Best Practice Storing Sensitive Information in Web Application

The full scope of this question is huge (several aspects of secure application design). I'm not sure a simple Q&A here will suffice.

Given the seriousness of what you're attempting, you should get a strong AppSec pro into your team and consider a holistic approach that includes that includes threat modeling, secure design, secure coding principles, security testing and verification.

I'll attempt short answers for pointed questions - with the disclaimer that AppSec pundits are still debating some of these, especially as some of the answers are "evolving" (e.g., secure credential storage - some discussions around favoring K12 and Blake2 over PBKDF2/ bcyrpt / scrypt).

This was not a question but:

  2) User registers for an account at register.php and passwords is
  hashed password_hash and Password_BCRYPT during registration.

Please make sure you're using a sizeable random salt. See this old discussion on hash and salt size for some understanding.
OWASP has a decent and recent guide for this here. Note that the 2013 discussions were about 64 and 128 bit salt. OWASP mentions 64 byte (not bits) salt. Also recommended are keyed functions - not just simple hashing.

Finally, you mentioned "basically like a password manager." That complicates matters a bit. You will want to leave the user in control - with at least a reasonable assurance that part of the keys to the kingdom are locked away in their brain or their system. The usual method for this is that the user's master key (password) is not stored anywhere (not even on the local system) but is used to derive the key(s) used for password storage.

Now for your questions:

  1) For a system like this, what encryption/security methodology is
  considered best practice to maximize security of the sensitive
  information that is stored in step 4 and 5?

Sorry, no short answer for this question.

This system would need a comprehensive threat modeling + a privacy as well as security design from ground-up. It is good that you started off quite well - but please don't underestimate the tasks at hand. OWASP has guides for most parts, though people with deep expertise have been known to diss some areas (usually on the count that "it's not perfect" ... which, I consider a pedantic objection).

  2) What is most secure way to transmit the information from step 4 and
  5 to a third-party website via the iframed web form?

As a security-conscious user I don't trust iframes. I don't recommend them to users. If what you're doing is akin to a password manager functionality - I suggest you explore alternatives.

  3) Is it better to store the sensitive information entered in step 4
  and 5 on the server or on the client? If on the client exactly how
  should this be done?

Please see a previous para where I mentioned master key (password).

If you follow that advice, then you should store the per-user hashed-stash of passwords on your server. There is no real (technical) advantage of storing properly hashed/encrypted passwords on the user's system where it can easily be wiped out for a number of reasons.

Hope this helps.


There is no mathematical proof that secure encryption systems can actually exist, let alone that any specific candidate is secure. At best, some encryption algorithm can be proven to be secure (for some notion of security) as long as some given mathematical problem remains intractable with existing knowledge. E.g. the Rabin cryptosystem can be proven (with some caveats that are a bit too long to explain) to be secure if it is not feasible to factor a given big integer into its prime factors.

Symmetric encryption algorithms (such as AES or 3DES) don't usually boast even that kind of proof.

In practice, the "gold standard" for cryptographic algorithm is survival. To gauge the security of some cryptographic algorithm, the procedure is the following:

Publish the algorithm with a complete unambiguous specification, along with a reference implementation and some test vectors (no, the reference implementation is not the specification; that's something else).
Let the design cook under the fiery gaze of many other cryptographers for some years.
If none of them found anything bad to say about the algorithm after that time, then the resulting algorithm is "probably good enough".

The crucial point is that you have to attract the collective interest of many researchers for a long time, which is not an easy task. Some key ingredients include the following:

Make sure that you publish your algorithm with the utmost clarity, and using the terminology accepted among cryptographers. Don't make them chase wild geese; they won't. See (for instance) the eSTREAM portfolio for examples on how this is done. (In particular, avoid using the word "cypher", which brands you as "someone who watched the Matrix movie too many times" instead of "someone who actually knows a bit of cryptography.)
The algorithm should be interesting in some way; for instance, it might be substantially faster than existing alternatives (see eSTREAM again to get some information on what "fast" means for cryptographers).
Don't patent. For cryptographers, patents mean that they either won't be able to publish their result, or that the patent holder (you) will make money out of their efforts, or both. Patents also mean that nobody will actually use your algorithm, since unpatented alternatives exist and are, by definition, cheaper.

A high level of peer scrutiny is normally achieved as part of competitions where some organization goes to the trouble of formalizing the requirements, gathering candidates, and running regular meetings and conferences. NIST did just that when they wanted a new symmetric encryption algorithm: it was the AES competition.

If you operate out of such a competition, and your algorithm is not that interesting, then you could still salvage it by using it to protect valuable data. For instance, convince a satellite TV broadcaster to rely on your algorithm. Then some cryptographers may find it amusing to blast it into smithereens, just to show you that things shall not be done that way.


How can I detect whether a webshell exploit has been run?

You can do a self pen-testing by:

Executing that php file in your case the arbitrary jpeg file in your browser and see if it displays or execute a simple Linux command say ls.

Example: say the jpeg file is in your <path>/uploads/ you shoulbe be able to get a shell from your browser if you enter http://yourSite.com/uploads/shell.jpeg

You can also detect such web malware by analysing your HTTP access logs. Because these malwares depends on the HTTP protocol having your ewb server serving the requests; it should log all access and errors. For Nginx your logs should be under

access: /var/log/nginx/access.log
error: /var/log/nginx/error.log

Example: cat /var/log/nginx/access.log | grep -i 'name_of_file.jpeg.php'

Note: You do not want to remove the web malware until you see what the uploader has done or doing to your server, so you can recover from any damage.

Post Mitigation: After you mitigate the damage, fix your application vulnerability by updating to restricting who can upload files, in addition you may want to disable PHP execution entirely in you /uploads/ folder (how?)


Why does my home Ubuntu installation says my chosen hostname resolves to an external IP?

The way hostnames work in GNU/Linux is kinda silly.  The system itself only knows of the hostname, not the fully qualified domain name (FQDN).  In your example, your hostname is 'fortknox'.  To get the FQDN, for example, if you run the 'hostname -f' command, what happens is it uses the resolve to resolve the address of your hostname, then uses the resolver to get the reverse of that to translate the address back into a domain name.  Since you don't have your hostname in your '/etc/hosts' file, it is using DNS and looking at /etc/resolv.conf.  It will search any 'domain' or 'search' listings in '/etc/resolv.conf' until it finds an address that matches that name.  For example, if you had "search example.com" and "fortknox.example.com" matched an address "256.0.0.1", it would then go on to reverse lookup that address and find "fortknox.example.com" or it may even find another FQDN that has nothing to do with either "fortnox" or "example.com".

In order to solve your problem, there are a few options.  Most people just add their hostname to their "/etc/hosts" file so that it resolves to "::1" or "127.0.0.1".  Another thing you can do is edit your "/etc/resolv.conf" and take out the "domain" and "search" entries that you don't want to be searching.  Since you are getting this error during install of the operating system, you are probably getting your "domain" and "search" from your DHCP server.  In that case, you can edit those settings on your DHCP server.  If you don't have access to the DHCP server, the easiest thing you can do it just choose a different name.


How can I work out how they've been hidden

Hiding partitions is actually relatively straightforward. First up, some theory.

Your disk is a big bunch of memory addresses as far as the operating system knows - we call this LBA addressing. Ignore everything your read about CHS unless you're dealing with XP and earlier - modern hard disks do not come with cylinders, heads and sectors although they do come with some strange compatibility support for people who want CHS values.

Now, on this big empty space you need to decide how to lay out your data. You do this by having a partition table - that is, a known area of the disk that holds data describing your partitions. There are two schemes in use in most consumer PCs - MBR partitions and GPT ones. MBR stands for the master boot record and everything, the code needed to launch the OS and the partition table, lives in the first 512 bytes. Wikipedia describes the format as it goes for GPT partition schemes.

Things can get more complicated. As you are no doubt aware, MBR limits you to four partitions per disk, which is how logical volumes were born. Logical volumes are basically another type of partitioning scheme inside one of your four MBR partitions. Of course, when I say "logical volumes" I could mean logical volumes from Microsoft, LVM as part of the Linux Kernel and so on. These schemes are unnecessary (but LVM can and might be used) on GPT disks because these support unlimited partitions, or if you are on Windows, an arbitrary 128-partition limit. Mind you, you can't have that many drive letters in Windows anyhow.

So back to your question: how do you hide a partition? Two ways, as far as Linux is concerned:

remove the entry from the partition table by supplying a null entry where the partition should have been.
fill up the partition table, but don't fill up the disk. Allocate the new partition in the free space.

These two have the same on disk result - they're just different in the order of events that are needed to make them happen.

  and any suggestions on how to unhide them so that we can mount those other partitons?

The most obvious way would be to re-write the partition table entries for these partitions. You can then run kpartx -l to see what would be mounted and kpartx -a to trigger a re-evaluation.

However, editing partition tables is a bit of a fraught process unless you're really happy totally breaking things and I'm not sure I'd recommend it. Luckily the Linux kernel has an awesome trick called device mapper.

The sole purpose of device mapper is to take one or more block devices and map them in some defined way to produce a virtual block device. Long story short, you can use device mapper to say "map from my hard disk starting at block 1000 and ending at block 2000 this new block device". Then the resultant device is a 1000 block device which maps back to the original device but can be used as a block device in its own right - containing a filesystem! If you're familiar with loopback devices, the trick is quite similar.

To create such a mapping, simply do:

dmsetup create mappingname --table "0 2048000 linear /dev/sdx 0"

where 0 2048000 represents the starting block and ending block this "window" creates on device /dev/sdx. If this succeeds, you should have a block device /dev/mapper/mappingname. You can find the documentation for this as part of the Linux kernel.

As an aside because I can't help myself, "fake" RAID cards on Linux works in exactly this way. The command dmraid -ay analyses your attached disks for RAID card metadata and creates the appropriate device mapper mappings.

  It seems like someone has gone into a lot of effort to hide the partitons but I don't know how.

Now, the ultimate crux of the issue is that whatever you do, you need to know where the partition is on the disk. Most filesystems have recognisable super-block structures. NTFS for example begins with a BIOS parameter block and various other metadata - you can see this here. Ex4 has a superblock with various magic values. Repeat for just about every file system out there.

How you go about finding partitions matching a given set of file systems - well, I would have hoped TestDisk would have identified the metadata. Failing that, you could write something yourself.

An encrypted volume may be more problematic. Depending on the software in use, there may be no magic value that indicates a file system at all - indeed, it may be indistinguishable from the random junk also on the disk and abandoned by legitimate file systems. The only hope you have in this case is that the disk has not ever been repartitioned and there are still identifiable "empty zones" between the valid partition ending and the encrypted partition beginning.

At this point, you've exhausted my personal knowledge. It looks very much like you may need to write some custom scripts/tools to parse your disk (image) to find what you need, identify the range and then map the volume. There may be users here who have more experience of forensics and can point you at existing tools, so I'd be tempted to hang around and wait to see if any materialize.

Disclaimer: I work in disk imaging and recently happen to have upgraded our Linux environment to support fake RAID cards. Oh and LVM too.


You should rework your entire system.  It is inherently far less secure than it should be.  There is no good reason that you should be storing encryption keys that could be used to impersonate your devices on your servers at all.  Rather, you should be providing each device with a signed certificate (from one private CA that you can operate securely using CA best practices).  This affirms to you that a) each device actually is using a public/private key pair authorized by you and b) allows you to verify each device from the public cert which you can store in the clear (or even be transmitted by the device at the start of each connection and not stored on your servers at all).

