Sigh.
Just got told by a company internal app that it's time to change my password.
Can we please stop with the fake #security? My password is a long string of randomly generated characters. Nobody's going to guess it any time soon.
Timeline
Post
Remote status
Context
2
@argv_minus_one I still believe in password rotation on long intervals (1 year min). Passwords that get spread across multiple systems (e.g. LDAP, OIDC) get used and abused and shoved into god knows what by people and it contains the damage to some extent of a lost first factor which happens all the time.
@7666 @argv_minus_one 1 year is reasonable and I would go even lower to 6 months at max. That said, there are companies that force password changes every 2 months and sometimes even faster. At that point it misses the point completely, because much more employees will just stick some number at the end or capitalize one letter and be done with it.
Replies
50
@phnt @argv_minus_one I am waiting for the inevitable screeching about how passwords should last forever and shouldn't be rotated until confirmed compromised and then I'll go "okay! now do that for TLS certificates!"
As for public CAs requiring TLS certificates to be rotated every 21 seconds, they're doing that because
1. OCSP has epically failed,
2. everybody had to go back to CRLs, and
3. in order for CRLs to not get monstrously huge, certificates must expire quickly so they can be quickly deleted from the CRL.
None of this applies to company internal stuff. Long-lived certificates are still fine in those environments.
@argv_minus_one @phnt Expiration and CRL entry are not the same. Certificates are timestamped with an expiration date which is approved by the CA. A CRL only gets updated when a certificate is explicitly revoked by the CA so that when clients reach out to the CRL they find the cert and stop trusting it, even if it is a 100% valid, in-date cert. You have this sideways.
The only reason why certificates, which generally live in a protected space untouched by users, have a more aggressive rotation period than passwords, is because of domain / resource transfers. At the time of signing, the domain / resource that was signed for could have changed hands, but the certificate would still be valid. This is where a CRL would come in, because prior to transfer you'd revoke the cert, but this is apparently too hard for CAs.
The correct path is to fix OCSP or CRL distribution, and not force the rest of us to fix it on their behalf by cycling certs like maniacs.
The only reason why certificates, which generally live in a protected space untouched by users, have a more aggressive rotation period than passwords, is because of domain / resource transfers. At the time of signing, the domain / resource that was signed for could have changed hands, but the certificate would still be valid. This is where a CRL would come in, because prior to transfer you'd revoke the cert, but this is apparently too hard for CAs.
The correct path is to fix OCSP or CRL distribution, and not force the rest of us to fix it on their behalf by cycling certs like maniacs.
@7666 @argv_minus_one You can't fix the system when browsers are basically the only ones steering it. The various hacks needed to make XMPP S2S connections not freak out after LE stopped issuing certs for client auth should have never existed in the first place.
Then there's also this: https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs
Then there's also this: https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs
@phnt @argv_minus_one I used to laugh at the US government and military for running their own CA and making people trust their root cert to access their sites. Now I'm having second thoughts.
Removing the TLS Client EKU is an epic fail and has made a lot of people justifiably upset, but that isn't the same thing as certificate rotation.
I certainly wouldn't mind if someone offered a better alternative to this rapid certificate rotation as it is rather inelegant, but I can't think of one. Can you?
Also, OCSP was even more inelegant. As someone who was dreading having to actually use it in a non-browser client app to validate a server certificate: good riddance.
@argv_minus_one @7666 It's the shorter lifetime of certs that annoys me. It will be 45 days in a few years, then what? 30 days and 14 days? It doesn't make sense especially in the context where seemingly no ACME client can properly request certificates. I've had issues with certbot, switched to acme.sh with the dynamic web server reconfiguration, that didn't work reliably either. Then switched to acme.sh with webroot where the only way to fail is not to place a single file in a predefined directory and it still manages to fail ~20% of the time for some reason. The only ACME client that hasn't failed me is OpenBSD's one. In a few years, we'll all be running an ACME client on a daily cronjob I guess.
@phnt @7666 @argv_minus_one none of this would even be a problem if revocation wasn't such a pain either
@i @7666 @argv_minus_one Good luck getting your domain registrar's DNS to cooperate or running your own.
I'm not familiar with DANE, but according to Wikipedia https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities it has the rather serious problem that everything is signed with 1024-bit RSA.
This is…not great.
Replacing CAs with DNS server operators sounds like an okay idea in theory, but it'll only work if DNS server operators are prepared for the responsibility, which it doesn't sound like they are. Not yet, at least.
@argv_minus_one @7666 @i DANE's only actual deployment is with MTAs where it is used to ensure you aren't getting downgraded with a MiTM.
And even there it flopped hard because it's annoying to get running and maintain.
@phnt @7666 @argv_minus_one and also there's a circular loop where the initial thing wasn't good enough and now it's never allowed to ever be adopted because vendors are just fine with CA's, securing dnssec with 256bit elliptic sigs (https://www.ietf.org/rfc/rfc6605) is old as hell, and people still complain about the initial rsa1024 keys
it's like saying saying https is insecure because ssl or tls1.0 existed before
it's like saying saying https is insecure because ssl or tls1.0 existed before
@argv_minus_one @phnt This is the exact fallacy that LE falls into. Let me know when ACME runs on an iDRAC8, because until then, I am just going to bypass cert warnings.
@argv_minus_one @7666 Both are a problem, you can't have fast expiring certs when the thing that is supposed to make them work barely works.
@argv_minus_one @7666 idk, ask those maintaining the spec and the developers.
@phnt @7666 @argv_minus_one I run dehydrated on a weekly cronjob, never had any issues besides having to change the time because LE's servers are oversaturated
Guessing isn't the issue. If the hash gets exposed in a breach, attackers can brute-force it at their leisure. Rotation helps ensure that by the time they crack it, it's no longer valid. Rotation policy should thererore be based on projected brute-force time per string length, not arbitrary human calendar dates. Set a short password? Well then you're changing it often, don't like it, remember a longer password 🤷♀️
@nicholas @phnt @argv_minus_one there are widely available one way hashing functions that can protect passwords of suitable length *beyond the expiration of the sun* with our current compute capabilities, you know.
When bitcoins start mysteriously moving around, call me.
When bitcoins start mysteriously moving around, call me.
@nicholas @7666 @argv_minus_one You missed the point. If the passwords are too similar, if you crack an old hash you can guess the new password much easier. That's why aggressive rotation actually hurts security. You don't get that issue with longer periods of rotation.
Yes, and if they brute-force it at their leisure, they gain…access to the same system they've already breached.
You didn't think I was reusing passwords, did you? I'm not completely incompetent.
Actually, they don't even gain that, because I've been notified that there's been a breach and have already changed my password.
So exactly which threat is being mitigated by time-based password rotation?
@argv_minus_one @nicholas @7666
>You didn't think I was reusing passwords, did you? I'm not completely incompetent.
You aren't 70+% of people in <insert your workplace>.
>So exactly which threat is being mitigated by time-based password rotation?
Forgotten accounts, password reuse.
>You didn't think I was reusing passwords, did you? I'm not completely incompetent.
You aren't 70+% of people in <insert your workplace>.
>So exactly which threat is being mitigated by time-based password rotation?
Forgotten accounts, password reuse.
@argv_minus_one @nicholas @7666 I mean forgotten accounts as accounts of employees that have been fired or left and weren't deactivated for whatever reason. That gives the account and absolute deadline where it is still active.
>Why are people at your workplace reusing passwords
Almost everybody that isn't tech savvy does that and there's exactly 0 ways to stop them from doing it, because they will never learn. Or people are just careless. Best you can do is force a password manager on people and put some higher password requirement on the vault password and some second factor. But have fun implementing that with Karen in HR.
>Why are people at your workplace reusing passwords
Almost everybody that isn't tech savvy does that and there's exactly 0 ways to stop them from doing it, because they will never learn. Or people are just careless. Best you can do is force a password manager on people and put some higher password requirement on the vault password and some second factor. But have fun implementing that with Karen in HR.
@argv_minus_one @phnt @nicholas Not everything supports SSO responsibly (see: https://sso.tax), hardware tokens are notoriously difficult to integrate into existing systems such as on-prem AD which runs a ton of the world still, etc etc.
Your idealism is getting in the way of practicality. This statement would also smack you upside the head but is functionally correct: The right amount of security is just enough not to get hacked.
Your idealism is getting in the way of practicality. This statement would also smack you upside the head but is functionally correct: The right amount of security is just enough not to get hacked.
Every organization bigger than a lemonade stand is under constant attack by billion-dollar crime gangs and nation-state intelligence agencies.
“Just enough not to get hacked” is a really high bar, we've got the weekly high-profile security-breach headlines to prove it, and all this security theater (password rotation, Zero Trust, etc) is, unsurprisingly, not working.
As for the SSO tax: if a vendor sleazes on you like that, then kick them to the curb and migrate to an alternative that won't. Preferably one that's FOSS and therefore *can't* do that to you.
If that means you have to do extra work? So be it. With the alternative being either sky-high fees or getting pwned, the extra work will pay for itself in short order.
If the alternative is FOSS but sucks? Pay somebody to work on it. Still cheaper in the long run.
@argv_minus_one @nicholas @phnt The issue is humans. It was always humans. Why have two factors if one factor is cryptographically perfect? Humans. Humans fuck up all the time. If the world was perfect you'd be right on all counts, but it's not, so stupid things happen all the time out of ignorance or malice or both. Whether or not you account for this and layer things properly will make or break you in InfoSec.
True, but increasing friction (with password rotation, MFA, etc) only encourages people to find workarounds to defeat the security measures instead of actually using them. That's why NIST recommends doing away with password rotation entirely.
Although I suppose that same problem also applies to my earlier suggestion of using FOSS alternatives…
@argv_minus_one @nicholas @7666
>hardware tokens gets stolen or left somewhere
>game over
Amazing security. This push for hardware tokens as the solution to everything security genuinely annoys me. Instead of securing a single factor like a password with a second factor like a hardware token, the current push is to replace passwords completely with tokens, still making it a single factor authentication.
>hardware tokens gets stolen or left somewhere
>game over
Amazing security. This push for hardware tokens as the solution to everything security genuinely annoys me. Instead of securing a single factor like a password with a second factor like a hardware token, the current push is to replace passwords completely with tokens, still making it a single factor authentication.
Yes, that's the idea. MFA is security theater. The sum of a weak authentication method and a strong one is not significantly greater than the strong one by itself. The weak one is purely decorative. If both of them are weak then both of them are purely decorative. If both are strong then one is unnecessary.
And how the hell do you lose your hardware token without noticing? If it's gone, so are your car keys, your house keys, and your key into the office building!
And if you're worried people won't report a lost hardware token, you should be able to solve that with company policy:
“If you lose your hardware token, the punishment is we dock your pay by like $2 for a replacement token. If you lose your hardware token and try to cover up the fact that you lost it, the punishment is you're fired. Tokens are cheap; security breaches are expensive.”
@argv_minus_one @nicholas @7666 If I can take your token from you in a workplace and within 5 minutes or less gain access to everything, that is true security theater. Meanwhile you might get my token, but you probably aren't getting the password from me unless <xkcd 538>. If I can gain access to your whole computer by plugging in your token I stole, that is not security I would want near anything important.
>And how the hell do you lose your hardware token without noticing? If it's gone, so are your car keys, your house keys, and your key into the office building!
Idk, you leave your keys somewhere while on lunch in <company canteen>, i steal it from you in a hallway because you didn't have it securely on you,... Many different ways to achieve that. All it takes is a few minutes for someone prepared. Point is, your systems security might be high, but your physical security now sucks. In this case a smart card reader would actually be a really good solution and using your card to also log in to your computer, but barely any laptop now has a smart card reader.
On that note, it still vexes me that you can't setup a hardware key with password login on Windows I think. I have a hardware token on me almost at all times and I can set it up as a second factor on Linux with enough caffeine, but Windows can't do it (especially with an offline account).
>And how the hell do you lose your hardware token without noticing? If it's gone, so are your car keys, your house keys, and your key into the office building!
Idk, you leave your keys somewhere while on lunch in <company canteen>, i steal it from you in a hallway because you didn't have it securely on you,... Many different ways to achieve that. All it takes is a few minutes for someone prepared. Point is, your systems security might be high, but your physical security now sucks. In this case a smart card reader would actually be a really good solution and using your card to also log in to your computer, but barely any laptop now has a smart card reader.
On that note, it still vexes me that you can't setup a hardware key with password login on Windows I think. I have a hardware token on me almost at all times and I can set it up as a second factor on Linux with enough caffeine, but Windows can't do it (especially with an offline account).
You don't need xkcd 538 to break a weak password. And since we're talking about the password people type in by hand to login to their computers, not passwords stored in a password manager, goodness knows that password is going to be weak.
I suppose it would take more than 5 minutes, though.
Then again, if we're talking about the kind of ninja who could sneak into a corporate office building unnoticed, he probably already saw you type in your password…
@argv_minus_one @nicholas @7666
>Then again, if we're talking about the kind of ninja who could sneak into a corporate office building unnoticed, he probably already saw you type in your password…
You can have someone on the inside. That isn't that unheard of these days, especially in large profile companies that would already have hardware tokens. That said, offensive security is also a thing and yes, if you see couple of those guys in action, they can look like ninjas.
>Then again, if we're talking about the kind of ninja who could sneak into a corporate office building unnoticed, he probably already saw you type in your password…
You can have someone on the inside. That isn't that unheard of these days, especially in large profile companies that would already have hardware tokens. That said, offensive security is also a thing and yes, if you see couple of those guys in action, they can look like ninjas.
If the bad guys already have someone on the inside of your organization, you're already breached. They don't need to hack anything because they already have access legitimately.
The only way I can think of to solve that problem has absolutely nothing to do with computers: create a culture of mutual loyalty between employer and employee, so that no one is willing to betray the company in the first place.
Good luck selling that proposal to the shareholders, though…
I'm shocked to learn that Windows makes it hard to use a hardware token to log in. I remember Windows championing smart cards back in the 1990s when everybody else had never heard of anything other than passwords.
Old-fashioned card-slot-type smart card readers do seem to be a thing of the past now, but a cursory web search says some laptops have NFC interfaces and some smart cards are NFC enabled. That must be what the cool kids are using these days.
@argv_minus_one @nicholas @7666
>but a cursory web search says some laptops have NFC interfaces and some smart cards are NFC enabled.
Dell used to have NFC smart card readers on some of their laptops at least until recently. Don't know if they still do.
>but a cursory web search says some laptops have NFC interfaces and some smart cards are NFC enabled.
Dell used to have NFC smart card readers on some of their laptops at least until recently. Don't know if they still do.
@phnt @nicholas @7666 @argv_minus_one Sorry to interject but I just updated #Pleroma and I want to make sure federation is working (as the logs had a message saying it might not be working). If you can see this please say 'hi' or give an like/emoji reaction 🙏
@argv_minus_one @phnt @nicholas @7666 if my workplace wouldn't enforce password rotation, I could pick a secure password without having to worry about by the time I memorized it, it already expired
so I just make variations on a simple password…
so I just make variations on a simple password…
@LunaDragofelis @nicholas @7666 @argv_minus_one Thanks for proving my point why aggressive password rotation is harmful.