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

521–530 of 539 posts

Re: Frequent reauth doesn't make you more secure

#521

Post by Perz1val »

beaugunderson wrote: post #511
chillfox wrote: post #421

Earlier quoted context omitted.

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 questionnai…

Should you also question their competence? They should know, right?

Re: Frequent reauth doesn't make you more secure

#522

Post by odo1242 »

notpushkin wrote: post #344
yardstick wrote: post #337

Earlier quoted context omitted.

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.

Isn’t there a way to ask for OTP after initiating the SSH session?

One issue with this is it makes it hard for scripts to log in (this may be what you want)

Re: Frequent reauth doesn't make you more secure

#523

Post by throwaway1854 »

beaugunderson wrote: post #511
chillfox wrote: post #421

Earlier quoted context omitted.

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 questionnai…

is a judge going to think the same way if insurance doesn't pay and you take them to court though, in the event of a breach, etc.

After all it's perfectly possible to do interior work in your house that isn't up to code, but if it burns down in a fire, the insurance company will investigate and may not pay out if they find out.

Re: Frequent reauth doesn't make you more secure

#524

Post by beaugunderson »

throwaway1854 wrote: post #523
beaugunderson wrote: post #511

Earlier quoted context omitted.

> 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 questionnai…

is a judge going to think the same way if insurance doesn't pay and you take them to court though, in the event of a breach, etc. After all it's perfectly possible to do interior work in your house that isn't up to code, but if it burns down in a fire, the insurance company will investigate and may not pay out if they find out.

in this case I'd be more worried about being in court trying to explain why we knowingly used an inferior approach (forced password changes) when we knew the newer approach resulted in higher security... that is a vastly different analogy than being "out of code". additionally, noting the deviation from the old, less secure standard up front (in our HITRUST submissions) and with our customers (in their vendor questionnaires) provides evidence that we are going above and beyond vs. shirking a duty.

Re: Frequent reauth doesn't make you more secure

#525

Post by beaugunderson »

Perz1val wrote: post #521
beaugunderson wrote: post #511

Earlier quoted context omitted.

> 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 questionnai…

Should you also question their competence? They should know, right?

this is less about competence and more about update schedules... we happen to feel like it's worth incorporating guidance that's newer than what HITRUST or our customers require us to (though the guidance in question was updated by NIST eight years ago... sometimes it takes a long time for this stuff to change)

Re: Frequent reauth doesn't make you more secure

#526

Post by h4kunamata »

Anything that generates fatigue doesn't work. Passwords expiring every 2 months?? Users will user password like "test1" "test2" test3" and so on.

Companies don't even have a password manager so few employees use the browser to save passwords, others use their own password manager which comes with its own security risks like that service, LastPass IIRC, that got breached.

When working for big companies, there are so many wrong processes and practices which provides the bare minimal and that is fine.

Support team cannot care to report the problems coz they don't wanna more work, my laptop always connect to a restricted network while in the office which kills internet access to everything, that in turn cause the laptop to take 20-30 to turn own while it tries to run AD policies.

The whole process is broken within the companies culture, keep it minimal, repetitive and that "should work, next"!

Re: Frequent reauth doesn't make you more secure

#527

Post by seadan83 »

jerf wrote: post #516
seadan83 wrote: post #483

Earlier quoted context omitted.

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…

> I can tell you've not been involved in defending against an active attack.

Um... I'm really happy you can mind read dude.

The whole premise here is whether passwords on SSH keys actually help.

SSH keys tend to live in two places: (1) a developers laptop, (2) some sort of CI/CD machine.

The passworded SSH key helps in case (1) only when a person walks away from the laptop and leaves it unlocked. An attacker can't simply then open up a SSH terminal and then SSH to whatever they see in the history. Or, it helps in case a person has a laptop that never locks and the org is simply trying to buy enough time to rotate the persons public keys before the SSH key password is cracked. The SSH key password can buy time, yes - but it does not change the actual security posture.

In case (2), all sorts of considerations need to be made. Though, any password would need to be encoded in a way that is just as accessible as the secret key itself. In case (2), the password really does nothing.

So, yeah, passwording a SSH key does not really help very much. If the keys are left around, then it is the fact they are left around that is a problem. The solution is not to create a scanner that all SSH keys have a password on them, but instead be sure that no SSH keys are installed on systems where they do not belong.

> They are the ones who get to flow through any crack they can find.

I would agree, that is why defense in depth is a good principle just as zero trust security.

So.. passworded SSH keys are kinda really security theater. Please give an attack vector on a persons laptop where the password SSH key is going to stop an attack that is otherwise unachievable. I'll steel man the counter position and mention that physical access is one case (except in that case we are only buying time). AFAIK, that is really it, that is the one place where a password on a SSH key helps.

To hack a persons laptop and read contents in the .ssh directory is a full compromise. To pick up the pieces after that, you need to do things like make sure the compromise can be observed, that privilege escalation is limited. If it comes down to the password on a SSH key being last line of defense - it's game over.

Keep in mind, your burden of proof is to show cases where SSH password actually provides a true increase in real security. The meta conversation of "well, you obviously never have.." is not interesting.

I'll note, if it is the case that SSH passwords are actual security - then, presumably you would feel comfortable stating "yeah, the SSH key was stolen, but nothing needs to be done because the SSH key had a password on it!" It's like the locks on doors, it is for the honest people, the criminals are only slowed down but not stopped by most door locks.

Re: Frequent reauth doesn't make you more secure

#528

Post by fastball »

ars wrote: post #482
fastball wrote: post #282

Earlier quoted context omitted.

Not having to start all my API handlers with a call to the DB to check token validity significantly improves speed for endpoints that don't need the SQL db for anything else, and reduces the load on my SQL db at the same time.

Does it actually improve speed though? The DB check is simply "does this key exist", it can be done in a memory database, it doesn't have to be the same DB as the rest of your data. Validating a token requires running encryption level algorithms to check the signing signature, and those are not fast.

It definitely improves speed. Crypto algos are slow, but they are not slower than a TCP roundtrip. Even a memory database is not generally running on the same machine, so there is still a round-trip cost vs a JWT. Also, although it doesn't need to be the same DB, it adds more complexity to store such a key in a different DB than your actual user data (where the original auth logic is coming from).

Re: Frequent reauth doesn't make you more secure

#529

Post by fastball »

RadiozRadioz wrote: post #507
fastball wrote: post #282

Earlier quoted context omitted.

Not having to start all my API handlers with a call to the DB to check token validity significantly improves speed for endpoints that don't need the SQL db for anything else, and reduces the load on my SQL db at the same time.

Then don't hit the SQL DB directly, cache the tokens in memory. Be it Redis or just in your app. Invalidate the cache on token expiry (Redis has TTL built in). UserID -> token is a tiny amount of data.

And now I need to invalidate the cache if the key is invalidated. Also this cache cannot be updated/invalidated atomically, like I can if I'm just storing a refresh key in the SQL db. Caching in Redis is more complex and more prone to error than access/refresh token systems.

Re: Frequent reauth doesn't make you more secure

#530

Post by dspillett »

thih9 wrote: post #418
dspillett wrote: post #399

Earlier quoted context omitted.

Not if the check is done client-side, so the plain password never leaves you local domain. Of course the check being done client-side means that it isn't difficult to skip if you are inclined to make a smidgin of effort.

It can be done server side too, the old password can be sent along the new one and the server can verify it.

Yes, what I meant to say that it doesn't even have to be done server-side, so the fact it happens doesn't imply the server ever sees the old password beyond it's initial setting.
Post reply on HN