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

511–520 of 539 posts

Re: Frequent reauth doesn't make you more secure

#511

Post by beaugunderson »

chillfox wrote: post #421
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…

The requirements usually don’t come from IT. It’s usually on the checklist for some audit that the organisation wants because it lowers insurance premiums or credit card processing fees. In some cases it’s because an executive believes it will be good evidence for them having done everything right in case of a breach. Point being the people implementing it usually know it’s a bad idea and so do the people asking for…

> Point being the people implementing it usually know it’s a bad idea and so do the people asking for it. But politics and incentives are aligned with it being safer for the individuals to go along with it.

we've gone through HITRUST several times and I just told them we weren't going to do forced password rotation since NIST had updated their guidance. it was fine!

and every time we get a vendor security questionnaire I just say "no, we don't do this because it's old guidance" and link to NIST... no one has ever complained.

Re: Frequent reauth doesn't make you more secure

#512

Post by __turbobrew__ »

thwarted wrote: post #167

The MFA is getting out of control too. Go to vendor's tool/website, which uses some SSO method and redirects/prompts me to login with the SSO provider. Authenticate to SSO providers, which requires an MFA. Redirects me back to the vendor's tool/website, which prompts for its own MFA. And the vendor's tool's configuration has a security setting that requires all accounts to have MFA, even if they are authenticated via…

I have this at my work. One system requires SSO so I go to the SSO gateway, touch my yubikey to login to SSO, and then I am redirected back to the original app, and it also wants my yubikey so I touch it again, and then I am finally granted access.

The root of trust is my yubikey in both cases but the implementation was lazy.

I brought this up to our security team and they shrugged.

Re: Frequent reauth doesn't make you more secure

#513

Post by yardstick »

mazone wrote: post #505
yardstick wrote: post #491

Earlier quoted context omitted.

Presumably at some point in your environment you are doing MFA? Just not at every step? Ie If someone broke into your office, opened computer, inserted the hardware security key, would they get in? Or is there something else non-physical going on? Like the initial login is password + security key, and you can demonstrate the ssh keys never leave the secured PCs etc.

It is not about MFA or not but to demonstrate the process is secure for the purpose. It can be complicated but a example. TOTP that is very common used with passwords is regarded as MFA (tho most of the time software based on phone) but have many problems regardless - many time replayable - can be intercepted - implementations look different - recovery code reuse problems etc. On the other hand, using only passkeys d…

It’s always interesting to hear other people’s approaches- Thanks for the insights!

Re: Frequent reauth doesn't make you more secure

#514

Post by brendoelfrendo »

mrandish wrote: post #163
brendoelfrendo wrote: post #132

Earlier quoted context omitted.

Right, the numeric code is proof of intent. In theory, tapping "ok" or "yes, this is me" should be proof of intent. In reality, it's common for those who have compromised someone's password to flood people with these notifications and auth prompts to get them to eventually say "ok," even if by accident.

> it's common for those who have compromised someone's password to flood people with these notifications and auth prompts And by excessive reauthing, legit platforms and apps are helping scammers by conditioning users to click "OK" or enter a passcode reflexively just to get on with their lives. Frequent reauth makes everyone less secure.

I don't disagree, and I appreciate your keeping the conversation on-topic, but that's very much an incomplete picture. I think our modern app ecosystem as a whole conditions users to click "OK" reflexively. A hypothetical app wants permissions for your camera, location, and file storage. If you click OK, you can use the app. If you don't, some functions may not work. I think the average user gets caught in the desire to use an app for its intended purpose and the need to tinker with settings - which they may or may not understand - if they want to use that app securely. So, they just say OK to everything.

Of course, that's not the only situation with these push notifications. MFA fatigue attacks are a real thing, hammering the user with as many notifications as they can in a short time. Maybe the user assumes it's a bug, maybe they try to deny the push notification but eventually hit the wrong button, maybe they just want it to stop; it's not so much about exploiting user conditioning as it is assuming that if you force people into an unfamiliar situations, that some of them will eventually slip up.

Re: Frequent reauth doesn't make you more secure

#515

Post by CjHuber »

arccy wrote: post #384
apitman wrote: post #240

Earlier quoted context omitted.

