[BrandoElFollito]

And how exactly do you want to store passwords if not in plain text (and then encrypted of course)? 5k is a lot, the authorization process is broken, but this is not related to how the passwords are stored.

The only solution is correct access segregation and a bastion

[Dangeranger]

You should never store passwords in plain-text, encrypted or not, you should always use a one-way cryptographic hash like bcrypt [0], scrypt [1], or PBKDF2 [2], combined with a single use salt [3] and optionally a pepper [4], and then store the output of the hash in the database.

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

[3] https://en.wikipedia.org/wiki/Salt_(cryptography)

[4] https://en.wikipedia.org/wiki/Pepper_(cryptography)

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[Epa095]

Hashed, you store them hashed (and salted). A breach should never reveal passwords.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[__turbobrew__]

You speak very authoritatively on something you don’t know.

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.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[jm_l]

Typically you store a hash of user passwords instead, then when logging in you hash the user password client-side and compare the hashes. This acts like a one-way function that protects the password while letting the user authenticate themselves.

[CyberLily]

Hashing passwords client-side is generally a bad idea, since it means that the hash effectively becomes the password. For example, if I have a database row that has the hash of the password and a bad-guy gets access to the database, they will get the hash. The benefit of a hash is that it is a one-way operation, I can't figure out the plaintext from the hash, so my account is safe. If the password is hashed on the client, and sent to the server the attacker doesn't need to reverse the hash, they can just send the hash in the request. Instead, you should send the password to the server (using TLS encryption) and do the hash and compare on the server.

[jmull]

You actually want to one-way passwords both client-side, for transport, and again server-side, for storage/comparison.

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.

[PunchyHamster]

If you're worried about MITM in the TLS web connection between client and server, you already lost and no prevention method client side will work, because if you own the connection you can just give client malicious JS to extract the password when they enter it

[fc417fc802]

Hashing client side is sufficient because the only service you can breach with the hash is the one you already had to breach in order to read the database.

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.

[Tangurena2]

Also, you need to add salt. Otherwise every person using "Password123" has the exact same hash. Before they broke their search engine, it was common to google the MD5/MD4 hashes to "decrypt" or "unhash" them.

[necovek]

And rainbow tables appeared too.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[jmull]

People shouldn't be downvoting this...

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.

[necovek]

I wonder how common are setups where an internal person has access to the TLS private key part of the certificate or access to a network equipment that all traffic passes through, yet they cannot access the inputs required for hashing/encryption client-side?

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.

[jmull]

> This seems to mostly prevent accidental logging

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.

[fc417fc802]

Yes limited protection against insiders is good defense in depth but not the primary purpose which is to protect end user accounts on other services in the event that you are breached.

[necovek]

My question still stands: how do you disallow cleartext password extraction if you are breached, assuming all your IT infrastructure and code is now accessible to an attacker?

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.

[fc417fc802]

There are substantial differences between database access, snooping the logs, internal (no TLS) wiretap, and full MITM of the frontend.

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.

[ellg]

I hope youre joking

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[jjk7]

Assuming you're serious? Store passwords with salted one-way hashes.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[subscribed]

You don't store passwords.

You store safely crafted hashes.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[subscribed]

Thanks for the follow up! And yeah, I share your gripe with the next target :)

[kjs3]

I don't think those words mean what you think they mean.

[BrandoElFollito]

(I will be copy/paste this answer for the other comments)

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 :)

[kjs3]

You should have stuck with the 'My bad...' and left out the eye-roll inducing humble brags and inscrutable non-clarifications. But what do I know...I've only been an infosec practitioner since the early 90s...I'm sure 'conference experience' trumps that.

(I will not 'be copy/paste' (?) this response everywhere you spammed someone who pointed out the glaringly obvious)

[BrandoElFollito]

Or I could have let it go.

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.

[kjs3]

You should have stuck with "Or I could have let it go.".

[BrandoElFollito]

And yet I have not, sorry for having dissapointed you.