4 ms·

Am I out of the loop, or is it really uncommon for a company to proactively reset passwords after a breach? Maybe I'm being paranoid but after the whole T Mobi

Am I out of the loop, or is it really uncommon for a company to proactively reset passwords after a breach? Maybe I'm being paranoid but after the whole T Mobile plaintext password fiasco a couple years back I worry that AT&T may have done something equally stupid, perhaps un-salted hashes if not plaintext passwords. Edit: my bad, I didn't read this article first (and stupidly relied on another article I read earlier, which didn't have as much detail)... Does anyone have more detail on the new research? If the "passwords" are really short numeric pins, it sounds like they _are_ unsalted if they're so vulnerable.

pxx 3y ago
Hashing is more or less pointless with such a small input space. Salts wouldn't help much.
- anonym29 3y ago
  if salt is a per-user randomly-generated 32 digit value, then even if you're using a weak, outdated algo like md5, md5($ssn.$salt) is still safer than md5($ssn): pre-computed hash lookup tables don't exist for md5($ssn.$salt) but they do exist for md5($ssn). A competent adversary could still crack these if they got the whole DB, but salting is meant to be a defense in depth thing, not a one stop solution to every database security problem. Hell, if the adversary only gets the DB but not your application source code for some reason, them not knowing the order or formatting specifics of your salt and other static values might stop them from being able to crack even with the full contents of the DB - i.e. imagine your hashes are md5(md5(md5($ssn.$signUpTimestamp).$salt)."iejfmgklaihfje"). If the adversary doesn't get your source, there's almost no way they're guessing the hashes column is computed like shown above, they're just going to be banging their head against the keyboard trying to figure out why hashcat isn't spitting out passwords when they feed in the hashes and salts. The idea of an adversary getting db access but not source access may sound strange, but I've been doing security work for close to two decades now and I've seen this happen multiple times to real companies. Never undervalue defense in depth! You don't know what your adversary's capabilities will be so whenever you have an opportunity to deny them if they're missing a capability, you should try to if it's not an unacceptable businesses decision. Disclaimer: you should NOT be using MD5 for security-sensitive one-way hashing in 2024. bcrypt is a much stronger algorithm and has stood the test of time well, Argon2id is newer so less battle-tested, but is ostensibly a major improvement even over algos like bcrypt.
  - pxx 3y ago
    As soon as you've lost the db, with low-entropy inputs like these, you should assume that the plaintext has been compromised and should treat it as such, especially if your "security" corresponds to under a billion hash computations. It doesn't count as "Defense in depth" when the layer is as thin as tissue paper. If you actually do care (and you still don't really want to), there is actually a regimented way to do this instead of the ad-hoc nonsense that you propose. Add a service-specific salt embedded in an HSM; this is sometimes known as a "pepper". You still would probably consider resetting everybody even in this case if you lost the DB, though.
    - anonym29 3y ago
      I'm not asserting that what I've proposed is all that should be done, and my post was not meant to be exhaustive, just offering some extra DiD tips when it comes to hashing, salting. My suggestions are to mitigate the impact of precomputed lookup tables, forcing adversaries to crack the hashes themselves, and offering defenders a slight information advantage in circumstances where an adversary gets access to a database, but not source code, which really isn't that obscure or unusual of a situation.
nickburns 3y ago
these aren't login passwords like as part of a credential set. these are what AT&T does, in fact, refer to as "passcodes." and an account holder (or any agent of such) is required to furnish it to any AT&T representative in order to discuss and/or access sensitive account information. kinda like MFA before MFA became ubiquitious. i have been required to provide all three—credentials, TOTP, and passcode—to access my account for as far back as i can recall.

pxx 3y ago

Hashing is more or less pointless with such a small input space. Salts wouldn't help much.

anonym29 3y ago
if salt is a per-user randomly-generated 32 digit value, then even if you're using a weak, outdated algo like md5, md5($ssn.$salt) is still safer than md5($ssn): pre-computed hash lookup tables don't exist for md5($ssn.$salt) but they do exist for md5($ssn). A competent adversary could still crack these if they got the whole DB, but salting is meant to be a defense in depth thing, not a one stop solution to every database security problem. Hell, if the adversary only gets the DB but not your application source code for some reason, them not knowing the order or formatting specifics of your salt and other static values might stop them from being able to crack even with the full contents of the DB - i.e. imagine your hashes are md5(md5(md5($ssn.$signUpTimestamp).$salt)."iejfmgklaihfje"). If the adversary doesn't get your source, there's almost no way they're guessing the hashes column is computed like shown above, they're just going to be banging their head against the keyboard trying to figure out why hashcat isn't spitting out passwords when they feed in the hashes and salts. The idea of an adversary getting db access but not source access may sound strange, but I've been doing security work for close to two decades now and I've seen this happen multiple times to real companies. Never undervalue defense in depth! You don't know what your adversary's capabilities will be so whenever you have an opportunity to deny them if they're missing a capability, you should try to if it's not an unacceptable businesses decision. Disclaimer: you should NOT be using MD5 for security-sensitive one-way hashing in 2024. bcrypt is a much stronger algorithm and has stood the test of time well, Argon2id is newer so less battle-tested, but is ostensibly a major improvement even over algos like bcrypt.
- pxx 3y ago
  As soon as you've lost the db, with low-entropy inputs like these, you should assume that the plaintext has been compromised and should treat it as such, especially if your "security" corresponds to under a billion hash computations. It doesn't count as "Defense in depth" when the layer is as thin as tissue paper. If you actually do care (and you still don't really want to), there is actually a regimented way to do this instead of the ad-hoc nonsense that you propose. Add a service-specific salt embedded in an HSM; this is sometimes known as a "pepper". You still would probably consider resetting everybody even in this case if you lost the DB, though.
  - anonym29 3y ago
    I'm not asserting that what I've proposed is all that should be done, and my post was not meant to be exhaustive, just offering some extra DiD tips when it comes to hashing, salting. My suggestions are to mitigate the impact of precomputed lookup tables, forcing adversaries to crack the hashes themselves, and offering defenders a slight information advantage in circumstances where an adversary gets access to a database, but not source code, which really isn't that obscure or unusual of a situation.

nickburns 3y ago

these aren't login passwords like as part of a credential set. these are what AT&T does, in fact, refer to as "passcodes." and an account holder (or any agent of such) is required to furnish it to any AT&T representative in order to discuss and/or access sensitive account information. kinda like MFA before MFA became ubiquitious. i have been required to provide all three—credentials, TOTP, and passcode—to access my account for as far back as i can recall.