For talking to your servers, you only need to have one private key used for all communications and a public key used by the devices to verify your server.  AES can still be used for the individual sessions between the client and server, but the key can be generated on the fly, exchanged using the asymmetric system and then discarded at the end of the session.

Under this setup, you only need to store 2 to 4 keys securely instead of needing an entire infrastructure to manage keys whose only irreplaceable value is to attackers that are trying to compromise your system.

Update: If you really can't use a proper distributed key infrastructure, then you will need to use key chaining to minimize the sensitive data.  Encrypt each of the keys with a master key, thus enabling them to be stored safely anywhere.  Setup an extremely locked down server with the master key and have it provide encryption and decryption services for the system so that the keys are never decrypted outside that system.  That system would then basically be functioning as an HSM (if you can get an actual HSM, that would be preferable.)  Connections would be sent off to that system along with their encrypted encryption key.  The system would decrypt the traffic and provide it back to the requester.  You would additionally need some kind of security to authenticate the services making requests of the encryption/decryption server, though the specific needs there depend largely on what kind of security you need on the data at your site.


The theory of the Web of Trust is that participants act as local certification authorities, verifying the correspondence between public keys and identities. Guarantees can be obtained from chains of signatures on keys based on the following heuristic: presumably, an attacker could corrupt or deceive some users, but not all. So if you can build many chains of signatures, from a key you trust a priori (your own key) down to the key you want to validate, and all these chains go through distinct intermediate keys, then all the involved presumed manual verification somehow add up: if you have 12 such chains, then, the attacker (who tries to impersonate a user) would have had to bribe or fool at least 12 distinct people to achieve such a picture.

Whether this heuristic validation is sufficient is open to debate (personally I don't find it anywhere near decent, as far as security is concerned). However, the core principle is that any act of key signature contributes to the overall security only insofar as the corresponding identity verification is robust against corruption.

In the case of your robot, the robot would merely verify control of an email address. Unfortunately, emails are not a secure system; in fact, PGP has been invented precisely because emails are not secure. When you use PGP, you assume that possible attackers can read and fake emails at will; that's the very reason why you use PGP. In that context, basing the safety of the key-to-id signatures on emails seems unwise. Or, said otherwise: the contribution of the signatures produced by your robot to the overall "validation guarantee" ought to be considered to be very low. It does not hurt per se, but it won't help a lot.

(Or, rather, it may hurt if people begin to trust such signatures for more than what the actually provide.)


Human or Bot: Behind the Scene Checks vs CAPTCHA

CAPTCHA are not necessarily needed nor or they the only solution. Defense in depth means using multiple tactics, layers, and techniques. If you have information you can try to determine the likelihood that the client talking to your web app is (A) a human and (B) a human you want accessing your site.

There are reputation services out there that can provide blacklists based on reports or peer-customers, your upstream network providers or CDN providers may offer such services as well. You may choose to block access from certain known bad ranges, bad or unlikely countries of origin, etc.

You can tune your response based on the risk, cost, etc. You can also manually adjust your metrics over time depending on expected number of customers versus customers that do not sign up, repeat ip addresses, tracking to email invite codes, etc.

A while back I saw a good presentation on "Repsheet" where the presenter talked about all of the behavioral analysis and data points his company uses to identify likely fraudsters and how they used multiple techniques to address it. The slides were more accompaniment rather than stand alone, but you should still be able to follow the techniques. Some components of the system are available at the repsheet github repo.


Safety of publishing last 4 credit card digits in age of fast computing?

Creating Luhn valid credit card numbers is not difficult, if you need them they're available here amongst other places.

The trick for the criminal is tieing up the credit card number to the rest of the data to create a fraudulent transaction (CVV, expiry, name, perhaps address).

Even if I have the customers name, expiry date and last 4 digits, brute force shouldn't be a problem as it's an online brute-force and if you start iterating through valid numbers with a credit card processor, I'd expect that you'll get blocked very quickly by fraud detection mechanisms..


Question - "D3 (js) allows you to bind arbitrary data to a DOM"

EDIT:  I can't comment on the question since I got locked out of my old account and don't have enough reputation...  All the below applies to data too.  Nothing on the client side is under your control.  I'm confused as to why you wouldn't be worried about arbitrary code but only arbitrary data.  Generally speaking, the ability to modify code provides more power to produce "unexpected" results than the ability to modify data.  Maybe you should explain exactly what you are worried about.  Can you clarify what you mean by "authorized JS execution"?

If I understand your question I think you are asking whether a user can change your client-side javascript arbitrarily i.e. to change it however they please.  The answer is a resounding yes.  Have a look at Greasemonkey, for example.  In general, anything that is executing on the client is in their control.  There have been many attempts to create client-side systems that prevent this kind of thing but they really only work if the client opts to use them.  Any technically sophisticated user will be able to disable these options.

You should never put any sort of sensitive logic on the client-side.  All input coming from the client should be considered potentially malformed or otherwise manipulated for nefarious reasons.

There was a case decade or so back where a retail website took the price of an item as an input from the client's POST.  A user saw this and submitted a price of $0.01 and ordered a bunch of items.  The website duly executed the order as submitted.  It went to court and the case was ruled against the website.  That is, it wasn't even illegal.


You are essentially correct in your last paragraph:

Is the sole purpose for authentication purposes so that one who has a public key knows that this piece of encrypted hash information is signed by the person that issues this public key (has the private key) since he/she is able to decrypt it.

Though, as mentioned in comments, and in various places around the internet, the idea that a signature is "signing with the private key" is not quite right, it's like saying that a motorcycle is a mechanical horse; it's kinda right (and if you're talking to someone from the year 1685 then it's probably the best you can do) but it's also completely wrong.
So I'm not sure where you got that image from, but I would be wary about anything else they've said, since they are clearly over-simplifying.

I think you already have the core idea, but I'll try to add some more context.
Let's say you're in some sketchy foreign country and a complete stranger walks up to you and says "Hi @Noob, I have a letter for you from your mother." Before you open the letter there are two things you probably want to know: 1) did this letter really come from your mother? And 2) did anyone modify it before giving it to you? In information security these questions are known as authenticity and integrity, respectively.
Digital signatures accomplish both authenticity and integrity, let's talk about integrity first.
Data Integrity
With this question we want to prove that the message has not been intercepted and modified while in transit. To do this we will use cryptographic hash functions with the idea that if two messages have the same hash code, then with a 99.99...% chance they are the same message. (The 0.0...01% chance that two properly formatted English messages have the same hash is actually exploitable, and is called a hash collision attack, but we'll ignore that here.)
So when I send a message, I'm going to attach to it a hash of the message so that the recipient can compute their own hash of the message and check that they match (that's the right-hand-side of your image "Identical hash validates data integrity"). But what's to stop the mail-man from replacing both the message and the hash with new ones? Well, we'll solve that at the same time that we solve authentication.
Data Authentication
In this question we want to prove that the message which claims to be from your mother, did actually come from your mother. To do this, we usually get the sender to include something that only they could have done, for example you sign paper by scribbling your name in a way that nobody else could possibly copy, ancient kings would press their rings into wax (assuming that nobody else has a copy of that ring). With digital signatures we are going to sign a small piece of sample data and send it along, that way anybody can try decrypting it with the public key in the sender's certificate and make sure that it matches the original sample data. Now, instead of signing any random piece of data, we'll sign the hash of the message and kill two birds with one stone. When we check that
decode(received_hash, sender_public_key) == hash(received_message)

