5 ms·
I still expire passwords on a yearly basis for the sole reason that users have complained to me that it stops them from using the password they use for everythi
by discreditable 7y ago
I still expire passwords on a yearly basis for the sole reason that users have complained to me that it stops them from using the password they use for everything else.
- jeremyjh 7y agoI 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.
- xixixao 7y agoI'm not an expert, but you could integrate DBs like https://haveibeenpwned.com/Passwords https://haveibeenpwned.com/Passwords to make sure users don't use exposed passwords?
- LeoPanthera 7y agoWhat I do: 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.
- omh 7y agoHow are you implementing these checks? I'm using Active Directory and options for extra password checks are somewhat limited.
- LeoPanthera 7y agoOh sorry I'm not using AD, it's just a web service.
- technion 7y agoMicrosoft has a pwnedpasswords-like service you can use: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-premises https://docs.microsoft.com/en-us/azure/active-directory/auth...
- discreditable 7y ago* If you use Azure Active Directory
- funnybeam 7y agoOn-premises AD has the same functionality but it is a pain to set up and so limited as to be not worth the effort
- omh 7y agoI don't think this (Azure AD Password Protection) actually implements a pwnedpasswords-style check. 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.
- asimops 7y agoYou can use a dll to do additional security checks on a domain controller base. Check this https://github.com/JacksonVD/PwnedPasswordsDLL-API https://github.com/JacksonVD/PwnedPasswordsDLL-API
- discreditable 7y agoThe problem is the password change UI on Windows systems is terrible. It does not give users any clue why their password was not accepted other than "Unable to update the password. The value provided does not meet the length, complexity, or history requirements of the domain."
- shakna 7y agoIf you have the DS-Replication-Get-Changes permission, you can exploit dc-sync through something like mimikatz [0] to grab the password hashes out of Active Directory, so you can run your checks. [0] https://github.com/gentilkiwi/mimikatz https://github.com/gentilkiwi/mimikatz
- tomglynch 7y agoI don't think checking against haveibeenpwned is a good idea. They recommend against checking your current password, and you're automatically checking every users current password?
- bscphil 7y agoYou can download a database from haveibeenpwned of SHA-1s of all the passwords, which is the only way you should be checking user passwords against an external database. It's also a good way!
- fwip 7y agoDownloading the database is best, but you can also safely use their range API [1]. This can be run either client-side or server-side. 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#SearchingPwnedPasswordsByRange https://haveibeenpwned.com/API/v2#SearchingPwnedPasswordsByR... [2] https://safepasswordchecker.hashbase.io/ https://safepasswordchecker.hashbase.io/ [3] https://safepasswordchecker.hashbase.io/script.js https://safepasswordchecker.hashbase.io/script.js
- LeoPanthera 7y agoThe check is done locally against a hash. There's no risk of leaking the password.
- tomglynch 7y agoOk, that is fair. I thought you were skipping this rule from Troy Hunt (HIBP creator): "Do not send any password you actively use to a third-party service - even this one!"
- lysp 7y agoFrom memory their system works by a using a partial-hash, minimising the leak of the password. 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.
- omh 7y agoThis is definitely a dilemma. 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 https://support.google.com/a/answer/6197480
- crazygringo 7y agoYup, this type of feature is the answer. 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.
- bscphil 7y agoThe requirements are actually using Google accounts, and requiring all your employees to use Chrome.
- jupp0r 7y agoNot sure about the legality of this, but trying to log in to a a couple of services would be an easy test.
- yaks_hairbrush 7y agoA secure service wouldn't have an easy way of getting at a user's password. They'd store the salted hash of a user's password, and not the password itself.
- discreditable 7y agoIf services were secure then password re-use would not be such a problem.
- jupp0r 7y agoYou mean hash it in the browser? That's rare. Otherwise, you have the plain text password in the request you do the hashing and writing the hash to storage in.
- xfitm3 7y agoStrong password policy. Reused passwords are often simple.
- air7 7y agoI disagree. I feel it's not a site's responsibility to stop users from reusing their passwords if they choose to. It has no relation to the security of the service. As a metaphor, a good lock maker protects their customers from lock picking, not from a key left under the mat. 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.
- jeremyjh 7y agoI've never heard of a website implementing something like this. Password rotation requirements are usually found in corporate or government settings, for logging into your workstation, email and internal applications.
- desas 7y ago"internal" and line of business apps are not provided as cloud hosted SaaS yet? 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
- bscphil 7y agoSome possibilities off the top of my head (some suggested here already): * 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.
- kibwen 7y ago> Test for password existence in public databases 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.
- cjensen 7y agoThat's amusing but... those same users are likely to be using just altering their passwords a little like "passwd1" "passwd2", etc. You aren't gaining anything.
- discreditable 7y agoI'm sure they are, but I think predictability is slightly less bad than being distributed across every single service they've ever used. There's only so much I can do about people not giving a crap.
- rtempaccount1 7y agoTOTP or other forms of 2FA are the best way of avoiding the very real problem of user password re-use.
- pstch 7y agoI don't see how TOTP/2FA can avoid the problem of user password re-use. The password has still been reused, whether an extra layer of authentication is used or not. Maybe you can say that it mitigates it, but I don't think it avoids it at all.
- infogulch 7y agoThere are two slightly overlapping ways to actually solve this problem: 1. Use a password manager. 2. Have the tools, knowledge, capability, and willingness to use secure passphrases.
- tomglynch 7y agoOne other way. Websites could hash and salt the users password client side, then proceed as usual (SSL and hash it server side). Means the users password is effectively a long, secure passphrase and is unique. What do you think?
- 7y ago
- javagram 7y agoI guess other options could be not allowing the users to set their own password but instead generating a password for them. Or just require 2FA for everything, but that’s hard to do with a lot of software.
- Wowfunhappy 7y agoRequire all employees to use a password manager?
- pedrocx486 7y agoAnd spend time training them on using it? I really wish it was a thing but people looked at me like I was an alien when I mentioned it... (I work for a Microsoft subsidiary. I also hope they adopt the new rules, I hate changing passwords every 90 days.)
- Wowfunhappy 7y agoI don't think it's actually possible to both (A) use unique passwords and (B) not use a password manager. If you can't provide one, don't expect the other.
- kibwen 7y agoIn practice I'd stake money on it, even taking into account the tech-savvy users who would otherwise use password managers but are forced to log in manually every time they step away from their computer for five minutes (I'm pretty sure it is intentionally impossible that you can't use a password manager on the Windows login form, for example).
- kurtisc 7y agoIf your profile is up to date: why are you including password reuse attacks in your threat model?