

Ask HN: store password - no hash, but aes - aw4y

It's just an idea....what's your opinion?<p>Instead of using md5 and similar (too fast to calculate, and rainbow tables attack too - if not salted) my idea is:<p>-create a cleartext (even public);
-use the password you want to store to encrypt this text, using aes256 for example;
-save the encrypted text;<p>verify your password (on user input) encrypting the clear text and checking if it matches with stored encrypted password.<p>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!<p>opinions?
cheers, aw4y
======
Zenst
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.

~~~
aw4y
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?

------
tompko
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.

------
s2r2
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_...](http://en.wikipedia.org/wiki/Known-
plaintext_attack#Present_day)

~~~
Zenst
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.

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

------
jgrahamc
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>