we are actually verifying both authenticity and integrity in the same step, since the only way this will pass is if the sender owns the matching private key and the message has not been modified.
~~ Edit in response to your comment: ~~
How do I know that the public key that I have is actually for my friend, and not for an attacker pretending to be my friend?
That's what certificates are for.
The question has a different answer depending on the type of trust model we're using, so let's look at the two main ones:
Web of Trust
This is the system used by PGP where each user creates a certificate for them self and gives it to their buddies. The first time you give your cert to someone you have to do it carefully, like on a USB stick in person, or once they have it, have them encrypt something for you and make sure you can decrypt it properly.
Once you have a certificate that you trust for someone, then you can encrypt for them and verify their signatures without any problem.
There's also the Network of Trust (aka "Web of Trust") idea: you can add your signature to anyone's key to endorse that it's genuine. Let's say I'm good friends with Bob, and he has endorsed Alice's cert, then I'm probably OK to trust Alice's cert.
Hierarchical Trust - Public Key Infrastructure (PKI)
This model gets it's trust by having all certificates generated by trusted servers (called Certificate Authorities). In this model, the job of the CA is to make sure that the person is who they claim to be, before issuing the cert to them. For example, if someone submits a request for a certificate tying pub_key to bob@example.com and 1-800-123-4567, then the CA might send a one-time code to bob@example.com and make sure he can get it, and might try calling 1-800-123-4567 and ask "did you just order a cert?"


The Java Sandbox was bypassed a lot in the last years and Java established itself as one as the major attack vectors in drive-by-downloads. To mitigate the problem Oracle decided to only allow applets signed by a trusted CA (i.e. no unsigned or self-signed), since this is at least increases the efforts needed by the malware author. Also, certificates used for signing can be revoked to limit the impact of a certificate used for signing malware. This change to the platform was done in 2013 with Java 7u21.

This does not mean that all these applets run outside the sandbox. To cite oracle:

  As of 7u21, signing no longer automatically equates to privileged execution, ..

Thus if the applet uses privileged execution depends on the exact way it was embedded and on the permissions it implicitly or explicitly requests. With Java 7u51 further restrictions were added and all applets must now contain the list of permissions they need.

Apart from that it is recommended to remove tje Java plugin completely for security reasons or at least make applets click to play, which is the default in several browsers now.


Is there a way to tell, when looking at a packet, that an aircrack-ng attack happened?

What kind of attack are you talking about? DoS attack? If yes, you should look for deauth frames on your sniffer captured data. Here there is an interesting link about how to filter on wireshark to look for deauth frames: https://packetwrangling.com/2017/11/02/weathering-a-deauth-storm-with-wireshark/

Other kind of attacks like bruteforce against your WPA/WPA2 network are not detectable because they are done offline. The attacker capture the Handshake and then try to crack it offline by bruteforce, dictionary attacks or however. So, there is no trace about this cracking attempts.


Can I know that my bluetooth speaker has been hacked?

You can try to determine if someone else is logging into your laptop to play music. Using the command

sudo less /var/log/auth.log

and/or simply

last

