Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Frequent reauth doesn't make you more secure

tailscale.com

Post reply on HN
Print view View original

361–370 of 539 posts

Re: Frequent reauth doesn't make you more secure

#361

Post by hashstring »

awesome_dude wrote: post #181
hashstring wrote: post #172

There’s another closely related one, changing passwords periodically. A lot of infosec authorities move away from this. However, I always wonder, does it make sense for an org to stop with periodic password resets if: 1. the org is not very capable in detecting all account compromises; 2. in practice, users leak their passwords (e.g. by getting phished) and not all of them lead to direct intrusions, some credentials…

> I believe that in practice, forced password changes at least ensure that unknown compromised passwords will become outdated at some point in time, and I think that this is positive. password password1 password2 password! Password1! People get predictable on how they modify their passwords when that policy is instituted. Mostly because it's a royal pain in the ass to have to generate a new password AND remember it.…

On the password1, password2, password2! flow, yes this happens and is bad, but not everyone is like this. I would say, any change (even a weak one) to a compromised password helps (even a bit). Because it requires attackers to test more passwords, providing more opportunity to detect them.

I agree, on moving the weak point to certain service providers when doing this.

Unsolvable: hm, but isn’t the idea to make it more secure, not necessarily solve it completely?

Re: Frequent reauth doesn't make you more secure

#362

Post by imtringued »

majkinetor wrote: post #325
bigfatkitten wrote: post #234

Earlier quoted context omitted.

In the corporate space you should move away from passwords entirely. Smart cards have had pretty solid ecosystem support for the past two decades thanks to the U.S. Government and HSPD-12, and now we’ve got technologies like webauthn that make passwordless authentication even easier.

And require smart card, reader, drivers etc... nah

Every work laptop I've used had a smart card reader directly built into it and I've never used smart cards.

Re: Frequent reauth doesn't make you more secure

#363

Post by thyristan »

bux93 wrote: post #350
thyristan wrote: post #112

Earlier quoted context omitted.

Even worse. NIS2 in the European Union makes password changes legally required for many organisations. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=PI_... 11.6.2 (c)

Yikes, whoever wrote that should be ashamed of themselves. On the bright side, it doesn't specify how long the predefined interval should be, and says entities are to 'ensure the strength of authentication is appropriate to the classification of the asset to be accessed' - so, in order to ensure the appropriate strenght the interval should be 100 years is totally defensible IMHO. The whole paragraph doesn't take MFA…

11.3. (a) mandates multi-factor auth for priviledged and sysadmin accounts, and 11.7. requires multi-factor auth depending on criticality determinations. All in addition to whatever is in 11.6.

But the thought about the non-specified intervals in 11.6. is great, nowhere in there are any numbers to be found. So basically one can do the sensible thing, set some huge numbers that are no problem in practice and everything is fine.

Re: Frequent reauth doesn't make you more secure

#364

Post by HPsquared »

notpushkin wrote: post #345
tiltowait wrote: post #333

Earlier quoted context omitted.

This comment reminded me of a talk I saw[1] about Apple's password generation algorithm. Apparently (and unsurprisingly), they have a list of offensive terms the system is designed to avoid. I expect this is common-enough practice in most popular password managers, but probably not all. [1] https://www.youtube.com/watch?v=-0dwX2kf6Oc

It would be fun to make a passphrase generator that always includes a profanity.

So long as they factor that into the "bits of entropy" calculation.

Re: Frequent reauth doesn't make you more secure

#365

Post by imtringued »

Retric wrote: post #222
xp84 wrote: post #214

Earlier quoted context omitted.

Password rotation does nothing more than get you to use 1234abcd@ 1234abcd@1 1234abcd@2 1234abcd@3 I'm becoming pretty convinced that at least in the corporate space, we'd be way better off with a required 30 character minimum password, with the only rules being against gross repetition or sequences. (no a * 30 or abcd...yz1234567890 ). Teach people to use passphrases and work on absolutely minimizing the number of t…

I’m doubtful a 30 digit minimum password is a meaningful improvement over a 20 digit password here. Meanwhile actually typing in very long passwords adds up across a workday/year especially with mistakes.

You're only supposed to type your password at most once a day to sign into SSO.

Re: Frequent reauth doesn't make you more secure

#366

Post by Xss3 »

montebicyclelo wrote: post #189

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…

Hot take, password requirements are a necessity to prevent id10t errors.

Another hot take, calling them passwords instead of pass phrases was a mistake.

People have no problem making a secure pass phrase like 'apophis is coming in 2029’.

It uses special chars and numbers, but some websites would reject it for spaces and some for being too long.

I say these are hot takes despite aligning with NIST because I've never seen a company align with them.

Re: Frequent reauth doesn't make you more secure

#367

Post by mattmanser »

klysm wrote: post #305
valleyer wrote: post #304

Earlier quoted context omitted.

Um, that's a really bad sign...

To elaborate for the uninitiated, that means they are storing it in plaintext somewhere.

No it doesn't. Shows you how complicated all this is and how the un-initiated (including me) should learn to not give their two cents.

When you do the password change it asks you for the old one, that's how it knows.

So it asks for old + new, checks old is correct against the hash, and then compares old + new likeness.

So it all happens in memory.

Re: Frequent reauth doesn't make you more secure

#368

Post by eru »

apitman wrote: post #317
eru wrote: post #287

Earlier quoted context omitted.

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?

Yes, if it takes one cpu second to hash a password, it'll take a while to try a few like this.

You can do a quick check against the last password (which you have in clear, because it was just entered), though.

Re: Frequent reauth doesn't make you more secure

#370

Post by maccard »

tetha wrote: post #27
d4mi3n wrote: post #7

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device. In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentica…

I was somewhat pondering along these lines. At work, we have somewhat of a two-staged auth: Once or at most twice a day, you login via the ADFS + MFA to keycloak, and then most systems depend on keycloak as an OIDC provider with 10 - 15 minute token lifetimes. This way you have some login song and dance once a day usually, but on the other hand, we can wipe all access someone has within 15 minutes or less for service…

You say users don’t notice much of this - I disagree. I had to authenticate with our SSO provider 9 times yesterday (I started counting because it’s getting so frustrating). All on the same device; once on initial login, once on VPN connect, once to the SSO dashboard, twice (!) to Microsoft for Outlook and Azure access via our IDP, once for perforce (no 2FA required thankfully) and three times to Jenkins because it doesn’t remember the OIDC token if you close your browser. IT say it’s normal and here I am spending 10 minutes a day waiting for my Authenticator app to log in.

I work on a corporate controlled machine, with a corporate VPN app and custom certificates installed. I’m pretty sure it knows when I sneeze, but yet remembering who I am for more than 15 minutes seems out of scope.

Post reply on HN