To confirm a user supplied password matches you run input into the same hash function again with the salt+pepper and compare it to the value in the database.
That way if the database is stolen, the attacker cannot recover the contents of the passwords without brute forcing them. Encrypting passwords is not recommended because too often attackers are able to recover the encryption keys during the same attack where the password data is extracted.
[0] https://en.wikipedia.org/wiki/Bcrypt
[1] https://en.wikipedia.org/wiki/Scrypt
[2] https://en.wikipedia.org/wiki/PBKDF2
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
Hashing passwords has been a thing for at least 50 years now. V3 unix had /etc/passwd which hashed all user passwords. Notably, these hashed passwords in early unix have been cracked: https://arstechnica.com/information-technology/2019/10/forum...
I guess you got your answer.
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
Otherwise, there's a hole, between the end of the TLS connection and where the server-side encryption happens, where the password is in plain text. Think logs and load-balancers and proxies.
While the client-side hashing doesn't help protect your site a lot (as you say, the hashed value the client sends effectively becomes the password), it helps protect the users who use the same password across multiple sites.
Notice in this case, that's exactly what the brothers are accused of doing: using credentials harvested from their site to log into other, potentially more lucrative accounts.
I didn't see if that's the hole the brothers exploited but it very well could have been.
The client-side encryption may have been all that was missing in this case.
Of course performing an additional server side hash on top of the client side one is good defense in depth because there's at least some chance that it might make things more difficult for a rogue insider and doing so costs approximately nothing. But it certainly isn't critical because by the time you're dealing with a rogue insider things are already looking quite bad.
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
Hashing client-side is a good idea. You must also hash server-side, for storage/comparison.
Otherwise, an insider may be able to harvest the original password, from logs, proxies, load balancers, etc. that requests pass through after the end of the TLS connection, on the way to the db.
They can then try the credentials on other, perhaps more lucrative sites. That's what the brothers are accused of doing here, so client-side hashing (or just simple encryption) may have been the missing piece of security that would have thwarted the credential stealing.
This seems to mostly prevent accidental logging and is thus a matter of defense in depth, stopping malicious actors from exploiting it later — but an actively malicious IT person would not be deterred.
Yes, and that's not uncommon, IME. There's generally a lot of logging that's at least potentially available, and it gets turned on, and the logs shared when there's a problem that needs to be fixed (especially when it needs to be fixed quickly, which is usual).
This is going to make more sense for "enterprise"-type deployments, where there's a significant distinction between the people who might have access to request logs at times, and the people who can push code to production.
I am talking about not logging them ever, using internal TLS and strong hashing in general, and wondering what exact value is added on top with client side hashing.
Hashing client side minimizes the risk of any blast radius exceeding the bounds of your own service. There's obviously no way to prevent an adversary who achieves full MITM from gradually harvesting credentials over time. The only solution there is to use keys instead of passwords.
In your enumeration, what is breached for this to be meaningfully impactful for other services where customers might be reusing credentials?
I already answered you that if you assume full MITM of the frontend then it is physically impossible to prevent gradual credential harvesting. Did you have a different scenario in mind?
> how is client side hashing really helping
Compared to what? Server side hashing? It prevents the plaintext from ever hitting your infra which minimizes to the greatest extent possible an insider or intruder gaining access to the plaintext. Since preventing access to the plaintext is the primary purpose of hashing it's the sensible option if you're forced to pick only one.
Of course there's really no good reason to pick only one of the two. You might as well elect for defense in depth against rogue insiders with full db access even though it's difficult to imagine what use they would have for a password based login at that point.
If you are never logging a clear-text secret and storing a hashes version to validate against, and using TLS between client and server, client-side hashing does not bring much benefit other than protecting customers' reused passwords against people who have sufficient access to the infrastructure to MITM the client but no ability to modify the client side code where they could extract the password directly.
When IT has write access to code, client side hashing protects only against accidental log leakage and similar.
That is not a property of server side hashing but rather hashing in general.
> If you are never logging a clear-text secret
Yeah good luck with that. /s
It's better not to need to worry about logging plaintext. The less of your infra that falls within any given security boundary the easier it will be to properly secure. The difference between server and client side hashing is how much of your infra touches the plaintext. Less is always better.
Sure, an insider could make direct use of hashes pulled from the logs. However if the attacker already has access to your systems then they are already inside the security boundary (or at least most of them) and likely have many other (probably better) options available to them.
It's important to keep in mind that the primary purpose behind hashing credentials is to minimize the degree to which your systems come into contact with the plaintext. The goal here is to contain the blast radius of any intrusion to only your own systems and only the immediate intrusion (ie to prevent future abuse after you've cleaned everything up) given the unfortunate reality that end users will frequently reuse credentials.
It's also important to keep in mind that hashing is cheap enough that you should probably be doing both. Hash it on the client so that you don't need to worry about logs (or snooping the LAN or whatever other way an employee might come up with to obtain plaintext passwords) and then hash it again before it enters the db so that you don't need to worry about the logs that contain hashes leaking.
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
You store safely crafted hashes.
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
My bad - I misread the post.
To clear things up: I am completely aware about how to store passwords in services that check against them. You are likely to have read some of my prose on that topic in OWASP or at a conference :)
My point, after misreading the article, was that in order to authenticate to a service (the one that holds the hashed version of that password) you need to have access to its cleartext version. This is VERY bad, should never be stored without special considerations etc.
I read the articlae as if they accessed the source of the passwords, the one used to access to services (a vault, with its encryption, access restrictions etc.). 5k was a lot but that could have been bearers or similar ones.
So my comment, and the comments to it, actually yelled at me (that's good!) the way I yell at actual implemententions sometimes :)
In all seriousness - thanks for the reaction, we need more of these. My next obsession are servies that require "only digits" or "strictly 8 to 11 chars" for credentials :)
(I will not 'be copy/paste' (?) this response everywhere you spammed someone who pointed out the glaringly obvious)
See, I respect people who point out mistakes, and explain why I did it.
Why did I mention that I do security? Because I spent the last, 25 years trying to push proper practices and did not want to jump into discussions where over 10 comments we would end up flexing about details.
Since you are an infosec practitioner since the early 90s you either are a saint, or did not have to yell through best practices to just let it go.
Not sure what you don't like about conferences? Never got anything from them? I did and I am sure glad to have listened to great presentations.