"Trust this device" is the modern day elevator door close button.

I've found that it's only american elevator door close buttons that don't work. The rest of the world manages to keep them operational.

As a obsessive door close button presser, I can definitely tell you that there are many elevators in Europe where the button doesnt work either

Re: Frequent reauth doesn't make you more secure

#516

Post by jerf »

seadan83 wrote: post #483
jerf wrote: post #479

Earlier quoted context omitted.

"Though, if someone gets that far, couldn't they also install a key logger on the users system?" There are a ton of situations where that is not the case. They may be using directory traversal from something else to read a key without even necessarily being on the system. They may be on the system at 1am local time, and want to get in and get their job done before the user is even there. They may be on a server somew…

I appreciate the additional insights, but the premise I'm pushing back on is whenever a SSH key is read, then the user account is by necessity compromised in order to do so. Given that level of a breach, there are myriad ways for an attacker to escalate privilege and exploit their access without worrying about a password on the SSH key. Namely, at that point, cracking the password on the SSH key is a tractable proble…

I can tell you've not been involved in defending against an active attack. You, as the defender, do not get to play the game of "well, if I squint and read it that way, that attack wouldn't work". The attackers get to play "well, hey, if it turns out I do this and that and push it through the other thing, I get access". They are the ones who get to flow through any crack they can find. They are the ones who get to do logic chopping like you're trying to do. You don't get to argue "Well gosh, that team shouldn't have left that one permission open on that one system, that's not a best practice, if they'd followed best practices 100% of the time the attackers couldn't have gotten in...". Your job is to pick up the pieces.

Re: Frequent reauth doesn't make you more secure

#517

Post by kelnos »

SAI_Peregrinus wrote: post #270
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…

Does anyone not add the year & month of the last password change to the end of their password? E.g. PascalCasePassphraseGoesHere2025-06, then at the next required change in (for example) 6 months: PascalCasePassphraseGoesHere2026-01. It almost certainly fits the inane "letter, number, and special character" requirements they probably have, complies with "different from your last X passwords", and is easy to keep trac…

When I first set up an account at a new org or whatever, I don't think about the possibility of rotation later, but once I get my first "your password has expired and needs to be reset" message, I just add a counter to the end of the password that I increment each time I'm required to change it. Successive passwords have no less entropy than the original password, anyway.

Fortunately, I haven't encountered a system that does a similarity check when changing the password.

Re: Frequent reauth doesn't make you more secure

#518

Post by [deleted] »

kelnos wrote: post #517
SAI_Peregrinus wrote: post #270

Earlier quoted context omitted.

Does anyone not add the year & month of the last password change to the end of their password? E.g. PascalCasePassphraseGoesHere2025-06, then at the next required change in (for example) 6 months: PascalCasePassphraseGoesHere2026-01. It almost certainly fits the inane "letter, number, and special character" requirements they probably have, complies with "different from your last X passwords", and is easy to keep trac…

When I first set up an account at a new org or whatever, I don't think about the possibility of rotation later, but once I get my first "your password has expired and needs to be reset" message, I just add a counter to the end of the password that I increment each time I'm required to change it. Successive passwords have no less entropy than the original password, anyway. Fortunately, I haven't encountered a system t…

[deleted]

Re: Frequent reauth doesn't make you more secure

#519

Post by Viliam1234 »

claudex wrote: post #382
pcardoso wrote: post #377

Earlier quoted context omitted.

I once wrote a script to change my password randomly X times and then back to my original password. Worked like a charm.

There are policies to prevent changing the password more than once a day to prevent that. I've encountered it in several places

The obvious solution is to have a Monday password, a Tuesday password, etc.

Re: Frequent reauth doesn't make you more secure

#520

Post by motohagiography »

recently came to appreciate the irony in proving who we are via catchpas, password complexity, and context switching 2FA is that any security method without personal irritation will get automated and broken. therefore, all security requires for us to prove the authenticity of our being by demonstrating suffering somehow- and an authentication method without evidence of suffering cannot prove we are real.

it's funny, but tracks infosec life pretty well, that we've stumbled into a proof that the necessary condition for a system to verify we are alive and are our authentic being is to offer up some minor suffering to it.

Post reply on HN