Lots of people may have recently switched to a password manager, and now use it to store old passwords that they haven't regenerated. It's very likely a common use case.
I've imported my passwords from Firefox's password manager to a dedicated one a few years back, and I've been generating new passwords ever since.
There's still dozens of occurrences of the one-password-for-all-services I've used previously, because nobody will go through the hassle of changing passwords in hundreds of online services. I do change it whenever the autofill appears too short to be randomly generated, but I still didn't get rid of all of them.
With that said, I'm not using 1Password and I've already checked my old password in Troy's service to make sure it wasn't in a breach.
If we'd use something like certificate auth it'd be less of an issue, but currently password managers are a horrible trend because they encourage using your password for a service for kany years. Ideally you'd rotate them every 60 days. Automating that is hell.
It'd be much nicer if we could just use OIDC with user-configurable endpoint.
In fact, Android implements now on OS level an API for password managers, but no way to easily authenticate through a third party app.
Password managers are "good enough" that few people care about better solutions anymore.
Personally, I'd prefer to see client side certificates, or OIDC login everywhere, with short lived session tokens, and proper U2F 2FA.
With rotation, there is a tendency to just use the same password but increment a digit at the end, or to write them down because people forget them. A password manager helps with this, but if you're using a password manager, then you can use a different password everywhere.
Password rotation was recommended in the days when people used the same password everywhere and had to memorize them because password managers weren't a thing.
Password rotation gains you nothing if you're already using strong, unique passwords. The best it will gain you is preventing your account from being accessed if they have already breached the password file, cracked it, and come back after the rotation period. But at that point they've already had access to the system and your password is meaningless anyway, so you didn't actually gain anything.
Rotating credentials is important, even if you automate them. For the same reason that Let's Encrypt only provides certificates with 90 days validity, and that OAuth2 Offline tokens are usually limited to 90 or 180 days.
Ideally we'd use OAuth2 for everything, as that'd allow proper usage off offline tokens that allow the client to generate short lived session tokens, but we don't, instead we're using passwords everywhere, and we'd ideally want to have the same validity there.
The optimum would even be using challenge response authentications, or client side certificates.
This isn't a comparison of manual password management to password managers, but a criticism of password managers when compared to 30-day rotation cycle of client-side certificates.
In any case, if you really want to rotate passwords, 1Password has a "Security Audit" section with sections for "3+ years old", "1-3 years old", and "6-12 months old" passwords (and duplicate passwords, and weak passwords, and watchtower alerts), so you can rotate if you want to.
Sadly, currently this all is highly theoretical. The first thing we should focus on is getting 2FA (TOTP/HOTP or U2F) authenticated login on every service that doesn’t use OIDC. Even this very site, HN, has no such functionality (@dang, @pg: Why?)
This is a much more important first step, and once that’s fixed, we can look at improving credential rotation, and providing global SSO with browser credentials.
I'm not saying 2FA is bad, but these people like the person above lives in a hilarious bubble if they think a website like HN is missing out by not having it.
It comes off as concern-masturbation, if I may be so vulgar.
By the way, the best thing we did for security across our gambling network is to generate passwords for users. Nobody uses 2FA, and the people that use it aren't the ones that need help. But everyone reuses passwords.
I'm moving to KeepassXC currently and if you use a Yubikey challenge, you (by default) have to press it anytime you save or update a record which is a big pain. I think you can change it but I worry it might crash (I'm running unstable for the browser extension) or I might forget to save
But that can only work if most services you’re using are using SSO, and you rarely need to reauth. I need to reauth every time I log in, every time I want to authorize a new service, or modify server, DNS or storage settings.
This only works well because I’m self-hosting 90% of the services I use, and they use a Keycloak as identity provider, and then don’t have to handle identity themselves.
This is why I’d prefer to see more identity federation – ideally the tokens the services see are short-lived, but the user doesn’t have to re-login every time either.
I think MFA is important and have it enabled for every service that offers it, but we have MFA set up for our CLI access to AWS and I used to let out a volume of curses frequently when my token expired.
I eventually ended up adding a bash alias “damn”[0] that pipes my current MFA token into the AWS CLI so whenever it expires I can just type “damn” and be logged back in.
I like the magic link approach Slack and Medium use - although I have frequently cursed the inconvenience of having to log into gmail.
[0] why damn? Fuck was taken: https://github.com/nvbn/thefuck
I imagine some people use it as a signal - if you support 2FA, you are at least considering security well, even if they don't actually make use of it.
To be clear, you’re aware how absurdly long it would take to complete offline cracking for a single, randomly generated, 128-bit password, right? From a purely statistical perspective, what you’re advocating doesn’t actually make sense. It can only impose usability friction.
Unless you know a site’s password database has been compromised, you shouldn’t change the password. If it has been compromised, your password is so strong that you could honestly let just about every computer in the world try to crack it and still be reasonably confident in its continued security.
Password managers empower you to do that, but with a different password for every single service you use. You set it and forget it because you don’t have to do anything else. Simpler is better for users.
> For the same reason that Let's Encrypt only provides certificates with 90 days validity
I’m sorry, but no. This is utterly dissimilar to personal passwords. Public key certificates have limited validity because digital signatures cannot be revoked offline. The entire premise of a digital signature scheme and PKI is that you default distrust. Therefore, signers must renew instead of revoke, like a dead man’s switch. It doesn’t make sense to use this principle as a comparison for password security, because passwords are a secret used for access control, not authentication in the cryptographic sense of the term.
I think there is merit to the argument that public key authentication is better than passwords, but such a discussion should 1) include nuances, like the differences between authentication and access control, and 2) be mindful of cavets, especially with respect to usability. Under the current paradigm, passwords are not weak just because they do not share the same e.g. rotation characteristics as certificates, because they have very different use cases and threat models.
Suppose it will take 100 years to crack your strong unique password once the file is breached. If the rotation period is 90 days, rotation gains you something. Suppose they got the password file from a database backup. Your password isn't meaningless yet. You'll be fine as long as you rotate it within the next 100 years.
And tada, they got your password.
This is the sole reason why Let's Encrypt does 30-day certificates, and why the session tokens in OIDC are usually a few minutes at most.
The only one that's using a session token without invalidation time, forever, is Uber, and that was heavily criticized last time on HN.
And now, everyone's apparently in support of using the same password as login token for decades, never changing it.
Passwords != session tokens != certificates.
Passwords are a form of access control. I repeat: a strong password cannot be brute forced for billions of years. Even with technological advancements, most strong passwords are well over what’s required to literally be safe for a lifetime.
Certificates are not a form of access control, like I explained in my other response to you. They are a form of cryptographic authentication. Digital signatures cannot be revoked offline, which is a problem because they’re used by other parties for validating trust. Therefore, certificates have a built-in dead man’s switch that requires renewal.
Passwords are not used for validating trust. They’re not comparable to certificates. Stop using certificates as an example of why passwords need to be rotated, because certificates don’t even use “rotation” in that sense of the word.
The topic was never about brute forcing, that’s irrelevant.
It’s always about exfiltrated passwords, certificates or session tokens.
You usually have additional authentication requirements so that changing the password requires more than just the password, but an attacker that exfiltrates the password can still read everything.
For example, an attacker that obtains my onlinebanking password will be able to read all transactions, but not make changes. In this way, the password acts identical to a session token – an attacker exfiltrating a session token will get the same access.
The goal is to reduce this ability – changing the password as often as the offline session token ensures that if an attacker had such read access, as is possible with many services, this access will not continue forever.
With your suggestion, of using an identical password for decades, a potential attacker has for decades read access to the bank account. This is undesirable.
Yes, preventing exfiltration would be better, but exfiltrating session tokens and passwords is identical in terms of attack surface, and as result, they should be protected identically.
A strong password takes billions of years to crack with current computing power, assuming an entire datacenter is coordinating offline cracking on your password in particular.
This isn’t correct. Password rotation is a function of desired cover time (how long you want to maintain confidentiality) and password strength (approximate entropy and complexity).
If you randomly generate a password with 20+ mixed case alphanumeric characters, it’s theoretically safe against offline brute forcing attempts for more time than the universe has existed. Statistically speaking, you gain virtually nothing by rotating such passwords unless you know they’ve been compromised. On the other hand, you impose a significant security liability through usability friction.
Eventually decided to give them all stronger unique passwords (because why not) and it was a pretty easy process because the password manager could show me all the sites with duplicate passwords.