will show you users who have logged on. Auth.log is privileged so you need to be root/use sudo to view it. From there you can determine if you were home and logged in at that time to see if someone has taken control of your Dell laptop. A note from the comments: if you think your computer may be seriously compromised, running sudo could give the attacker your password (if they don't already have it).

You can monitor the Bluetooth pairing history on your laptop as well using

cat /var/log/syslog | grep blue

That command opens the syslog file and searches for the word "blue" to see logs containing "bluetooth". That should show you pairing history. This is assuming a hacker may have broken into your laptop to play these sounds.

As for logs on the speaker itself, I doubt it would keep any and I doubt you'd be able to access them if it did. It's important to note that Bluetooth can only be active from one host at a time, so if someone is hijacking your Bluetooth connection, it would necessarily invalidate your pairing. If your connection has been hacked, you would need to reconnect your laptop to the speaker.

Some important questions for you (you don't necessarily need to answer them here, just something to think about):

How far away is your nearest neighbor? Bluetooth only has a range of 30 meters (100 feet) line of sight; less if it has to travel through a wall. In an apartment/flat you might run into this problem, less likely if you live in a detached house.
Have you ever had to reconnect your Bluetooth speaker to your laptop when it hasn't been unpaired? This doesn't necessarily mean it's been hacked, Bluetooth is notoriously unreliable, but it's one thing to consider.
Do you have to push a button on your Bluetooth speaker to get it to pair with your laptop? If you do, it's very unlikely it's been hacked unless the hacker has physical access to your speaker. Possible, sure... but very unlikely.

IMO, the more likely answer is that Bluetooth is unreliable and speakers can easily pick up interference. But you should run through the above questions just to be sure.


Techniques used by highly sophisticated entities to snoop on VPN or SSH traffic?

You seem to exclude quite a number of attack vectors. To summarize (an correct me if I'm wrong), out of scope:

Compromise of the client
Compromise of the SSH or VPN server
Comprise of network infrastructure
Collaboration of the VPN provider or SSH server administrators

I do believe the problem is over simplified by not considering these attacks. Certainly, the government agencies use these techniques to eavesdrop on your communication.

If the government has collaboration from your ISP or has a monitoring device in the network, they are still able to see source and destination of SSH and VPN traffic. So they know what VPN provider you are using. What bandwidth is being used and what the timing of this traffic is. Some information can be gained from this. A user browsing a website will had a low throughput whereas an attacker ex-filtrating data over SCP will have a high throughput which is fairly consistent over time. Agencies have knowledge of certain IP ranges owned by certain ISPs, countries, companies. This helps them in determining the goal of the traffic.


Unfortunately if it is a properly configured transparent proxy, getting the originating IP address is not *possible. The best you can hope for is a badly configured transparent proxy.

You might want to read this post for more info on why.

*If you act ethically. You have to consider two things here:
Firstly, the ethical issue of trying to locate a user that obviously wants to remain anonymous. Secondly, the fact that an transparent proxy is designed to do exactly that, protect the identities of the users behind it, and to bypass that would mean that you would need to serve some malicious content (possibly script) to the client that can exploit a vulnerability on the client system to bypass the proxy or identify the user otherwise. This is obviously completely unethical and possibly illegal depending on the presiding laws and thus I suppose not suited for your experiment.


A full answer would be far beyond a post on this site, so I will only give hints here.

You problem a real security question. The answer will not be (only) technical, but you should first wonder about your real security requirements. In security, I want a safe solution just means nothing, a solution can only be safe according to a system of security requirements.

So you should ask yourself the following questions - I do not know your use case, so I cannot answer them

what are the already known weaknesses (known vulnerabilities in used libraries or frameworks, pen testing reports...)
what are the threats to consider (information theft, unwanted modifications, denial of service, physical attack...)
what are the possible attackers you want to be protected against (script kiddies, NSA, russian mafia...)
what could be the possible consequences of data compromission

You will end with a number of risks. You then will have to say how you can mitigate the risk itself or its consequences, and whether the remaining risk is acceptable or not.

What you propose is a mere obfuscation of data requiring first an attack of the web server and then access to the database. You can say whether it is acceptable for your security requirements after doing your risk analysis, I cannot.


Why are short-lived certificates so rare?

It would be a huge operational cost in environments that don't have automated certificate management in place, which, in reality is the vast majority of the operational environments in the world today.  In fact, in most environment little to nothing is automated.  We've just started seeing people dip their toes in those waters in the past few years, and most mainstream organizations only in the past year or two.

So, when making a modification to server (like replacement a certificate) requires a purchase order, a manual deployment by a server admin, and a 4-6 week change management process, and you multiply that by, say 10,000 times for a moderately large-ish organization, short-lived certs go from being a challenge to an impossibility.

Certainly there are organizations (like Google, for instance) who have this nailed, at least on their public properties (I don't know if their enterprise systems get the same attention) and it will start to invade the mainstream with tools like Let's Encrypt's ACME client.   But that hasn't existed for long, and there was nothing else out there before that made this easy for a organization that isn't sophisticated to implement.  Add that to the fact that fake or stolen certificated haven't been a massively widespread or expensive problem organizations have needed to struggle with, and there wasn't really any incentive to invest in a solution.   The real answer is to make short-lived certs cheaper and easier to manage than long-lived certs. That is when they'll take off, and why Let's Encrypt holds such great promise in this area.


Sniff packets then repeating these requests?

While you might capture and resent the captured data it might cause the same result as the original data. For example if you just capture encrypted TLS traffic replaying it will not cause the wanted action because TLS protects against such simple replay attacks. Even if you take an unencrypted HTTP request it might include a one-time token or some other protection so that the receiver will detect a resubmission of a previous request.
In summary: it might work or it might not work, depending on the underlying protocol and on the servers and applications behavior.


Examples for practicing reverse engineering/disassembly of win32 .executables

http://crackmes.de/ is perhaps the most comprehensive website in this category.

Also Keygen challenges at http://tuts4you.com/download.php?list.51 are good .


What to share (OpenPGP key ID or fingerprint) once key uploaded on key server?

Fingerprints and key IDs are related: short and long key IDs just form the lower 8 respective 16 hex digits (32 respective 64 bites) of the fingerprint.

An example using my own fingerprint:

fingerprint: 0D69 E11F 12BD BA07 7B37  26AB 4E1F 799A A4FF 2279
long id:                                    4E1F 799A A4FF 2279
short id:                                             A4FF 2279

Shorter identifiers imply larger chance of collisions (malicious or by chance). Never use short key IDs, at least rely on long key IDs. If providing the full fingerprint is not an issue, share the full fingerprint. Short key IDs can be collided within seconds using graphic cards. The long key ID is considered save for now, but only unless somebody figures out more advanced attacks: there is not much buffer left that prevents brute-force attacks. The space of possible fingerprints is vast, and collision attacks are not feasible.


The real question is if you feel safe. If you feel it's necessary, I would send an e-mail and possibly do what they ask. However, I doubt the authenticity of the email for a few reasons.

They provide no evidence they are who they say they are. The From: part of an email can be faked fairly easily. See: https://en.wikipedia.org/wiki/Email_spoofing.
If you actually try to go to http://www.lizsquad.net it can't be reached and seems to not exist. While the address could be just a mail server, that seems quite unlikely
The Lizard Squad twitter was shut down 1-1-17. See here: https://twitter.com/lizardlands.

While the whole thing seems quite unlikely to be legitimate, if you want you can certainly send them an email and see what, if anything, comes back.


Is it bad if one uses the same email address on different sites/forums?

If you are concerned that some site is going to spam you or (worse yet) sell your email address, then you will want to use a unique address for that site.

If you're worried about a site being hacked, well, your email address is mostly public anyway; a hack just makes it a little bit more public.

What you must not do is use the same password across sites.  If one of them is hacked, your security on all of them is toast if they all have the same password.  It is critically important that the password to your email account be strong and different from any other site.  If the bad guys get your email password, they can use the password reset mechanism to break into your other sites.  Like your banking site, for example.

There are things a site or forum can do to make it difficult for attackers to compromise the password data, and to help secure the data even if it is compromised.  You generally cannot tell who's using best practices and who is not.  It is safest to assume that if a site is compromised, your password on that site is toast, along with any others where you've used the same password.

Edited to add: If you care about the ways a site can help protect your password, I wrote a short piece on that a couple of years ago: http://bitmonger.blogspot.com/2012/07/six-simple-rules-for-secure-storage-of.html


Truecrypt compromised? (Coldboot attack)

can encryption technologies such as TrueCrypt still be relied on for a high degree of protection?

Yes, provided you understand exactly what protection you're getting from Truecrypt.

Encryption is not access control and it does not protect your system whilst it is powered on. Once you put the key material anywhere near the computer (e.g. typing it in, loading it into memory) you should treat the computer as containing the key material because it does.

Therefore, anything that can extract your computer's RAM can read this key material. This should not be remotely surprising in any way. I have looked through the truecrypt driver code in a fairly extensive way (I don't approve of the statically allocated stack buffers they use, they should prefer ExAllocatePoolWithTag, but what do I know?) and it would not be all that difficult to write a driver to pull the volume keys out of memory on a system which has truecrypt running.

If you want encryption of your disks to be effective, you must do two things:

Ensure that you do not attach the key material to the system when you can be observed by somebody you wish to prevent from accessing your data.
Have the system powered down when the data is stolen.

Against a casual, opportunistic thief, point 1 happens by default since the thief in question is almost never there when you are using your device. This makes disk encryption a good defence against stolen laptops, for example, since opportunistic thieves who steal powered down laptops get some hardware, but not some data.

The determined attacker, or what cyber-literature refers to as an advanced persistent threat, however, may have the resources to observe 1. This could be through several means:

Bugging the locations you input the key material including hardware keyloggers, cameras and whatnot.
Exploiting the good old remove the RAM, freeze it and whatever techniques preserve system memory after power down.
Compromising your system whilst it is powered on - firewire, malware, whatever.

This has been the case for as long as disk encryption has been in use and will be the case for as long as disk encryption is in use in its current form. Encryption does not protect you against these threats - for these, you need good access control, good auditing procedures, good security practises to prevent malware access, good physical security etc.

Slight update, for extra fun:

Hibernation is a known attack vector in modern operating systems which depending on your implementation stuffs up secure boot entirely. The work done on this was derived from the fact it was possible to bypass Patchguard by altering the page file to load code.

The motto of the story in these two cases is that the operating system cannot trust the state it loads from disk unless it has control of the CPU.

How does hibernating affect your in-memory key? That depends on whether the hibernation file exists on the encrypted drive or not. If it does, good - you'll need to re-enter the key to decrypt it (and you'll have prevented the hibernation file attack vector, too). If it doesn't, then if the key is written out into the hibernation file you are in trouble. If it isn't, you're still not massively safe, as a sufficiently determined attacker with serious resources can probably take advantage of that.


Will 2FA protect me if there is a password breach?

It depends on what exactly was breached

If the breach is just user names and passwords, then 2FA does indeed protect you in this case.

However, if the attacker can extract passwords, who knows what else they can extract? One-time passwords are based on a secret key shared between the client and server. If the breach allows an attacker to extract the secret keys, they can then generate fake OTPs, so 2FA does not protect you.

It is good practice to hash passwords before storing in a database, which provides some protection in case of a breach. It is not possible to hash the secret key for a OTP - the server needs the original secret key to verify the submitted OTP. Because of this, it is good practice to have a dedicated microservice for OTP verification. If the main application is compromised, hopefully the microservice will not be.

Public key authentication

In this case the server only has the public key. A server breach cannot reveal the private key. In the case of a read-only database breach, an attacker cannot then login as you. However, if there was a read-and-write breach, an attacker could overwrite your public key with their own, and proceed to impersonate you.


The SP sends a samlp:AuthnRequest when it wants a token. This request can be signed, and the IdP can decide whether the response should include whatever it wants. See section 3.4.1 "Element AuthnRequest".

However, which key is used to sign the request, who issues the certificate, and how the key ends up in the hands of the SP are out of scope of the protocol.

It also requires both parties support such a profile, as you can have IdP-Initiated and SP-Initiated requests.

Alternatively some services handle this problem by encrypting the attribute to a key only the SP knows and is built-in to the protocol. This too requires an out-of-band configuration, but can work with all profile types.


How to encrypt database connection credentials on a web server?

The other answers here are all correct in a couple key aspects. The file containing your connection string should not be kept in a world readable location, and as you note, you can't stop someone from getting at the key if they've compromised your server. Even so, there are other reasons to encrypt the key (or the file). Part of the reason OWASP recommends against storing in plain text are to prevent accidental disclosure of credentials to those who don't need them.

While many make the point that encrypting the connection string on the running system provides little actual value (security by obscurity) this is true primarily in the context of the live system. Assuming a traditional LAMP configuration, file based permissions would prevent read from any user other than the script user that the php/apache process is running under. Having the file outside of the root location provides slightly more potential security (in case of misconfigured MIME handlers or .htaccess) but isn't strictly necessary.

The greatest value in segregating connection settings is that authentication details and data no longer needs to be handed out to developers/testers or other individuals that may have a real need to connect to the server. By keeping the connection details out of source control, and out of general distribution, you reduce the possibility of loss or leakage.

A second benefit is the distribution and backup of the source. Certainly a best practice would be to only transfer files containing sensitive connection and account information encrypted themselves, but for many reasons, this isn't always practical. Due to this if encryption is in use, separating the key from the connectionstring and separating the connectionstring from the source is an essential action. Doing this has separated the duties and protection of the encryption keys (or configuration files) and becomes a system administrator function, rather than a developer function.

That out of the way, in Apache/php you have a number of options.

1.) Don't put the connectionstring in php code at all. You can put these values in your httpd.conf or virtual hosts file. Connection then requires no parameters when using mysql_connect() ... more detailed use is available here: http://www.php.net/manual/en/class.mysqli.php

2.) Include the configfile.php configuration file as normal, but move the connection file out of webroot if you can, and encrypt the file itself. OS decryption can be set up by the SA for the process that will access the file. Alternately use If you can't move the file out of the webroot (shared hosting) secure the file with .htaccess

<files configfile>
     order allow,deny
     deny from all
</files>

For Microsoft IIS with ASP.NET, the connection string is stored in the application.config or web.config file and the encryption used can either be a static machine key, stored in either of these files, or a key generated by IIS itself - which is not stored in an accessible location. Specifics are available on MSDN, which I won't litter this answer with since your question was specific to LAMP.

I should also note, that when possible, my preference is to avoid the issue altogether by using integrated authentication. Mapping the OS user to a db user pulls the protection requirements out of this question's context almost altogether.


Getting compromised is never a good feeling. That endless loop is a process. every process has an process id. If you don't have ssh access (and I assume you don't) try finding the process id by PHP script:

php system("ps aux");

Locate the name of the file for example php endless_loop.php which is located in the last column of the returned list. In the second column you find the process id. When you have the process id all you have to do is execute another script:

php system("kill proccess_id");


Using mysql root account to execute root commands

Assuming the MySQL daemon runs as a non-root user, you can't. At worst, you can exploit a vulnerability in the MySQL daemon and gain a shell running as the same user as MySQL. From there you'd have to use a local privilege escalation vulnerability in the OS to gain root.


How do we 'initiate' mail exchange with PGP

Apart from useless use of cat (<message gpg --encrypt [...] or gpg --encrypt [...] message would do, too) I don't see a real problem here. Adding your fingerprint is sufficient; as an alternative you could also --sign the document (the signature also includes it).

The only thing you shouldn't do is referencing your own key using your user ID, provide your (long) key ID or fingerprint here. Somebody else could create another key with the same user ID, and send you some kind of "drive-by-download" message signed with the fake key, which would result in you possibly downloading it without knowledge.


List of visually similar characters, for detecting spoofing and social engineering attacks

