Comment by giantg2
18 hours ago
How did they get access to 5k passwords? Are they being sent/stored in cleartext? This is the most baffling part of the article for me.
The second part I'm unclear about is how you could pass SOC2 when you aren't terminating account access simultaneously with the employment termination.
From the article, it sounds like the passwords are indeed stored in cleartext:
> On Feb. 1, 2025, Muneeb Akhter asked Sohaib Akhter for the plaintext password of an individual who submitted a complaint to the Equal Employment Opportunity Commission’s Public Portal, which was maintained by the Akhters’ employer. Sohaib Akhter conducted a database query on the EEOC database and then provided the password to Muneeb Akhter. That password was subsequently used to access that individual’s email account without authorization.
It still blows my mind. Shouldn't the government audit their contracting companies for egregious issues like this? Seems extremely reckless not to.
I've been through a handful of SOC2 audits and they've never asked us to _prove_ that we aren't storing passwords in plaintext or with reversible encryption (we weren't).
This is why so much of vetting & compliance is toothless. You can have robust change management, physical security, network security, identity management, etc. policies but absolutely nobody wants to spend enough on audit & enforcement to make them meaningful.
The gov't will make you _claim_ that you do all of these things before awarding a contract, but they won't ever check.
Good actors will do the right thing regardless because they know the consequences of cutting corners.
I'm pretty shocked as well. I thought every company stopped doing this like 20 years ago? Even for a legacy system that is a long time to continue storing credentials like that.
2 replies →
Policy and practice might not be the same thing. The company and the entire management staff should be on somebody’s blacklist for future procurement.
The tighter your security is, the more inconvenient it is for legitimate users, and the more you have to do audits because it's easy to justify going around security in the name of efficiency.
It's not just information security, either. I've seen vault doors propped open because the people working inside didn't want to do all the sign-in/sign-out paperwork to take a leak.
The whole point of stuff like SOC2 and audit to verify that policy is actually implemented. Seems like nobody actually checked.
SOC2 requires an audit. But one of the weaknesses of SOC2 is that the audit mostly checks to determine that you are following whatever your policy is. It doesn't verify that your policy is rigorous.
I don’t think you understand what SOC2 is.
First of all, it is viral, and it is almost never adopted based on its own technical merit.
Second, it has lots of levels. The first level is “we wrote down a plan explaining how we’re going to secure stuff”.
The second level is when you start implementation or maybe tracking or something.
The key thing is that first level: When your SOC2 dept says you have to do something idiotic for SOC2 compliance, it is because someone at your company invented the idiocy, and should be fired. However, you still need to follow their dumb plan because that’s the process.
In this case, the “how do we fire people” process, and “how do we prevent one llm from dropping 96 prod DBs in a single session” very well could have had answers in the plan, the plan could have been implemented, and therefore the company is still soc2 compliant, and this is exactly what a working soc2 process is supposed to look like.
Depends on what their offboarding policy is. If it's 72 hours or something they would not breach policy.
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
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)
(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 :)
Hashed, you store them hashed (and salted). A breach should never reveal passwords.
(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 :)
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.
(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 :)
I hope youre joking
(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 :)
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.
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.
1 reply →
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.
3 replies →
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.
9 replies →
(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 :)
You don't store passwords.
You store safely crafted hashes.
I don't think those words mean what you think they mean.
Assuming you're serious? Store passwords with salted one-way hashes.
I can only think of a scenario where this is still valid: spying.
The minimum one can do is have a different randomized password for every service on a possibly completely offline password manager.
Yes, you will depend on a password manager at all times, but at least the blast radius is minimized to the affected service.