I came here to say this. I can't think of another way to guarantee that they aren't using the same password that they use on every website they've visited since 1997. If anyone has suggestions on this I'd love to hear it.
1. Check the password against the haveibeenpwned.com database.
2. Check the password with the zxcvbn password strength library.
If it passes both they can use it. It's not perfect, but it's a lot better than nothing.
I'm using Active Directory and options for extra password checks are somewhat limited.
https://docs.microsoft.com/en-us/azure/active-directory/auth...
It lets you upload your own custom list of banned passwords but it's limited to 1000 words. My impression is that this is intended to blacklist common words and things like your company name.
I see that Troy Hunt is now working for Microsoft so perhaps there's something in the works related to this. It seems like linking this Azure AD service to the haveibeenpwned API would be pretty straightforward.
I built a toy webpage using the API [2], and you can see how straightforward the API is to use by checking the script [3].
[1] https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR...
So for: * Password: trustno1 * Hash: 1234567890abcdefghij
You send to the api:
* Hash: 12345
And it returns all hashes it knows of that start with 12345 along with a count of how many times each hashed password has been breached.
You then compare that list to see if your full hash exists in there.
If it exists - it's been breached. If not - you're clear.
It's about checking a "new" password when an account is created, or the password changed.
Having said that - I don't see any issue with checking current passwords when the user logs in - you don't send the password to the remote service, so it can't leak that way.
Turns out he's downloaded a hashed list and is checking against that. Which is fine.
Personally, I reuse a simple password for very non-important services and it's very convenient. I think that's ok, or at the very least I should be able to choose to.
I work on a web based SaaS used mainly by different parts of the government and we are often asked about password policies and rotation, to which we point at the nist & nscs advice
If you're using Google Accounts then they have a feature for this[1]. It detects when they enter their Google password into any other site then reports it and makes them change their password. I'd love a similar feature that somehow worked with Active Directory.
[1] Password Alert: https://support.google.com/a/answer/6197480
It's not foolproof-perfect, but from personal experience it tends to work quickly and effectively. It requires "surveillance" of your browser/computer, but you should assume that with a work device anyways, and it can work with hashes and password fields so it's not storing your actual password or logging everything else you're doing.
* Test for password strength (most reused passwords are weak)
* Test for password existence in public databases (and recheck on database updates when they log in)
* Automatically generate a secure password for your users at the account creation stage and require them to use it
* Use a login method more sophisticated than just username / password to mitigate against password reuse
* Expire the first password they enter instantaneously, but then never expire again.
* Set an exact length requirement of between 16 and 20 characters inclusive. (Don't actually do this, but it's better than password expiry.)
* If your users are also your employees, make them responsible if their password is compromised while training them in proper password use.
I don't know, it just seems to me like basically any solution, including doing nothing, is better than expiring passwords. Even if it forces a few people to not reuse a password and there were no other way to achieve the same result, the tradeoff of worse security that results would make it not worth it.
While we're on the topic of security guidelines, this one really ought to be mandatory for any organization that cares about security in the slightest. It immediately invalidates the overwhelming majority of the class of laughably-insecure passwords selected by users.