Other Software > Developer's Corner

Essays on Proper Storage of Site Passwords

<< < (3/5) > >>

db90h:
Well, thanks. I dunno if someone has done it before or not, but it seemed the only way to do it without waiting for users to log in. Necessity is the mother of all invention and such. I'm sure others have done the same.

While reading those articles, the premise of what I'm doing is very similar to what they suggest with, say, PBKDF2 ... That algorithm apparently iterates the hash in a similar fashion, X times. Now, they are not rehashing the *plaintext representation of the hash*, and instead are rehashing the last iteration, but I think the result is similar if they increase the iterations of the hashing algorithm. Of course, they go through far more iterations, making it more secure... except that it is not clear if they allow for multiple algorithms to be used.

Of course, PBKDF2's intention isn't to allow instant updating of a database, but to provide strong initial security.

In my case, I actually did change the database field, just to be sure and certain of which password hashes were updated (since I didn't initially do it all at once, but later did). So, while not storing metadata, I did implicitly give an indication of which accounts had been updated to the new algorithm.

TaoPhoenix:

Bruce Schneier posted an article somewhere on his blog about double-layering of different algorithms on top of each other. Last I recall you added a couple of new corollaries.

db90h:
Bruce Schneier posted an article somewhere on his blog about double-layering of different algorithms on top of each other. Last I recall you added a couple of new corollaries.
-TaoPhoenix (June 13, 2012, 06:23 AM)
--- End quote ---

I figured SOMEONE had done this before, as it is the ONLY way to INSTANTLY update an entire database. Still, sometimes the most simple things are overlooked. I don't know whether he was mentioning this as a method to improve security or update a database, but still.

After reading this thread, I'm actually going to go ahead and take it another step further and add one or two more algorithms on top.. and that's the beautiful thing, how far it can be extended (infinitely). So long as nobody gets access to the code, they'll also not know the algorithm.

mouser:
I'm always a bit weary of layering stuff like this though.. all it takes is one bad hash algorithm that by accident maps all inputs into a small hash space and you are in trouble.

TaoPhoenix:
If my ailing memory serves, he was definitely remarking on the security side, I think it was in relation to the data - I don't recall speed considerations.

But heh I think I also walked into the "obscurity" theme a while back - that's one of those topics where it protects lower level situations and it is somewhat useful, but I learned that you have to assume that the algorithm could be discovered.

Re: Mouser, you were talking about the damage level of a breach of LinkedIn. I think it's worse than it sounds, because it's a dangerous Phish opportunity. I am grumpy at LinkedIn because they *already* turbo-spam people's addressbook - I got two separate ones and that's from normal accounts. Give attackers an hour logged in and all kinds of fun could happen.

Navigation

[0] Message Index

[#] Next page

[*] Previous page