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.
Password rotation has been shown time and again to be worse than just using a unique strong password.
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.
> "...if they have already breached the password file, cracked it, and come back after the rotation period..."
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.
> 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.
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.
If the hackers have compromised the service to the point they are able to manipulate the service unnoticed, isn't the horse already a little out of the barn?
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.
> 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.
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.
I'm talking about automated password rotation. A new 128 byte random base64 password every month.
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.
Rotating passwords is only important if the site has been compromised (or you've been compromised, such as being phished). For the former, 1Password already has the Watchtower functionality where it tells you if a site is known to have been compromised since your password was generated, and for the latter, well, if you're being phished then you'll probably figure it out pretty quickly when the attacker steals your account.
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.
Rotating credentials is also important as an additional layer of security to prevent misuse.
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'd wager HN doesn't have 2FA because there's not much damage you could do if you compromised someone's HN account. At best you can pretend to be someone else for a bit, but in most cases that's harmless. There's only a handful of accounts I can think of where it would be problematic if someone started impersonating them.
I work in online gambling and 2FA is a feature everyone says they want but doesn't use because it's annoying. Just query the amount of users actually using 2FA on your site if you've set it up. Now compare it to the number of people who said that they can't take your site seriously until you have it.
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 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.
As someone who uses a Yubikey for physical 2FA, I happily use it for things like my email and Github but then I just click trust the device for X days because, yeah, it can be a pain every time.
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
Personally, I use Yubikey or TOTP (with RedHat’s FreeOTP) for everything.
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'm talking about automated password rotation. A new 128-bit* random base64 password every month.
Rotating credentials is important, even if you automate them.*
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.
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.
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.