The problem with implying that hashing (which *isn't* encryption!) could lead to complacency is equally relevant if only flagging plain text passwords in the fashion you've suggested. SHA-1 (even with a salt) is *almost* equally as useless as plain text so by that rationale should also be flagged. Then what about bcrypt with low work factors? Or high work factors but poor password strength controls?

This is precisely why services recommend (or even mandate) password changes when passwords of any kind are breached. I'm all for adding more details about the hashing algorithm as it's relevant for those who understand what that means, but the only guidance I want to give to end users after passwords are exposed is "change them immediately".

Instead of marking some of the breaches as having "hashed" passwords, which could lead people to complacency, I would like to see a flag for "plaintext" passwords. That is, HIBP would give no notice about encryption for most breaches, but a breach known to contain at least some passwords in plaintext would get flagged to help to raise the alarm.

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.

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.