-3

I've got a totally theoretical question to you on today - what is the "best" practice for storing passwords? [Best in terms of security and performance]

Usually, especially PHP-Developers tend to store user credentials either in plain text or as hash, using MD5 or SHA1 and their successors. The more clever web developers and software cooks even add some salt to the password before hashing.

Android Developers usually seem to store in plain text, as far as I have seen it until yet, naively relying on the user rights concept of android, even arguing that rooting the devices the user's own fault.

There are lots of different practices out there. Plain text for those applications, where the developers either rely on platform security or want the user to recover their own password. Hashing where developers rely on the integrity of their hashing algorithm, ignoring collision attacks and so on. Salted Hashings where developers read that plain hashing is a bad thing because of rainbow tables. There are even some developers out there who use real cryptography, but usually the key is somewhere recoverable.

My idea was to use AES (or [still not broken] symmetric cryptography in general, like blowfish and so on), crypting the padded password (for hiding the password length) with some salt prefix. The Key would be the users password, which should make it impossible to recover and verifying the password without the password.

I wonder why the usual practice differs from that idea - so where's the fault? The complexity shouldn't be that much high, because there are good implementations of AES out there, even hardware implementations. There are no hash collisions possible on this.

So am I right that no one could use a data dump with those passwords for anything other than bruteforcing? [Of course there are other attacks, which are regardless of the back-end password storage, those are not topic of this question]

May it be that this idea is pretty similar and related to bcrypt, but without multiple iterations?

pmedia
  • 113
  • 2
  • See http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords – Shnatsel Feb 10 '13 at 23:33
  • Please don't be a Dave and try to design your own hashing schemes. Try http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords – Lucas Kauffman Feb 10 '13 at 23:33
  • This is a question from StackOverflow about [how to ethically store passwords for later plain-text retrieval](http://stackoverflow.com/questions/2283937/how-should-i-ethically-approach-user-password-storage-for-later-plaintext-retrie) (it has 593 upvotes currently). – gloomy.penguin Nov 12 '13 at 20:37

2 Answers2

7

Good practice is not to store the passwords but something which is used to verify a password. That's called hashing.

Your proposal is just a custom hash function wrought of AES, which was not meant for that. Custom, homemade cryptographic algorithms are the bane of security. Stop it. Resistance of AES as an encryption function says (almost) nothing about its resistance as an element in a hash function (except for that weird thing called related-key attacks which do not matter for encryption, but can kill a hash function proposal, and AES is somewhat flimsy in that area).

Your idea is pretty similar to bcrypt except that it avoids all that actually makes bcrypt a good algorithm, i.e. the configurable slowness (the "iterations") and the salt, both of which being important for security.

Collisions have nothing to do whatsoever with security of password hashing schemes. These work on resistance to preimages.

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475
4

You've basically proposed making a one-way hash from a block cipher using the scheme:

H(x) = AES(x,x)

What's wrong with it? Everything that's wrong with just using a standard hash function, like raw SHA-*, plus the fact that it's a custom design. At best it doesn't improve on a normal hash function, at worst it has some flaw that a standard hash function would not have.

(Note that there is nothing inherently wrong with designing hashes based on block ciphers. It can be done, although I'm not endorsing the proposed scheme here.)

At a minimum, password hashes need to be salted to prevent dictionary attacks, and have a scalable work factor that allows the hash to make the attacker expend a configurable amount of energy doing their attack.

B-Con
  • 1,832
  • 12
  • 19