31–40 of 144 posts
Earlier quoted context omitted.
It's pretty easy to migrate users from one hashing algorithm to another when they next log in: if( user has an old style hash ){ if( password verifies against old style hash ){ add a new style hash delete the old style hash log them in } } else { if( password verifies against new style hash ){ log them in } }
You mean you're sending unhashed passwords from the client?
BTW COTS means Commercial off-the-shelf. (I've always known that abbreviation as just OTS, and was trying to figure out if the C stood for "Custom".)
BTW COTS means Commercial off-the-shelf. (I've always known that abbreviation as just OTS, and was trying to figure out if the C stood for "Custom".)
Earlier quoted context omitted.
Such a toolkit would probably be a good idea. Tie a card-carrying cryptographer to a chair until he delivers it ?
>Tie a card-carrying cryptographer to a chair until he delivers it ? Alternatively, implement it very, very simply and put it on github, and ask card-carrying cryptographers to vet it. That one is harder on the ego though.
Earlier quoted context omitted.
One, often over-looked reason, that website designers chose simple MD5 or SHA1 hashing (and why many still do) is for portability. Years ago this was more of an issue than it is today. They may wish to change web frameworks, programming languages, service providers, etc. and when doing so they want a simple, easy way to use the hashes they have. Also, many big service providers still use MD5 or SHA1. I saw a company…
It's pretty easy to migrate users from one hashing algorithm to another when they next log in: if( user has an old style hash ){ if( password verifies against old style hash ){ add a new style hash delete the old style hash log them in } } else { if( password verifies against new style hash ){ log them in } }
Earlier quoted context omitted.
One, often over-looked reason, that website designers chose simple MD5 or SHA1 hashing (and why many still do) is for portability. Years ago this was more of an issue than it is today. They may wish to change web frameworks, programming languages, service providers, etc. and when doing so they want a simple, easy way to use the hashes they have. Also, many big service providers still use MD5 or SHA1. I saw a company…
" … at that time, Google accepted hashes in two formats only... MD5 or SHA1." That's, ummm, _concerning_… I don't suppose anyone knows how securely Google are storing my gmail password? I _hope_ it's not unsalted MD5 or SHA1. (Especially since google search is probably the best general purpose md5 hash reverser most people have access to.)
Earlier quoted context omitted.
" … at that time, Google accepted hashes in two formats only... MD5 or SHA1." That's, ummm, _concerning_… I don't suppose anyone knows how securely Google are storing my gmail password? I _hope_ it's not unsalted MD5 or SHA1. (Especially since google search is probably the best general purpose md5 hash reverser most people have access to.)
Google could store passwords in plain text if they want, because they're never going to leak. I'm only partially joking.
Earlier quoted context omitted.
You mean you're sending unhashed passwords from the client?
Yes. That is the standard behaviour that nearly all sites use, and is perfectly fine.
Edit: there's more detail at the link below. It looks clear that in at least some of their schemes they deliberately do not send the client password to the server, which sounds like a decent idea.
http://www.skullsecurity.org/blog/2012/battle-net-authentica...
Earlier quoted context omitted.
You mean you're sending unhashed passwords from the client?
How many web login forms (as an example) are doing client side hashing? The only ones I know are of the recent 'test your password in the linkedin leak' variety. How do you degrade for NoScript users? And where's the harm in that anyway (assuming TLS)?
Of course, if you're salting the hash uniquely for each user, then this approach isn't very helpful.
Finally, if your server will accept hashed passwords, then getting the hash is as good as getting the password for access to your site. The only benefit is that the password is hidden so you may avoid compromising security on other sites.
The app provides a fixed 'secret key' that defines (somehow) a sequence of hashing and scrambling functions to apply to the password. So, for example, the secret key "df8dfuhuejew3" (or whatever) might be interpreted as '3 iterations of md5 hash followed by rotate hash 5 places to the left followed by 2 iterations of bcypt etc..'.
So, in effect, each app (with a different secret key) will have a different hashing process, but with the advantages that its repeatable and cross platform (reference implementations could be available in the major languages).
Of course, if your secret key is hacked you are in trouble, but at that point the hacker can probably get your source code for whatever hash system you use, and anyway, the combined hashing process is probably slow enough to prevent brute force attack.
Any thoughts?
Edit: Probably better to just use bcrypt with a larger work factor.