That is exactly what bcrypt does - it hashes with a salt. It seems though that I misinterpreted what you were trying to say. If you wanted to revise that statement that created this misunderstanding than I believe we’d be in agreement.
See:
As the code and accompanying text shows, I’m discussing adding a workload factor to fast hashes like SHA1 to get the varying ‘proof of work’ of bcrypt, whilst explaining how the combination of a plain salted-hash of a fast hash means it’s easily cracked - without the use of rainbow tables, because they are, for all the reasons decribed above, an infeasible solution to cracking passwords. Anybody still using them should be fired for wasting resources.
I didn’t read your entire post because of that insane initial statement that I wasted several minutes arguing. You can at-least appreciate why I would be so quick to correct that initial statement (which is albeit still wrong regardless of the contradictory accompanying text.)
But whatever - no point arguing over that - it seems we’ve come to an agreement.
I still stand by that statement. It’s written within a context. Pulling things out of context is a common cause of argueing.
You made two highly contradictory statements - I would suggest you revise your incredibly misleading initial statement unless there is a particular point to it - it adds absolutely nothing to your argument.
Excuse me for finding an article which seemed to argue salts in passwords are pointless not worth reading.
But if the password database leaks, someone has everyone’s passhashes (and none of their passwords) and can log in as anyone and cause chaos without even needing to fire up a GPU hash cracker. It’s even less secure than unsalted SHA.
The passhash itself is not stored as-is in the database, it is salted.
Table: Account [username, salt, saltedpasshash]
saltedpasshash = hash(hash(salt)+"::"+hash(passhash));
passhash is generated clientside, using hasher that takes ~1s
Password crackers don’t stand a chance against the 5 (or more) orders of magnitude increase in computation time to bruteforce the password, OR to generate the user’s passhash (20 bytes of absolutely random data).
Good thread, nice linked articles and posts. I think I’m going to incorporate some horse battering into my passwords.
Here’s a short video series that gives a nice entry into cryptography. I remember I liked it a lot when I first dipped my nose into what the hell cryptography is all about.
So server has salt, hash(hash(salt)+"::"+hash(passhash)), challenge, and needs to verify submitted value of hash(passhash+"::"+hash(challenge))? That doesn’t seem possible unless the hash is open to being extended in both directions.
Hmm?
Client sends passwordHash.
Server salts the password it received from the client (passwordHash + salt) and compares it to the stored value (which is salted aka passwordHash + salt).
Seems OK to me.
The nice thing of a hash challenge is that the ‘shared secret’ doesn’t go over the wire - whether that is a password or passhash doesn’t matter. The shared secret shouldn’t be revealed to a man in the middle, as that allows a replay attack.
Also:
YEBfamv-_do
And:
dleUxfghd5I
I have done it as Riven described for a few years now. Hashes need to be fast. If you want them to go slow, do it a million times. Or a billion. There has been some papers on using hashes in a way that current GPU’s (and bitcoin) hardware would be slow at. Typically something that requires a lot of branching. No idea of the security communities response.
Of course you don’t need much to be pretty good for online only attacks. But these days every expert are calling passwords broken in the offline attack vector.
Securing a server these days is not easy if you don’t know what your doing. Anyone who says different is lying or ignorant.
Then there is this https://xkcd.com/792/.
I forgot to add that the server sending the salt to the client is part of the hash challenge.
Both parties can calculate the shared secret (saltedpasshash) and therefore the answer to the hash challenge.
A MITM attack would be successful if the passhash is intercepted during registration and the salt is intercepted during the hash challenge. That’s why registration has to be done over a secured channel, while there is no such need for the hash challenge, nor for any further communication using nonce-based access tokens.