A mode for password hashing
bramcohen.com
bramcohen.com
> This operation is repeated some number of times until enough work has been done, and then output is extracted. It’s reasonable to set the number of rounds to be be double the number of blocks stored in bulk memory. It might be okay to go far lower, but that feels sketchy. In particular, going lower might result in custom hardware being able to effectively pipeline the next block being uninitialized (which might be able to produce a small speedup on a general CPU anyway, further research needed).
"Some number of times", "reasonable", "feels sketchy", "further research needed"...
> There’s also an encryption function used, probably AES128...
"Probably AES128"... If there's one thing that you shouldn't tolerate in security, is relying on your feelings about mathematics. You can DO the math, your feelings on what the result might or might not be are not very interesting.
The scrypt paper does all the research and math that this article doesn't do. It even includes dollar cost estimates for breaking passwords hashed with various algorithms. Yes, the scrypt algorithm itself already does what you need. The paper is highly recommended for developers who ever touch passwords.
http://www.tarsnap.com/scrypt.html
I also consider PBKDF2 acceptable for general password hashing.
This blog post isn't meant to be an in-depth research paper, its tone is more, "hey, I have a neat idea, what does the community think?"
Just some people are more precise at writing, and offer better mathematics than other people.
The concept is similar to SCrypt. He wants to utilize a memory-hard problem to make the difficulty of creating ASICs more difficult. However, this blog post has no ideas on how VLSI circuits work, nor any crypto calculations, nor any math or proofs that describe his thoughts.
He has a supposition: that using maybe AES (or any block cipher) as a random-number-generator, he can randomly traverse memory to increase the difficulty of hashing. (I'm assuming he's just using any ol' block cipher for this process). He leaves a component of the calculation in one memory block to keep it "inside the cache", presumably to keep it working quickly on modern CPUs.
Maybe. I dunno. He has no example code, which makes this sort of thing _very_ hard to discuss. I don't even know if I'm reading his post correctly.
But assuming this is how he's doing it (and mind you, I really don't know what he's talking about because he's so imprecise), my $0.02 of "serious" criticism is that its not obvious that these calculations cannot be pipelined and simplified in an ASIC or FPGA... at least any more than SCrypt (or BCrypt) was.
And remember, SCrypt has ASICs coming out of the pipeline, and also ended up being much much faster on R9 290x GPUs than your standard CPUs.
Honestly, the X11 proposals from the alt-coin community are better researched and more precise than what this blog-post proposes. This proposal here is so obscure and wishy-washy that I can't even discuss its merits.
You shouldn't and I'm not saying you should. I'm suggesting everyone is taking this more seriously than it needs to be.
"Might be a novel idea, here's some things to consider, needs work," is appropriate.
But this idea is clearly stuck in rough draft hell and needs some serious fleshing out before everyone pulls out their magnifying glasses.
Going balls-to-the-wall with scrutiny and criticism before it's warranted does nothing constructive and only discourages people from tinkering. Bad for the community, etc.
The idea is that you have a passwords table and whenever someone sets a new password / registers, you insert something like "hash(userid + password + salt)" into the table. There is no link between the account and hash, when the user logs in, you need to check the existence of the computed hash on the table. If someone dumps the database, at best, they have some password hashes with no way to connect them to user accounts.
Password changes would require asking the old password but I guess there is no way to implement 'forgot password' functionality here? How would you invalidate old passwords?
Is this something viable? Anyone uses anything like this? I thought about adopting it on some new auth systems we are working on but losing password recovery is downer.
edit: Changing the salt on account information would take care of invalidating old hashes I guess..
Even if all of these fancy hashing algorithms are implemented, it only makes it slightly more difficult to crack weak (common, short, dictionary word) passwords.
Any chance you would have time to elaborate a bit? I like the idea of having a table full of hashes with no (clear) link to accounts.
Password table has one column: hash(userid+password+salt).
Login process: given userid and password, look up salt. Check if hash(userid+password+salt) appears in Password table.
Password reset process: Given a userid and new password, change salt to a new random value and save to User table. Insert hash(userid+new_password+new_salt) into Password table. The old hash remains in the Password table and could still be used to log in, but in theory is useless because the salt has been destroyed.
Implementation detail: Make sure the old salt really is destroyed.
EDIT: After thinking about this, I think the reason not to do it is that it doesn't really win you much protection over the usual approach -- a single table with userid; salt; hash(userid+password+salt).
In that scenario, if your database is stolen then the attacker will have to brute force each user password individually and compare it to the stored hash for that user. You hopefully used an expensive hash() algorithm so that will be a slow process. The only thing the separate table adds is an extra table lookup during each brute force attempt, which compared to the cost of hash() is basically free.
So yeah, I don't think this really gets you anywhere.
EDIT2: In fact, you get almost exactly the same effect by making your bcrypt()/scrypt() parameters one notch harder. Crypto primitives FTW.
http://opine.me/a-better-way-to-store-password-hashes/
http://opine.me/all-your-hashes-arent-belong-to-us/
http://ethanheilman.tumblr.com/post/28481738192/security-thr...
If the hash is stored independently in another table as you suggest, then an attacker attacks each account by performing the hash on each potential password and checking to see if it is in the set. If that set is small enough to fit in memory (and they could likely store billions) then a simple contains check doesn't buy you very much. It is simpler to raise the work factor of the hash.
If someone is using dedicated hardware it may make it a bit trickier to implement, but it also makes things trickier for you to manage. Better to use a hash designed to thwart such an attacker (like scrypt) up front.
In any case, one can seed the hashes table with a couple billion random hashes, making the lookup slower for both parties. It would hurt the attacker more, given the nature of brute force.
The first thing he would do is a dictionary attack from a list of common passwords: Pick one user, create the hash and search the hash table for a match. That is one step more than only having to check the hash in the same row. I'd say it is slightly, but not significantly, more difficult.
Now I am going to mention something that will be very unpopular, but it is 100% true, so try to open your mind a little before reading.
Let's compare not hashing, the worst hashing algorithm, and the best hashing algorithm. The worst will be something like MD5 with no salt, and the best using the most advanced hashing, random salts, and CPU-heavy calculations. We'll compare the effect of database compromise by a cracker on a user with a weak password (4-character dictionary word) and one with a strong password (15-character random a-Z, 0-9, and symbols)
* No hashing - weak: cracked; strong: cracked
* Worst hashing - weak: cracked; strong: safe
* Best hashing - weak: cracked; strong: safe
The best hash will protect more medium strength passwords than the worst but there is no hashing algorithm strong enough to protect the weakest passwords, and MD5 with no salt still protects the strongest.
But there are other benefits of using any hashing over none: It protects your users from yourself and other admin-level people on your team and guarantees that your application cannot expose plaintext passwords even after you leave the project.
tl;dr The difference between no password hashing and weak password hashing is significant and the difference between weak hashing and strong hashing is small.
Hashing is just a stopgap measure that hopefully gives your users time to do something before they're compromised. It's hard to say how effective it is in practice when a new db dump goes to auction.
A password function is the last line of defense, and never foolproof. Looking at the history of successful password exfiltrations over time, attackers have about a month or two before somebody notices they got away with your data. So your password functions should ensure that passwords are strong enough that with current-day technology they can withstand at least that much time out in the wild; otherwise, don't even use a hash.
Judge it on its merits, if any. If we can't poke holes in it, then maybe its worth those same people's time to look at.