391–400 of 539 posts
Finally someone said it. This is a relic from when a row in a database table for a session id cost about $400. I'm joking of course but that's what literally was on the mind of early internet engineers. The only company that fights this is Google and apparently tailscale.
Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT. Many (most?) companies still do it, despite it now not being recommended by NIST: > Ver…
Stuff like ISO27001 still demands it. We have to rotate passwords, against modern cybersecurity practice, in order to comply with an information security standard.
Earlier quoted context omitted.
This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.
This is really just an optimization. It means that you don't need to do an expiry check on the regular token, only on the refresh token. It doesn't change the fact that you should be able to revoke a session before it naturally expires.
It's all a tradeoff. Yes, it means some user may have a valid token for ten more seconds than they should, but this should be factored into how you manage risk and trust in your org.
Earlier quoted context omitted.
I'm confused by this comment. Can you clarify exactly which poor design flow you're talking about?
1. Input username/password -> get email otp code. 2. Forget password -> get email for new password -> input username/new password -> get email otp code. The only actual security factor here is your [email, email password], everything else is just silly rigamarole.
Whether it is worth annoying some users in the password reset case to avoid making the login code slightly more complicated is going to depend on your specific situation.
Earlier quoted context omitted.
if my password has not been leaked it's insane that providers think i should rotate it, but this still seems to be standard practice for some completely baffling reason
There’s weird math that says your password or generally a secret key is more secure if it’s existed for less time (generated fresh) because there hasn’t been as much time to brute force it. I don’t believe it but some hardcore types do.
Instead, expiry is about “what are the chances that the secret has already leaked” and about choosing an acceptable compromise between rotation frequency and attacker loiter time - assuming that the system hasn’t been back doored, let’s put an upper limit on how long an attacker with the secret has access. And incidentally it also means that if you somehow fail to disable access for ex-employees, that lingering access will eventually take care of itself.
But as the article points out, expiry has always been controversial and it’s not clear that on balance expiry is a good control.
Forced password rotation and expiry seems the bigger problem; given that it causes people to get locked out so often, (e.g. if pw expires when on holiday), — often then requiring travelling to IT, or at least a few hours trying to get IT on the phone to reset, or chasing up colleagues who aren't locked out to get in touch with IT. Many (most?) companies still do it, despite it now not being recommended by NIST: > Ver…
Worse, it means that if an attacker can guess or otherwise obtain user names, the attacker needs nothing but network access to deny service to your users.
My favorite example is the iOS policy where it added more and more time before the next login attempt was allowed; small children kept locking their parents out of iPads and iPhones for weeks or months.
Earlier quoted context omitted.
I once had an employer that required us to use passworded SSH, and disallowed SSH keys, because they couldn't enforce that the SSH keys were passphrase protected, so just turned that option off. They said it was a PCI requirement, or something.
PCI requires multi-factor auth these days, so you’ll likely find now the ssh password will be your password plus a OTP at the end.
Earlier quoted context omitted.
I’ve personally experienced the password change require that “more than X characters be different than the old password”
Um, that's a really bad sign...
Earlier quoted context omitted.
No modern IT organization mandates periodical password changes since, I dunno, mid-2000's. edit : please note the "modern" qualifier, tons of IT orgs continue to mandate this anachronistic policy, sure, but those orgs aren't modern, the policy isn't a requirement for e.g. SOC2 or whatever, it's purely historical inertia.
Nope, not even close. IT depts continue this practice to this day. I had a friend in ~2015 that said they all had barcode scanners plugged into their computers (not 100% what they used them officially for) and so people would print their password as a barcode and stick it under their desk so they just had to scan the barcode to login (most/some/all? USB barcode scanners present as a keyboard and simply send scans as…