There are different approaches for homograph attacks. The success depends on the used font. For example in some fonts the small letter l looks very much like the capitalized letter I. And in others they don't.

Similarities

Use similar characters. They substitute the real character.

b ⇔ 6
c ⇔ (
g ⇔ q, 9
C ⇔ (
G ⇔ 6
L ⇔ l, I, 1, |
O ⇔ 0
S ⇔ 5
V ⇔ U
Z ⇔ 2

Sound Alteration Characters

Some language, like German, have special characters (e.g. umlaut). Under some circumstances they may look like a character without them:

a ⇔ ä, à, á
e ⇔ ë, è, é
i ⇔ ï, ì, í
o ⇔ ö, ò, ó
u ⇔ ü, ù, ú

Multi-letter

In some fonts the multi-letter approach is very successful.

a ⇔ ci
d ⇔ cl
g ⇔ cj
m ⇔ rn
A ⇔ fi
W ⇔ VV

Constructions

Construct a single character from multiple characters. Very popular is vv instead of w.

A ⇔ /\
B ⇔ |3
D ⇔ |)
G ⇔ (¬
H ⇔ |-|
K ⇔ |<, |{
L ⇔ |_
M ⇔ |v|
N ⇔ |\|
V ⇔ \/

Injections

Injection involves inserting meaningless characters into a string, especially within a domain/url.

http://somewebsite.example ⇔ http://some-website.example

Whitespaces are often overlooked in this case. The Zero Width Whitespace (&#8203;) is a nice tool under some circumstances.


Can the school see what you are doing on their laptop when connected to your home WiFi?

There is not enough information provided to give a clear answer, but I can tell you this.

Schools usually have pre-installed software to track laptops and to keep them in sync with the school's network. With that software, they could potentially log your browsing history remotely (even if you are on a different network), but that is not likely. The most likely way that they could easily track your browsing history from that computer is if you were on the school's network. The school's network most likely has an advanced system so it can operate a firewall that can block certain websites the school does not find appropriate. That being said, they most likely the school network would have log internet traffic of students computers on that network. Besides off that network, the only way they would be able to check your history is if:

They have software that DOES remotely send the students browsing history (as mentioned earlier, unlikely)
They have physical access to your computer. (Keep in mind they will not need credentials if your computer is not encrypted).

Bottom line is, that I would not condone searching anything on a school laptop that you would not want your school to see. However, most likely they will not go poking around as long as they do not have a reason (like using to much bandwidth on the school network).

Update:
Also having seen you asked whether your school "can see your Facebook", the answer to that is no if I am interpreting your question right. Your school cannot (by using their network) read Facebook chat messages or really anything you do on Facebook because it is encrypted using SSL (Secure Socket Layer).


Can people let me know why this command was ran and why he typed "network hacked....clampi found

If i understand this correctly, you called the 1800 number and gave them remote access to your computer where they opened cmd and ran netstat and typed "hacked... clampi found"

What is happening here is theater. When the scammers "check the computer" they do a variety of things including but not limited to:

looking at eventvwr
typing netstat or tree into cmd
looking at running services

Each one is designed to show you true information about your computer but then twist it in a way to convince you to believe there has been a breach of some kind. This is the essence of their con.

The idea for your specific example here is that while cmd is running a command, like netstat or tree, it still takes typed input. You can open cmd right now and type tree. While tree is running type something like "VIRUSES FOUND, MUST KILL EACH AND EVERY VIRUS" You will notice that once tree has completed  your text appears after the > in your cmd prompt. They usually use commands that take more than a few seconds to complete, just enough time to fully type out whatever they want so it doesnt appear one letter at a time but fully when the previous command is completed. netstat -sp tcp will generally take anywhere between 30 seconds to a minute and a half depending on connections. More than enough time to type out a sentence.

To the inexperienced this makes it appear as though a scan has been done and the result of that scan is output. In your case, they made it seem as though netstat is a scanner of tcp traffic and it found "clampi" a well known malware.

But it's theater, nothing more, they simply typed it so that, upon seeing it, the user enters a state of panic. In this state someone might do anything to fix the problem immediately! Well lo and behold your knight in shining armor, the tech support agent, who, for a fee of only 599.99 for the 3 month plan or 999.99 for the lifetime plan will personally make sure your computer is "hacker free" forever.

Its nothing more than a scam designed to prey on people who don't know the deeper aspects of computers or the full extent of their available features, which even today, is a lot of people.


I think that you have the answer to your question in the firewall rules.  From your network diagram it's reasonable to expect that your ISP has access to the Wi-Fi bridge that they provide, so if a host is accessible from there, it's likely he can access it.

In your rules, as you mention rule 60 seems out of place.  Rule 61 looks like a standard rule necessary to allow traffic relating to outbound connections from the internal network, but rule 60 seems from the information you've given to have all traffic forwarded across your router.

you're also right to say that usually firewall match one rule then stop matching on that chain, so the first accept rule would be hit and the second one 61 wouldn't be hit.

To test this what I'd do if I was you would be to connected a machine to the "outside" interface of your router, give it an IP address in whatever subnet is used there (assuming there's no DHCP in place) and then try connecting to a machine on your internal network.  If you can then, it looks likely that that rule "60" is the issue.

However be very careful removing the rule as removing accept rules on production firewalls can have unexpected consequences (i.e. it was allowing traffic you actually want and when you remove it, the traffic stops flowing).


PayPal payment reversal; scammer at work?

Is this someone testing out credit card numbers they've stolen?

Yep. You're being used as a canary to test stolen credit cards. They found your website at random and see you're willing to accept payments. They send you a token payment of $1 to see if the card works. (They used to use iTunes to do this, where they'd buy a $1 song.)

When they see the card works, they buy as many disposable Visa gift cards as they can. This racks up a few hundred to a few thousand dollars on the card. (They used to buy goods directly but it's easier for merchants to stop shipment of a flatscreen TV than it is a stack of gift cards.)

The cardholder or the FI notices the charges and starts reversing everything, but the money has already been laundered in the form of gift cards.

Thus, the scammer successfully manages to convert stolen credit into a fistful of untraceable, disposable gift cards. These can either be used for personal gain or re-sold for a slightly lesser amount to yield actual cash.


Request permission to PenTest on GoDaddy servers

After calling technical support, a representative told me (paraphrasing)

  "It depends on the hosting plan. Any shared hosting plan you will not
  be allowed to test. Period. But if they're on a dedicated hosting plan
  you can do anything and you don't need to tell us."

I pressed further for some sort of documentation stating that (so I'd have some legal coverage), and I was told that it's "buried" in the Terms of Service, specifically "somewhere related to the section on hosting" (this document?).

TL;DR GoDaddy doesn't seem to care what you do with their dedicated servers; you're just renting hardware. But they're very clear on the fact they don't want you touching any shared hosting boxes.


Are newly-generated recovery passwords sent to me via email hashed?

If they are indeed sending you a new password (i.e.: a system-generated password other than the one you previously had) when you click 'forgot my password' then no, that doesn't mean they're not hashing passwords.  They can have their forgot password function generate a password, hash it and store it in their database, and then (while it's still in memory) generate an email that includes the plaintext value.


Prevent users from easily changing the backend API URL of a desktop application

I do not think it would be a worthwhile time investment from a security standpoint, as it provides no security. As you said, users can just sniff the underlying protocol, hook or disassemble the application.
However, it may be worthwhile be from a QA standpoint. You don't want your users misusing the application, you want them to stay as close to the happy flow path as possible.


Is a full backup the quickest or the longest on restoring

The answer here I think depends on a slightly old-school approach to backups.  If you have an initial full backup to tape and you then do incremental backups to separate tapes, the incrementals backup quickly, however if you need to restore you may need to go through several different tapes to find all the files that you want to bring back, hence the slow restore.

In contrast full backups are slow to do (you're backing up all the data not just some) but the restore is quicker because any file you want back will be on that tape (as there is only one)


No one can never ensure you the ultimate safety. The practice you mention though is very good for encrypting an end-to-end connection. Pieces of advice:

Create a strong RSA key for the SSL
If you feel that iptables is not enough, use an external firewall, which will also be able to work as a vpn server and cover your original server behind it. Apart from the general rules, you can also set up IDS and IPS technologies.
Keep your software updated (less magic exploits can occur this way)
Watch out from where do you connect over vpn to your server. Try not to use your certificates over many different, not-trusted computers and networks.


Is an encrypted private key which never leaves my home directory more secure than an unencrypted one?

Yes, it is more secure to use an encrypted private key than an unencrypted one.

The argument your colleague gives just shows that an encrypted private key is not completely secure. His argument does not mean that an encrypted private key is no more secure than an unencrypted one. In fact, the opposite is true because the encrypted private key does protect against certain attackers and situtations that the unencrypted key does not. For example, it protects against the situation where you accidentally upload it to your public github account or something. It also protects against a specific type of attacker who only has read access to your directories/files. Because of these types of attacker and situations exist the encrypted private key is more secure.

On the other hand, your colleague is correct that an attacker with local access who can run processes, keystroke recorders, etc on your system could still get your key. However, a local attacker is a very powerful type of attacker and in the presence of such an attacker it is difficult to protect your keys in general.  However, one thing that could be used to protect keys in this situation of local attack is a separate physical factor like an RSA dongle.


Can pen-testing be done on a person's regular machine, or should it be done on a separate machine?

There is no reason to overthink your penetration testing setup. As long as you are working with established tools from renowned companies - you mentioned burp as a good example - you can trust them as much as any other third party software you install on your system. There is also no reason to protect your anonymity, as you are doing nothing illegal.

Having worked as a penetration tester for many years, I always liked to separate my penetration testing system using virtualization (VMWare or Virtualbox) for several reasons:

You have a standard image with everything you need. Having a clean image with all the tools pre-configured helps a lot to start new engagements fast. That's especially important, if you work for different clients and do not want to mix up results. This is less important in your scenario, but having a standard image to fall back to, in case anything breaks, is still an asset.
You are flexible concerning the OS. I like Windows as my host operating system, but many of the penetration testing tools I am using, require Linux as OS. While I prefer assembling my favorite tools on Ubuntu manually, others prefer a swiss army knife like Kali Linux, where many tools are already pre-installed and ready to go. Whatever route you want to go, being flexible when it comes to the OS choice can make life a lot easier for you. You can even use multiple OS in different virtual machines if your tool set requires it.
You do not clutter your host OS. Penetration tests tend to require a lot of different tools and installing all of them on your main OS will load it with a lot of baggage in the long run. Managing all those tools and keeping them up to date can become a nuisance. Having them separated in a penetration testing VM deals with this problem, especially if you reset it regularly to get rid of tools you only used once.
Added security when using less trustworthy exploits. In some scenarios you want to verify that an identified vulnerability is actually exploitable, but there is no exploit code available that you feel comfortable trusting. Having a throw-away virtual image makes it easy to experiment with the exploit and clean everything afterwards by resetting to a previous state. Sure, there might be a residual risk of a super advanced hidden malware that exploits a vulnerability to break out of the Hypervisor and infects your host system... but, while that's a cool story, stuff like this happens in real life only very rarely. That's a risk I would be willing to take.

So there are no reasons that makes it mandatory to have a separate VM, and I have several tools on my host OS, just do be able to check some things quickly. Burp again, is a good example that I like to have readily available without powering up a virtual machine.

But, as I mentioned above, it pays off in the long run to have a separate environment, but there is no reason to overthink it.


De-auth attack Reason codes and possible reaction

Based on code from http://www.sans.org/reading-room/whitepapers/wireless/programming-wireless-security-32813 , I would say that, yes, other attack toolkits can change the reason code.

One option for the victim is to use Protected Management Frames: http://en.m.wikipedia.org/wiki/IEEE_802.11w-2009


How do I know that malware on the client computer does not modify data transmitted to my webapp?

Short answer is: You can't.

All your server see is what the computer at the library sends. What programs or processes on that computer that generated the data is impossible for you to know. From the servers perspective, it might as well have been a pidgeon with a telegraph as your legitimate user.

The fact that the user entered a password does not mitigate this. Two factor autenthication with a cellphone does not mitigate this. Malware on the computer could hook into the browser and modify the HTTP requests after the password(s) has been entered.

There is one small thing you can do, though. Have the user digitally sign part of the message on another computer than the library computer, and then enter that digital signature into the webapp on the library computer. This could be his cellphone or a product such as a digipass. Since that computer is out of reach from any malware on the library computer, it is safe. The backside is that the user will have to enter the message he is signing on that device - not very practical for long messages. I have seen banks use this for signing the amount in a transfer, but not the account it is transfered to because that would be to user unfriendly.

That is only a partial solution that is only worth the effort for really high value targets such as bank. The easier solution is just to teach your users to not to do sensitive transactions from a public computer.


You must install some stuff. The same happened to me. But you can work with new hashcat 3.x and CPU in your vm, no problem on that:

apt-get install libhwloc-dev ocl-icd-dev ocl-icd-opencl-dev

And

apt-get install pocl-opencl-icd

This worked for me. I found it here. What I suggested It's a little different because you can install pocl with apt-get instead of downloading from git like that link suggests... Is the solution worked on my Kali vm.


Can't upload payload to my apache2 server. Pentesting exercise

Move it to /var/www/html/example.exe, then go to http://yourip/example.exe to download it.


A "pepper" is a secret application-wide random value appended to a password before hashing it. This ensures that an attacker has no way of actually cracking the password hashes without compromising the pepper value one way or another. This is unlike a salt which usually isn't a secret and appended together with the password hash.

If done right, this can be helpful in ensuring that an attacker with limited access to your systems will not be able to crack the passwords you store. This is quite a common scenario. Imagine an attacker that found a SQL injection attack that allows him to dump your password database. He will be unable to crack those passwords without the pepper which is stored in a configuration file he cannot get at.

That being said, I don't think peppers are commonly implemented. I don't know of any password hashing libraries that provide this out of the box, and i have never used it in my own applications.


for reCaptcha, the token needs to be sent to backend for validation right?

Yes. It's not clear of your exact setup based on the question, but the backend indeed does need to do some sort of verification to determine if the captcha was passed. Otherwise, a user could simply send requests directly to your server backend without dealing with the captcha at all, if it was purely a frontend thing.


How can one avoid having their online presence traced back to an identifiable network?

In order to serve content to you, the end web server must know where to send the information. Depending on how the individual packets are being routed, this could be with the IPv4 or IPv6 protocols. Each protocol use their own addressing systems, but still have "IP Addresses".

The website can not have any knowledge of how packets between you and the server come about. Internet paths are dynamic, so routing can change from one web page to the next. A trace route can be preformed, and the utility will give one of many paths for a website to reach it's destination client (you).

Beyond that, a website has access to some of your browser's information. For instance, your browser version and being able to read and write cookies. Interestingly enough, some individuals have made claims that websites can track users though screen resolutions. This seems quite unreliable so probably not of much use.

Browser information can vary between devices, cookies are not shared between devices unless the website writes the same data in cookies.

A VPN (Virtual Private Network) connection can eliminate a direct path between a web server and client. There are many services available, some even offer a website version.

Tor is a heavily modified form of VPN, which requires it's own reading.

As an added bonus, here is some log information from my web server. It shows basic information about some potential offenders: Where they are connecting from, what time and date, how and what they requested, and what the server's response to that request was.

46.165.254.129 - - [09/Jan/2017:00:32:33 -0500] "GET /muieblackcat HTTP/1.1" 404 210
46.165.254.129 - - [09/Jan/2017:00:32:33 -0500] "GET //phpMyAdmin/scripts/setup.php HTTP/1.1" 404 226
46.165.254.129 - - [09/Jan/2017:00:32:34 -0500] "GET //phpmyadmin/scripts/setup.php HTTP/1.1" 404 226
173.245.50.247 - - [09/Jan/2017:10:48:50 -0500] "GET /robots.txt HTTP/1.1" 404 208
222.186.51.194 - - [09/Jan/2017:14:25:04 -0500] "GET /phpmyadmin HTTP/1.1" 404 208
46.165.221.74 - - [09/Jan/2017:17:56:48 -0500] "GET /muieblackcat HTTP/1.1" 404 210
46.165.221.74 - - [09/Jan/2017:17:56:48 -0500] "GET //phpMyAdmin/scripts/setup.php HTTP/1.1" 404 226
46.165.221.74 - - [09/Jan/2017:17:56:48 -0500] "GET //phpmyadmin/scripts/setup.php HTTP/1.1" 404 226
46.165.221.74 - - [09/Jan/2017:17:56:48 -0500] "GET //pma/scripts/setup.php HTTP/1.1" 404 219
46.165.221.74 - - [09/Jan/2017:17:56:49 -0500] "GET //myadmin/scripts/setup.php HTTP/1.1" 404 223
46.165.221.74 - - [09/Jan/2017:17:56:49 -0500] "GET //MyAdmin/scripts/setup.php HTTP/1.1" 404 223
108.162.215.203 - - [09/Jan/2017:21:12:51 -0500] "GET /robots.txt HTTP/1.1" 404 208


Potential danger of infection through downloading malware?

Simply, no. If you didn't execute anything, the odds are approaching 0 (especially since it wasn't a MacOS executable).


Can a KRACK attack force a reauthentication handshake?

Yes, the AP can issue a Deauth message telling the client that it needs to renegotiate the connection.

Some attacks spoof that message to get the client to reauthenticate either to their rogue AP or to capture information.


Use the public key of a certificate as the key for HMAC SHA

TL;DR: "Using a public key as a secret key is not a good idea. – MechMK1"

I think you're mis-understanding how certificates work.

which will be deployed with private / public key on all workstations. So all the stations have the same certificate and therefore the same public and private key.

It's not really "private" if every employee in your company has a copy of it. Non-exportable helps, but you should really be issuing a unique certificate to each device; imagine the mess you'll be in if one of your devices is stolen / hacked and you need to revoke the certificate!

Is it possible, correct and secure to use the raw public key of the certificate (as a string) as the HMAC-SHA256 password?

Remember that public keys are intended to be public. Even if you are intending to treat them as a super-secret value, there is no guarantee that all of the software that touches them will. Two examples:

When a publicly-trusted CA issues a cert, they log it to public Certificate Transparency servers. For example, here is the CT logs for all *.stackexchange.com certificates, notice how many dev., qa. and test. certs there are in that list? By clicking into any of those, you can get the public key. If your certs came from a public CA, then I'll bet you can find them on https://crt.sh as well. This is not considered a problem because publicly-trusted certs are intended to be public in all aspects except the private key.
When establishing a TLS 1.2 connection, the certificate (and public key within it) is sent un-encrypted over the internet (@dave_thompson_085 pointed out that in TLS 1.3 the certificate is encrypted).

Never assume that your certificates will be a secret.

So your question "Is it ok to use a public value as a password?" is a bit like "Is it ok to use my name as my banking password?; no, no it's not.
Sounds like you need to figure out a different way of (securely) distributing an HMAC key to your apps.


Techniques to detect & mitigate Crypto-ransomware?

Backups, backups, backups.

Have a good backup and restore strategy. You should be able to restore any server, network fileshare or desktop client to exactly the state it had yesterday, last week or last month (adjust these time increments according to your business needs). When you notice a malware infection, just nuke the affected system and restore it from backup.

Backups should be on a physically separated system. Backups should be pull, not push, i.e. the backup system should have permission to read from the backed up system, but the backed up system should not have permission to write to the backup system. This ensures that a ransomware doesn't overwrite the backups.

Also, test your recovery strategy regularly. I've heard too many horror stories from organizations which thought they had backups, but when the day came where they actually needed them they found out that there was an error in their backup routine for years and they couldn't recover anything.

To prevent the hassle from being necessary too often, you should also improve the security of your workstations:

Give the user accounts on your workstations limited privileges. They should only be able to run those programs required for their work.
Do not give users the privileges to install software. Have the IT department install software remotely when it's required.
Also update all software remotely as soon as there is an update available.
Have a malware scanner on all workstations.
Also run a malware scanner on all email you receive.
Having your workstations browse the Internet through a proxy server also allows you to implement additional filtering on that proxy.

But all of that is really just auxillary to a proper backup and restore strategy which is always your final safety net when everything else fails.

Detailed instructions for how to implement each of these measures would be far too long and detailed to describe here, especially because the most appropriate solution also depends heavily on your IT infrastructure and business needs. But it should give you a place to start.


Use mdk3 by typing mdk3 --help.

Then look for the selection for deauthing. I think the command is mdk3 wlan0mon -d. I'm not on Kali right now so I'm not sure, but this command should deauth every device within a range regardless of APs. Mdk3 deauths devices by channel.


Password may not be similiar to last 5 passwords

They don't need to have the passwords in plaintext to be able to verify that.
They could be using the best practices(PBKDF2) and still be able to spot password re-use.

You have the password hash, the salt and number of iterations(e.g salt:iterations:hash). So all they have to do is keep the last 5 passwords run through PBKDF2 stored somewhere and run the same algorithm on new passwords along with the salts of old passwords and they can determine if the password was used before or not.

The downside here is that you can only check for exact match and even if a single character's capitalization has changed you won't be able to verify that for older passwords, but since you have to enter the current password to be able to change your pass, the application can have access to plaintext version of it at that moment and have more strict checks on your very last password. And this is what SAP does, you can't enter the exact same passwords you had before and you can also enforce the user to change at least "n" characters from their previous password in their new one. (Reference)

Hash algorithms have pseudorandom output and changing a single bit in the input makes unpredictable changes to the output. So apart from using salts, iterations or whatever even in case of simple hash algorithm use like md5 or sha-1, there is no way to measure the similarity between inputs, only having access to the hash output.


As sorted out the missing part was file privileges . As per documentation of LOAD_FILE the user executing the query must have File privileges  more over at file system level the file must allow the actions performed by query

LOAD DATA INFILE

For security reasons, when reading files located on the server, the
files must either reside in the database directory or be readable by
the user account used to run the server.
To use LOAD DATA INFILE on server files, you must have the FILE
    privilege.

  LOAD DATA LOCAL INFILE

Using LOCAL is a bit slower than letting the server access the files directly, because the contents of the file must be sent over the connection by the client to the server.

On the other hand, you do not need the FILE privilege to load local files.


How secure is Visual host key, and how is SHA2 converted into that representation?

Does the visual fingerprint uniquely identify a server's key?

No; the "visual host key" algorithm does not preserve enough information to give each key a 100%-guaranteed-unique image.  But neither does a more traditional fingerprint.  ECDSA keys like yours have 256 bits.  RSA keys have 2048.  But if you count the hex digits in your image, you come up with 32 of them: 128 bits.

Those 128 bits are an MD5 hash of the public key.  The MD5 algorithm is hard-coded in a lot of the code that generates fingerprints for display.

The visual host key algorithm (known as "randomart" in the source), takes that MD5 hash and uses it to trace a path.  As to how "secure" this is, I'll let the source speak for itself:

  If you see the picture is different, the key is different.
  If the picture looks the same, you still know nothing.

Isn't this insecure?  Isn't MD5 insecure?

If I wanted to trick you with a traditional fingerprint, I wouldn't bother with trying to generate a full MD5 collision of a pre-existing SSH key.  That's hard even today.

Instead, I'd generate keys until I found one where the first few digits and the last few digits of the fingerprint matched.  Unless you're very disciplined about validating, it wouldn't matter whether the fingerprint was MD5 or SHA256; your eyes would skim the number and it would look "good enough".  That's what the visual fingerprint is trying to protect against.

If you're paranoid, then don't use any human-verified fingerprint if you can help it, visual or otherwise.  Instead, put a known-good copy of the expected server key in your known_hosts file.

For more information, try:

https://superuser.com/a/22541/57026 -- which includes a link to a paper about the rationale behind the algorithm.
https://security.stackexchange.com/a/73157/14997 -- which includes a link to a paper about attacking the algorithm.

How is the picture generated?

Again, from the source:

  The algorithm used here is a worm crawling over a discrete plane,
  leaving a trace (augmenting the field) everywhere it goes.
  Movement is taken from dgst_raw 2bit-wise.  Bumping into walls
  makes the respective movement vector be ignored for this turn.
  Graphs are not unambiguous, because circles in graphs can be
  walked in either direction.

In more detail, the algorithm works roughly like this:

Start in the middle, and use the hash as a kind of treasure map for where to move next.  For each step, take the next two bits in the hash.  00 means move northwest; 01 means northeast; 10 means southwest; 11 means southeast.  Hug the wall if you bump into it.  Count the number of times you step on each square.

Finally, for each square you stepped on, choose a symbol based on the number of times you stepped on the square, from the following list of 14 symbols: .o+=*BOX@%&#/^.  (That's 15 symbols total if you include "" for unvisited squares.)  Mark your start and end points specially, with an S and an E, respectively.


Soundness of GRC.com Haystack padding concept

Of course entropy theoretically makes a password stronger but from the perspective of a password cracker the first password likely would take much longer to crack. This is because of the length of the password--this argument would probably not be valid with a short password. It is something I have written about before myself

Consider how password cracking software attacks a password:

Try all words from a massive dictionary of words including common passwords.
Try common permutations (password1, password123, p@assw0rd, drowssap, etc) of each dictionary word.
Brute force every password trying every possible letter combination.

As long as a password doesn't fall under the first two categories and the software must perform a full brute force, the first password is strongest because it is one character longer and yet utilizes the same keyspace (upper, lower, numbers, and symbols) as the second password. The first password is 24 characters long and therefore potentially has 95^24 (291,989,024,338,773,000,000,000,000,000,000,000,000,000,000,000) possible permutations. The second password has 95^23 (3,073,568,677,250,240,000,000,000,000,000,000,000,000,000,000) permutations. As you see, that 24th character makes a huge difference.

In practice, if the password was ....g..................... it would likely take much, much longer to crack than the other two because even though it just uses two a lower case letter and a symbol, the password cracking software would still attempt using uppercase letters and numbers and it is two characters longer. Keep in mind, however, that if a bunch of people started following the concept of padding then it wouldn't be difficult to build password cracking rules to try padding all passwords. You are better off mixing the padding throughout the password, alternating multiple characters, or simply adding a couple more semi-words to your password.

When it comes to passwords, lack of entropy and lack of character sets can always be made up for by increasing the length of a password.

Nevertheless, having said all this, you still need to be smart and not reuse the same password or even the same pattern on multiple systems and you really should only rely on stuff like this in cases where you have to memorize a password. Using a password manager with a random password generator is still the best practice to follow.


Do the Linux binary blobs contain any intentional security holes?

The problem with an intentional security hole is that it looks exactly like an unintentional one.  A well done attack shouldn't be detectable as anything more than a coincidental error.  It is really a your guess is as good as anyone else's type scenario.  Best practice if you need a high level of security is to firewall your system to prevent external access and control what it can send out.  It at least limits the possible damage of any kind of breach, including much more likely malware threats, since even if the NSA did put in a backdoor, they are most likely not going to use it on you.  It's still a vulnerability that exists, but it isn't inherently any more of a threat than any other unknown vulnerability that may be in some zero day war chest somewhere.


Client side measures are only a partial (and mostly cosmetic) solution, this can only limit non-serious attempts. Any serious attempt will either hit your server directly because a login URL/API was detected, or will run your client through an intercepting proxy to capture the details required to create a brute force run.

Robust defences generally require you to assume that the attacker knows everything about the system except the secret key (Kerckhoff's Principle) so you should start from that position.

Mitigating measures include:

make it hard/impossible for an attacker to determine valid user names, invalid passwords or locked out accounts (basically minimal feedback, i.e. no "invalid username" or "password too long" messages, though issue a unique incident code if this is important for user support). As noted in the comment by My1, open registration may be a weak point here.
make it hard to determine anything other than success or failure, a failed login should take the same time as a successful one — this usually means making both artificially long (200ms is a starting point)
make the login API multi-step using a nonce or some time- or session-based token to complicate automated attacks, and prevent distributed attacks; or add some client-side proof of work (client side password hashing is one option, but needs careful consideration)
make sure the password space is sufficiently large, encourage (and support!) the use of a password manager
use account lockout and source IP lockout with exponentially increasing lockout times (e.g. double the lockout time on each failure, this should avoid annoying a user who gets a password wrong a couple of times). As noted in the comments, this is an opportunity for DOS, so consider the tradeoffs carefully
implement adaptive rate-control and malicious activity detection (this is generally harder than any of the other solutions as it requires additional state and logic on the server side)
consider adding an "under attack" mode of operation that can be enabled as required, ideally this will have minimal impact on users

From CAPEC-112 Brute Force:

  The key factor in this attack is the attackers' ability to explore the possible secret space rapidly.
  While the defender cannot control the resources available to an attacker, they can control the size of the secret space.
  The defender must rely on making sure that the time and resources necessary to do so will exceed the value of the information.

See also CAPEC-49 Password Brute Forcing


What are the techniques to detect malware call home/beaconing activities?

There are a number of ways to do this, largely depending on the logs available, the exact nature of your network and the strain of malware you're infected with.

Malware can and will use your proxy, it can and will use your nameservers, it can and will run under the context of a normal user.

If you're effectively going in blind, with no indicators of concern, you could use the below to pick out potential malware traffic;

Web traffic to a domain no other device is communicating with
Web traffic to domains with known risky TLDs (.top, .gq for example)
Large amounts of DNS traffic originating from a user endpoint
Periodic traffic which calls out with a precise interval
Proxy traffic on odd ports
Proxy traffic which remains out of hours
HTTP traffic with commands within the URI (i.e, a web shell)
Unusual user agent strings


Is there a Cipher Suite which is only "good" when used with HTTPS, but not "good" with other protocols?

Some attacks (e.g. BEAST, CRIME) are only effective against HTTPS.

Not really. The underlying problems of ciphers or of use of compression are not specific to HTTPS, only some features of HTTP made it possible to exploit these problems because you were able to add chosen plain text to the encryption etc. You might find exploits for other protocols which are based on the same ideas.

  Is there any "good" HTTPS cipher suites (i.e. ChaCha20-Poly1305, AES-GCM, ..) which is not "good" for other protocols like IMAP, SMTP, SSH, etc.?

Based on what I wrote above the question would not be if their are any good ciphers for HTTPS which are bad for other protocols. Instead you might ask if their are any ciphers with known problems, where these problems can not be exploited by HTTPS but can be exploited with other protocols. Since typical attack methods like chosen plain text are probably easier to do with HTTPS than with other protocols I would say, that ciphers safe for HTTPS are probably safe for other protocols too, at least for the common protocols you've mentioned.

But you might also ask if you could construct a protocol in a way, that even the protection offered by good ciphers can be evaded. I'm pretty sure that you can do it and there might be protocols or applications out there which do this. But this is not the problem of the cipher or of TLS, but of the usage. Check out Timing Analysis of Keystrokes and Timing Attacks on SSH or I Know Why You Went to the Clinic:
Risks and Realization of HTTPS Traffic Analysis for examples what kind of analysis could be done even if the ciphers itself are fine. And you could definitely design protocols in a way which accidentally make these kind of side-channel analysis even easier (but also which make it harder).


Login with a hash. Is this secure enough?

For the level of security that your service sounds like it requires, I'd say that this sounds like a reasonable solution.

The risks are that someone will intercept a link and get access to the customers information, so you should make sure that access to the status page is encrypted via SSL.

For the timeout you could either go with the approach that you've got (time-based) which seems reasonable under the circumstances, or you could set each hash to only be used once (i.e. the hash needs to be re-created each time the customer uses it)

An alternative that I've seen used for this kind of system which is somewhat less secure but easier for customers to use, is to request information about the order (e.g. Order ID, customer surname, customer postal code).  This gets rid of the e-mail step, but is susceptible to a brute-force attack.

How secure you want it largely depends on how sensitive the information is and how annoyed the customers would be if someone else gets access to it.


Firefox (fixed in Nightly 59.0a1), Safari (fixed in Safari Technology Preview 54), Edge, and Internet Explorer display an authentication dialog if you request an image and the server asks that you authenticate with HTTP Basic authentication. This allows an attacker to display an authentication dialog when a user's browser tries to load the image:

Firefox. Fixed as of Nightly 59.0a1, but the warning present in latest stable release:

Safari. Fixed as of Safari Technology Preview 54, but the modal is still present in the latest stable release. Note that it's a modal dialog and the rest of the website is grayed out. "Your login information will be sent securely" is also technically true but may give a careless user the wrong impression:

IE11. A native Windows dialog locks up the whole browser:

If you make the realm a really long string of a\ta\ta\t...a\t, IE11 completely locks up.

A well-chosen domain name and realm can trick users into sending their usernames and passwords to an attacker's server, or make your website completely inaccessible.


What happens if biometric data is stolen?

The answer depends a lot on your use case. Are you using a biometric to authenticate yourself to a remote HTTP server? Then if someone steals a binary representation of your biometric, they will be able to log in as you. This is why we like moving to 2-factor authentication instead of a single factor.

An example would be something you are (your fingerprint, or a digital representation of it) and something you know (your password).

If you are doing local authentication, the story is a little different. Attacker's options are: cut-off your finger and take it with them (see Minority Report where he used eyes instead of fingers), get a scan of your finger and try to replicate it on something the scanner will be able to read, or connect something between the reader and the computer doing the processing.

Even for local authentication, 2-factor authentication is often used. Your fingerprint scan might pull up a picture of you on the security guard's computer. Or a fingerprint and a PIN.


How to best educate users on telltale signs of malware infections?

I would question the value of anti-malware software which cannot detect unusual behavior and why other layers of defense are not detecting attacks. For the list you proposed, there are legitimate reasons for most of those things to occur, so I would not expect an end user to think they should report this as malware. You could find or write a tool that detects and reports on these scenarios (e.g., HIPS, IDS/IPS, stateful firewall, etc.).

Perhaps the more reasonable scenario is the user contacts IT for weird behavior and IT does an investigations, malware scan, etc.

End users should be your last line of defense (The military does not rely on school teachers instead of intelligence agencies). Reliance on end users usually indicates insufficient technical controls. Most organizations do not deploy anything beyond spam filters for email and emails are designed to be something end users interact with on a daily basis. I would be surprised if end users event know how to monitor utilization or what a hosts file even does or where it is located.

An important thing to consider with the rise of phishing simulation and testing it the market/vendor effect. Phishing simulation is pretty much the same as sending marketing emails with tracking links, its not super complicated software to write and the sales pitch is relatively easy.

At a higher level, a drill is a good thing to test, but you should focus on your response from the IT team, not end users as a KPI. For example, how quickly can IT identify and quarantine a machine are they asking the right questions to determine if there is malware and investigation is necessary or are they just trying to close out ticket as quickly as possible?

If you want to test your malware response from end-user reporting and IT follow-up you can use an EICAR test file.


Dealing with an insider threat in an insecure environment

If IT security is not your job, stop right now. Report on the official channels and move on. This is the standard procedure. Messing with the miner or doing your own investigation may create evidence against you.

Report and have IT lock down the affected machine to start an official investigation. Or you risk being accused by the attacker of installing the miner yourself and trying to frame him.

If you company is a small startup, you need permission from someone. Call the owners or the ones in charge, show them what you found and ask permission to investigate.

Shutdown the server in front of them, boot a live distro, and take a image of the disk. Hash it, and send them the hash (to prove you haven't tampered with it) along with the image size, and a list of files on the disk before you start working. Mount the image read only on your computer, and create a detailed report.

With this, you have witness backed evidence.


Is it a security issue that Thunderbird only logically deletes emails?

Logically deleting is very common in many application that handle huge amounts of data for performance reasons. This includes other email programs for example Microsoft Outlook and even database servers for example MySQL.

Even files, that you delete from your hard disk, are not actually destroyed. The space is just flagged as empty and may be override in the future.

In Thunderbird, compacting folders will get rid of those deleted emails. At least for me, Thunderbird regularly asks me whether I would like to do that.

I consider this problem a minor issue because an average user may not be aware of it.

An attacker needs read access to the storage folder in order to exploit this behaviour which is one of the worst case scenarios to start with. If you are concerned about theft of your notebook or other forms of illegal physical access, encrypting your hard disk may be better approach.


Managing/Deploying a code signature certificate - Java Applet

Best way seems to use a code signing certificate from a well-known CA. Since well-known CA certificates are already trusted by Client (browser, OS), there is no need for additional maintenance with this setup.

Java Applet & Web Start - Code Signing states that

  ...Users will be better protected by maintaining up-to-date versions
  of the JRE on their systems, combined with requiring code that is
  signed by a Trusted Certificate Authority (rather than self-signed or
  unsigned code)...

  ...self-signing is primarily of value to developer and intranet
  applications as it also requires managing the keystore for Java...

When using a certificate from CA, renewal poses no problems, we may just sign with renewed certificate. Trusted timestamping, while adding complexity, allows Clients to validate your signature even after your signature expires, given that it had been valid during signing operation (see Signing code for the long haul).

Certificate revocation is checked using Online Certificate Status Protocol (OCSP) at the Client. For details please see Revocation Checking for Java Applications section here.

Nonetheless, there are many large enterprises who manage an in-house CA, primarily for issuing server certificates. If such an infrastructure is already in place, we may assume that internal CA certificates are already being distrubuted to Clients in one way or another, for Clients to be able to trust the servers. If this is the case, issuing code signing certificates from the same CA may not cause additional administrative overhead.