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

431–440 of 539 posts

Re: Frequent reauth doesn't make you more secure

#431

Post by lucideer »

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…

> But these don't seem to be authoritative enough for IT / security,

As someone who's worked for a cybersecurity team that was responsible for enforcing password rotations in a company, trust me when I say that nobody was more eager to ditch the requirement than we were. This is enforced by external PCI auditors & nobody else.

Fwiw, PCI DSS 4.0 has slightly relaxed this requirement by allowing companies to opt-out of password rotation if they meet a set of other criteria, but individuals employed as auditors tend to be stuck in their ways & have proved slow to adapt the 4.x changes when performing their reviews. They've tended to push for rotation rather than bothered to evaluate the extra criteria.

Re: Frequent reauth doesn't make you more secure

#432

Post by jerf »

bisby wrote: post #327
deathanatos wrote: post #297

Earlier quoted context omitted.

I just let the keyring roll a completely new password. For some reason, all of my employers do require this insanity, but not on the one password I have to actually type.

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.

This is not as illegitimate as it may sound to you. You may not hear about "getting someone's SSH keys" very often, because we only hear about "vulnerabilities" on places like HN and this isn't a "vulnerability" in any software.

But getting someone's SSH keys and then running off and doing other things is a very normal part of any focused attack in which attackers use some foothold to start pivoting into your systems. It's one of the first things an attacker will check for, precisely because it's high likelihood they'll find one and high reward if they do. It's an extremely serious threat that you don't hear about very often, just like you may not hear about "the sudoers file left something open with passwordless access it shouldn't have and the attackers lifted themselves up to root from there" even though it's a major part of many actual incursions. I'm aware of multiple cases in which someone's passwordless SSH key played a part of the process.

So that really is a legitimate problem and turning them off is not security theater but can have a real impact on your security posture. The problem is solved nowadays with adding other auth to the process like proving possession of a physical token as part of the login process.

Re: Frequent reauth doesn't make you more secure

#433

Post by mlinhares »

reddalo wrote: post #117
mlinhares wrote: post #101

Earlier quoted context omitted.

Why in the world does it need you to type a code id you have already accepted it at the other device? This whole flow is stupid, I guess they want to cover their asses.

I agree with you, but it's the same reason why Microsoft asks you to type a numeric code generated by their Outlook app in order to login. It's to prevent people from dismissing the alert by clicking "OK" without even reading (especially if they're in the middle of something else, e.g. during a scam phone call).

TIL, this now makes a lot of sense, won't be as mad about it anymore.

Re: Frequent reauth doesn't make you more secure

#434

Post by dcow »

fsckboy wrote: post #272
dcow wrote: post #261

Earlier quoted context omitted.

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.

> 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.

No, like I don’t believe the math. It’s not about not wanting to believe the math. I don’t believe the mathematical conclusion is practically true even if there may be something theoretically interesting to talk about, like the monty hall problem.

Re: Frequent reauth doesn't make you more secure

#435

Post by mooreds »

twodave wrote: post #425
mooreds wrote: post #299

Earlier quoted context omitted.

The auditors aren't writing the compliance guidelines, are they? Just enforcing them. I'd say you want to send these articles to the people writing such guidelines. What am I missing?

No, you’re right. Though I think there’s definitely a gap between standards bodies like NIST and the AICPA or whoever sets the SOC2 standards these days. I think some of the answer is just momentum. Customers have come to expect it of their vendors, specifically because it is security theatre, something they can point to if anything goes wrong.

> because it is security theatre, something they can point to if anything goes wrong.

Yeah, there is space between "this is a good practice and it's nice to be able to check the box" and "this is a standard someone else dictated but it will cover my butt if anything happens" unfortunately.

I get it, I depend on standards all the time (food safety, equipment certification) so I understand the desire, but darn it's frustrating when they are viewed as a cure-all.

Re: Frequent reauth doesn't make you more secure

#436

Post by mooreds »

blueflow wrote: post #390
account42 wrote: post #379

Earlier quoted context omitted.

Or just if they changed to a more secure hash algorithm themselves and want to upgrade users still on the older insecure one.

This can be done at login time without the user noticing, as you have the plaintext password for a moment.

Yeah, this is the best practice. We offer that in our product.

But it's possible that you could follow the best practice and still force a reset. This could be because:

* the customer or provider doesn't want to wait for everyone to log in

* they've waited for N months and now there is a block of users who have not logged in yet and they think it is worth the user annoyance to just force them all to reset their password

Re: Frequent reauth doesn't make you more secure

#437

Post by _dark_matter_ »

rocqua wrote: post #348
valleyer wrote: post #304

Earlier quoted context omitted.

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

No, you can do it safely. The idea is to have the password renewal process also ask for the previous password. This means the password changing method doesn't need to store a plaintext password, but still has access to the old plaintext password when changing. It's still not a great idea, but that's because nagging your users will see them choose worse passwords.

Oh so trivially bypassable by changing your password twice.

Re: Frequent reauth doesn't make you more secure

#438

Post by HocusLocus »

pcardoso wrote: post #377
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…

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

Password changed.

Password changed.

Password changed.

Error at : broken pipe

Re: Frequent reauth doesn't make you more secure

#439

Post by tom_m »

I don't know, I still think it's a good idea to change passwords every so often. At the rate databases get leaked, you can't always rely on the strength of the hash and the time it used to take to crack given hardware getting faster and faster. Yes it can cause a minor inconvenience if locked out, but that's better than the alternative depending on what that system was.

But...worry not, we're about to embark on a world with a whole lot less security now thanks to AI and laziness.

Re: Frequent reauth doesn't make you more secure

#440

Post by BrandoElFollito »

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…

These recommendations live in a mythical world, but not in a company.

In a company, you have individual passwords known by many people. They are written here and there. They are passed to other orgs because something.

In this ideal world of a non company, you have MFA everywhere, systems with great identity management wher you get bearers to access specific data, people using good passwords and whatnot.

This is not true in a company. If this is true in yours, you are the lucky 1%, cheers (and I envy you).

A good cybersecurity team will try to find reasonable solutions, a password rotation is one of them, in a despaired move to mitigate risks.

And then you have trauma that will say "we cannot change the password because we don't know where it is used".

Armchair cybersecurity experts should spend 24h with a company SOC to get an idea of the reality we live in.

Post reply on HN