0

We use PGP for almost everything and it's so infeasible to bruteforce that it's considered secure. This is the guiding principle beyond CryptoLocker. But for stuff like e-mail, SSH and HTTPS, it's still considered secure even though the computational cost of encryption should be low since these are common tasks that have to happen millions of times a day. Now if an encrypted password with strong encryption is out in the open the attacker can't do nothing to it. But a hashed password is vulnerable - it can be bruteforced. So is there a password policy that can make encryption of a password with strong encryption secure? Can a user use his PGP keys to encrypt the password before sending it to the server? What about end-to-end encryption?

  • 4
    Passwords are encrypted when sent over a connection. They aren't stored on the server encrypted because then you would need to store the key somewhere, which could be leaked. There is no key to leak with hashes. – PyRulez Feb 16 '16 at 2:26
  • @PyRulez Why would you ever need to do that? Passwords shouldn't be unencrypted. – user101387 Feb 16 '16 at 2:31
  • 3
    if you can't keep the password files secure, you can't keep a key secure. – PyRulez Feb 16 '16 at 2:33
  • 2
    Answer to title question: Because it's reversible. – Iszi Feb 16 '16 at 17:24
  • @Iszi Not without knowing the password if you use a password derived key to encrypt it. – inf3rno Nov 17 '17 at 6:11
14

Properly hashed passwords

  • Web app stores the salt and result hash and iteration count (PBKDF2/BCrypt/SCrypt, crypto random salt, high iterations/work factor).

  • To log in, user enters password

    • web app retrieves salt and iteration count and result hash

    • web app hashes entered password with salt and iteration count, compares result. If same, is OK.

    • an offline attacker with a copy of the database can AT BEST get only those passwords that the attacker guesses

    • Said offline attacker gains NO ADVANTAGE if they steal the web app executable code also

    • Said offline attacker gains NO ADVANTAGE if they steal the web app source code also

    • Said offline attacker gains MINIMAL ADVANTAGE if they steal every other piece of data the web app can access, since they'll be able to use names, family member data, addresses, etc. to help guess passwords for people who use those to construct their passwords.


Properly encrypted passwords

  • Web app stores the IV and result encrypted PW in DB, and key in some other key storage (AES/Camellia/Aria).

  • To log in, user enters password

    • web app retrieves IV and key and encrypted PW

    • web app decrypts encrypted PW with IV and key, compares result. If same, is OK.

    • an offline attacker with a copy of the database of IVs and encrypted PWs can AT BEST get only those passwords that the attacker guesses the key for

    • Said offline attacker gains POSSIBLE 100% OF ALL PASSWORDS DECRYPTED if they steal the web app executable code also, if that's where the keys were

    • Said offline attacker gains POSSIBLE 100% OF ALL PASSWORDS DECRYPTED if they steal the web app source code also, if that's where the keys were

    • Said offline attacker gains GUARANTEED 100% OF ALL PASSWORDS DECRYPTED if they steal every other piece of data the web app can access, since the web app had to have access to the keys


Other major points:

  • Encryption means anyone with access to the keys, IVs, and encrypted passwords can silently and without trace impersonate any user, there or from the outside, which is generally considered horrifically bad.

  • Hashing renders the strongest cryptographically random, 30+ character passwords virtually immune from being guessed, because they are crypto random with a huge keyspace.

    • On the other hand, encryption renders all passwords equally weak, no matter how strong the actual password is, because all you need is IV and key, and you get back even the strongest password to try on other sites or sell.
  • If you were already going to store encryption keys separately from the actual encrypted passwords, you can obtain superior results in every category by storing the per-user, cryptographically random unique salts separately from the actual hashed passwords.

  • This. This user has "the clue". Pay close attention. – 0xSheepdog Feb 19 '16 at 6:46
4

The core issue with encryption of passwords is not that the encryption can be broken, but that someone with the decryption key can work out what the password is.

Imagine this scenario I start up a web service of some kind and I encrypt the passwords with 256-bit AES encryption and for the sake of an argument let's assume it's implemented perfectly, there are no flaws or side channel attacks, the only way to recover the password is with the key.

So you come and sign up to my service and put in your email address and set your password.

Now I go rogue, or maybe it's an employee who has/had legitimate access to the key, or maybe a hacker who dumped the database also stole the key. Whatever it is, the point is that somehow the key gets out.

Now anyone with the key can see that your email is user101387@example.com and the password you have used is "0pen 5esame" so now I go off to facebook, twitter, instagram and so on trying that email and password[1].

Now if we imagine the same situation but with PBKDF2 instead of AES there is now no key to leak, and while it can be brute forced it will take days or weeks to crack just a few weak passwords. There is no way to decrypt all the passwords at once.


[1] it could be argued that the user shouldn't reuse passwords across sites but this is the world we live in, and most people only have one password that they use everywhere.

  • Also, it gives you some extra time to shut down the server if they only got read access. – PyRulez Feb 16 '16 at 2:34
  • Using one encryption key to encrypt all of the data (passwords or not) is horrible in of itself. My scenario assumes each password is encrypted with its own key that doesn't have to reside on the server. – user101387 Feb 16 '16 at 2:39
  • 3
    If your service gets a million users, are you going to have a million keys? Are you going to manage a million keys? How are you going to manage a million keys? – h4ckNinja Feb 16 '16 at 3:01
  • @Micheal Are you telling me there are services out there that don't manage a million keys? (GitHub is one example, but there are plenty more) – user101387 Feb 16 '16 at 3:23
  • 3
    @user101387 The problem is that your keys must reside on the server (or be trivially easy to access from it), because the server needs them to decrypt the data it works with. – Philipp Feb 16 '16 at 16:50
0

In addition to the good answers here, I also want to say your statement "But a hashed password is vulnerable - it can be bruteforced" is quite wrong as well.

Bruteforce, or better using rainbow tables, is only useful for weak passwords. If you generate a random strong password with enough entropy, its hash probably won't appear in any rainbow table (nor can it be bruteforced in any practical time).

Older algorithms (MD5, SHA1) may have weakness for collision, but as it is a vector that is actively defended against in the design, it is unlikely it will give you too significant advantage in bruteforcing a specific hash (only in rainbow table generation really).

  • 1
    The problem with MD5 and SHA-1 are not their cryptographic weaknesses - they mostly don't apply in the context of password hashing anyway. The problem with them is that they are too fast to compute, so calculating the hash of all common passwords plus the given salt is a viable option. Specialized password hashing algorithms (like bcrypt, for example) are intentionally slow to compute which makes them far harder to brute-force. – Philipp Feb 16 '16 at 22:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.