[dead]
Frequent reauth doesn't make you more secure
311–320 of 539 posts
Re: Frequent reauth doesn't make you more secure
#312Forced 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…
[dead]
Re: Frequent reauth doesn't make you more secure
#313I hate Apple products for this. I see this pattern across all apple products - not one. On my mac, I setup my touch ID, and log in to my Apple account on the App Store. Time and again, when I try to install apps, it keeps repeatedly prompting for my password, instead of letting me just use my touchID. This applies to free apps as well, which is again silly beyond what is already enough silliness. I briefly see this o…
[dead]
Re: Frequent reauth doesn't make you more secure
#314Earlier quoted context omitted.
> I don’t believe it but you have to believe it, it's true, you just think it's not the greatest threat or that the response to mitigate it (for example, using a pattern of temporary passwords to facilitate remembering them) would be worse than the disease.
if it causes 90% of people to just enter a simpler password, out of frustration and “fatigue”, then this is irrelevant IMO. Theory doesn’t take into account human behavior. It’s especially annoying when a company enforces these brain dead policies on employees. You want people to waste mental effort changing their passwords by 1 letter every 3 months, just to appease some IT manager? Give me a break lol. I’d rather h…
That's what baffles me. Somehow security NEVER acknowledges that security theater, cognitive overload and constant friction makes users more inclined to make bad decisions, repetition over months make this even worse.
Hackers need just one chain of tired persons to breach a system. Sometimes length(chain) = 1, that's when bad things happen.
Anecdotal PS: I used to work at a bank and had to rotate my password monthly (sometimes even more, because there were unfederated systems that required another password, also with rotation). Eventually all my passwords became [short STRING] + [autoincremental INT]. We had MFA, so it didn't matter that much, but that makes it even more hilarious.
Re: Frequent reauth doesn't make you more secure
#315Forced 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…
I think a lot of people in IT know these things but having a 'strict' auth policy makes them seem competent so they just go with that. Besides there is not much incentive to make authentication efficient since the frustrated users are a captive audience not paying customers.
Re: Frequent reauth doesn't make you more secure
#316Earlier quoted context omitted.
There is very little incentive to actually do information security correctly - because hardly anyone can tell if you have - consequently there are very few people who try. It is all just theater to cover their asses, and they'll admit it under the right circumstances. They don't want to change idiotic policies like this because it means they'd have to admit they've been dogmatically enforcing counter-productive polic…
Hardly anyone can tell, until everyone can tell, because you have a breach. It's similar to the idea that if you aren't doing restore drills you aren't really taking backups. But people rarely test their auth rules.
You could do everything correctly and still have a breach, so practitioners are quite fatalistic about it. The key is to diffuse decision making responsibility so that its not clear who can be fired.
Re: Frequent reauth doesn't make you more secure
#317Earlier quoted context omitted.
Doesn't enforcing this require storing the password in cleartext somewhere, which is a much more dangerous concept to begin with?
In practice, that's probably how it's done. But in theory: no. Assume you keep the hashes of the last few passwords around. Then you can search in the 'neighbourhood' of the new password to check if any of this matches the old password's hash. By neighbourhood, I mean something like within a small edit-distance, where the kind of edits depend on what measure of similarity you want. If you only care about similarity t…
Wouldn't this be super slow if you're using a proper password hashing algorithm?
Re: Frequent reauth doesn't make you more secure
#318I just joined a fintech company. It is so crazy, everything logs out daily, to login you have to input a complex password plus the 2FA, you have to run everything through a Citrix VDI. Really bad.
Only once a day? Sounds heavenly. Try every time you turn around and use your air-gapped dev PC for 5 minutes, while trying to keep a reference PDF from online up on your corporate PC to read.
Re: Frequent reauth doesn't make you more secure
#319Earlier quoted context omitted.
Remember how 1Password used to install itself as a custom keyboard that could "type" your passwords into arbitrary text fields anywhere in the OS, before password management specific hooks were added? It would be nifty if your phone could just connect to other devices as a BT keyboard and type in passwords there too. Probably not worth the actual fuss of pairing a BT device, but if that part were not so painful it co…
One major flaw in this approach is the one-way channel (keyboard input) prevents the password manager from knowing if it is supplying credentials to the correct recipient. Phishing attacks are relatively common and users expect a password manager to know these things, even in situations like you have described where it’s clearly impossible. I think this is why this approach hasn’t succeeded in the marketplace and FID…
Yeah, certainly a proper security module / passkey-type approach is ideal, it would be hard to justify all the bother of developing a bluetooth typer if really the only use-case for it is legacy devices that are old enough to not have an OS supporting the client app, but new enough to still pair with a device pretending to be a bluetooth keyboard.
Re: Frequent reauth doesn't make you more secure
#320Earlier quoted context omitted.
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.
Having a short session expiry is a workaround for not being able to revoke a token in real time. This is really the fault of stateless auth protocols (like OAuth) which do offline authentication by design. This allows authentication to scale in federated identity contexts.
OAuth2 is not inherently stateless.