Ask HN: store password - no hash, but aes | Hacker News Reader

Ask HN: store password - no hash, but aes

2 pointsaw4y8 comments

It's just an idea....what's your opinion?

Instead of using md5 and similar (too fast to calculate, and rainbow tables attack too - if not salted) my idea is:

-create a cleartext (even public); -use the password you want to store to encrypt this text, using aes256 for example; -save the encrypted text;

verify your password (on user input) encrypting the clear text and checking if it matches with stored encrypted password.

Pros: -it's more slow to calculate (and so less easy to brute force) -being the cleartext different on each "server" there's now way to have a rainbow table!

opinions? cheers, aw4y

View on HN

So basicly using AES instead of md5 is what your saying.

Though what your doing with the plaintext that is encrypted is iin effect adding a salt that actualy allows easier brute forcing as it does not compliment the the encryption but offers a fixed point ability to verifiy that you have broken the password.

Also AES256 isn't imune from being brute forced, not nth bit encryption is imune.

But remember that any password used on the web is only as good as the transport layer used to convey it and in that you could have the best encryption in the world, but when it is entered via a http connection in plaintext it becomes moot and when it is via https, then it is down to the encryption used for that connection.

Security is often the longest path to the weakest link and that sadly is still a weak link - some call them users, some call them bad passwords and some just call them and ask them for there passwords!

Summary: you have taken the salt aspect and made it a public cleartext password whilst at the sametime removing the extra entropy it affords. You could probably get a job at Linkedin though as you have done better than they did.

but the salt is not known?

https://www.owasp.org/index.php/Hashing_Java

"A salt is a random number of a fixed length. This salt must be different for each stored entry. It must be stored as clear text next to the hashed password."

the only difference I see it that the salt is different for each password, instead my "solution" uses a cleartext for all password...am I wrong?

A rainbow table would still work if you're using one clear text per server, I just have to build the table per server. The reason salts remove rainbow tables as a way of attack is that they're different per password, so I'd have to build an entire table just to crack one password. If I'm doing it per password there's no point in saving the table, I can stop once I've found the matching password. If I have a whole set of hashes which share the same salt though I can build a table and crack more of them at once.

I was just about to point out the known-plaintext scenario of this setup when the server is compromised, but apparently AES is immune to this attack. [1]

[1]: http://en.wikipedia.org/wiki/Known-plaintext_attack#Present_...

I don't believe it. If you have a text of say "WIBBLE" and thats encrypted and thats all you have, then you can run thru every permutation(brute force) and compare until your decrypted text matchs the known text. No shortcuts to this, but still brute/rainbow realms.

brute works (but slowly?)...rainbow should be created on cleartext basis...change the cleartext and trash the rainbow!

AES is not significantly slower than a salted hash and so this does not overcome the problem of JtR style attacks. See for example: http://www.cryptopp.com/benchmarks.html

Reply on news.ycombinator.com