6 ms·

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 unc

by giantg2 5mo 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.

inetknght 5mo ago
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.
- giantg2 5mo ago
  It still blows my mind. Shouldn't the government audit their contracting companies for egregious issues like this? Seems extremely reckless not to.
  - at-fates-hands 5mo ago
    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.
    - jeremyjh 5mo ago
      20 years is rookie numbers in these systems. I guarantee it’s been at least 40 years since a single fuck was given.
    - __turbobrew__ 5mo ago
      My wife works in IT at a mid sized city. They still store credentials in source control.
  - njovin 5mo ago
    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.
    - lazyasciiart 5mo ago
      See: the entire existence of Delve https://www.iansresearch.com/resources/all-blogs/post/security-blog/2026/04/19/delve-allegations-expose-weak-points-in-modern-compliance https://www.iansresearch.com/resources/all-blogs/post/securi...
BrandoElFollito 5mo ago
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
- jjk7 5mo ago
  Assuming you're serious? Store passwords with salted one-way hashes.
  - BrandoElFollito 5mo ago
    (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 5mo ago
  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.
  - Tangurena2 5mo ago
    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.
GorbachevyChase 5mo ago
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.
- giantg2 5mo ago
  The whole point of stuff like SOC2 and audit to verify that policy is actually implemented. Seems like nobody actually checked.
  - kube-system 5mo ago
    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.
- laughing_man 5mo ago
  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.
skinfaxi 5mo ago
Depends on what their offboarding policy is. If it's 72 hours or something they would not breach policy.
liendolucas 5mo ago
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.
hedora 5mo ago
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.

by giantg2 5mo ago

inetknght 5mo ago

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.

giantg2 5mo ago
It still blows my mind. Shouldn't the government audit their contracting companies for egregious issues like this? Seems extremely reckless not to.
- at-fates-hands 5mo ago
  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.
  - jeremyjh 5mo ago
    20 years is rookie numbers in these systems. I guarantee it’s been at least 40 years since a single fuck was given.
  - __turbobrew__ 5mo ago
    My wife works in IT at a mid sized city. They still store credentials in source control.
- njovin 5mo ago
  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.
  - lazyasciiart 5mo ago
    See: the entire existence of Delve https://www.iansresearch.com/resources/all-blogs/post/security-blog/2026/04/19/delve-allegations-expose-weak-points-in-modern-compliance https://www.iansresearch.com/resources/all-blogs/post/securi...

BrandoElFollito 5mo ago

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

jjk7 5mo ago
Assuming you're serious? Store passwords with salted one-way hashes.
- BrandoElFollito 5mo ago
  (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 5mo ago
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.
- Tangurena2 5mo ago
  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.

GorbachevyChase 5mo ago

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.

giantg2 5mo ago
The whole point of stuff like SOC2 and audit to verify that policy is actually implemented. Seems like nobody actually checked.
- kube-system 5mo ago
  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.
laughing_man 5mo ago
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.

skinfaxi 5mo ago

Depends on what their offboarding policy is. If it's 72 hours or something they would not breach policy.

liendolucas 5mo ago

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.

hedora 5mo ago

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.