Differentiate hashed and plaintext passwords in the data classes
Split the "Passwords" data class into "Hashed Passwords" and "Plaintext Passwords", or simply add the new types. This would allow for different actions to be taken based on the breach data. I think the plaintext identifier would be more important as a flag, and it should be used to also signify easily resolved hashes. (Maybe Passwords is the current hashed/encrypted/plain, and Plaintext is when text has been recovered)
-
There’s no guarantee that any password corpus (even when in plain text) will go into Owned Passwords, it’s usually just very large corpuses of largely unseen passwords. Best bet is to just hit the k-anonymity API on demand rather than manually downloading the hashes.
-
Mike commented
I understand, and I think that's why I backed off my initial sentence by the end. My concern was to know when the pwned password database was updated, but I saw in another comment that the last updated HTTP header can be used. But as of now, there doesn't seem to be a way to know if a particular breach has contributed to the pwned password dataset. A plaintext data class would be a flag, or another counter like PwnCount would give an idea of the immediate scope of compromised passwords.
-
I can foresee adding more information about how passwords are stored, but IMHO it needs more information than simply plain text / hashed / encrypted. MD5 / SHA-1 etc are all hashed, but (usually) easily cracked, even when salted. But even bcrypt is crackable when passwords are weak so in a case like the recent Spoutible incident where *very* weak passwords were allowed, bcrypt still poses risk. Part of my hesitancy in reporting how passwords are stored is it may lead people to make assumptions about the protection provided which, per the examples above, may not be consistent with reality.
I’ll leave this suggestion here as I do think it’s a good one, I just wanted to give some context around why it’s not quite as straight forward as it may seem.