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

281–290 of 539 posts

Re: Frequent reauth doesn't make you more secure

#281

Post by HeavenFox »

LordDragonfang wrote: post #42

There's supreme irony with Tailscale being the one posting this -- because one of my biggest annoyances with the service is that, afaict, there's no way to set up a device so that it never expires. I just had two devices - one of which was my main server - I was using it with require re-auth out of nowhere and break one of my workflows. If I had not already set up separate remote access to the server, it would have b…

Yes, and it's especially frustrating for tailscale, since when it signs you out on the server you are often not in a position to re-auth

Re: Frequent reauth doesn't make you more secure

#282

Post by fastball »

ars wrote: post #73
antihero wrote: post #24

Earlier quoted context omitted.

This is why you have refresh tokens - your actual token expires regularly, but the client has a token that allows you to get a new one. Revoking is a case of not allowing them to get a new one.

You only have to do that if you must validate a token, without having access to session data. I doubt most systems are like that, you can just use what you call "your actual token" and check if the session is still valid. Adding a second token is rarely needed unless you have disconnected systems that can't see session data.

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.

Re: Frequent reauth doesn't make you more secure

#283

Post by lytedev »

sakesun wrote: post #262
free652 wrote: post #257

Earlier quoted context omitted.

Jesus, it was so annoying so I kept appending a letter after each password reset -> a through z thankfully my current company let me keep my password for the last 3 years

Password similarity rule was not enforced ?

Doesn't enforcing this require storing the password in cleartext somewhere, which is a much more dangerous concept to begin with?

Re: Frequent reauth doesn't make you more secure

#284

Post by pylotlight »

tharkun__ wrote: post #277
MrDrMcCoy wrote: post #267

Earlier quoted context omitted.

That's why we recommend passphrases. That 30 character requirement becomes much easier when it's 3-4 words with a separater. Faster to type, too.

Which does nothing for the "stupid people". I.e. the ones that we put these rules into place for. They'll do what I posted instead (or something else easily guessable and the cycle continues - technological solution to a people problem, i.e. doesn't work)

I would hate to be labeled 'stupid' everytime I don't want to type some 30 dumb characters everytime I login. How about no?

Re: Frequent reauth doesn't make you more secure

#285

Post by eru »

lurking_swe wrote: post #279
fsckboy wrote: post #272

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

For most people, writing (most of) their password on a piece of paper that they keep in their wallet would be pretty good security.

Paper can't be hacked, and writing down the password allows for more complicated passwords. In case someone gets access to your wallet, you still keep a portion of the password not written down.

(And if someone gets physical access to your stuff, you are hosed in general, because they can just install a keylogger. So even keeping your password fragment on a post-it under your keyboard would be fine-ish.)

Re: Frequent reauth doesn't make you more secure

#286

Post by ValleZ »

princevegeta89 wrote: post #36

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

It's because an average Apple engineer has to enter his password at least 10 times a day and it's kind of no big deal for them. Source: I was an Apple eng.

Re: Frequent reauth doesn't make you more secure

#287

Post by eru »

lytedev wrote: post #283
sakesun wrote: post #262

Earlier quoted context omitted.

Password similarity rule was not enforced ?

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 to the last password (or care about that one specifically), then that's even easier: during the password change procedure you can have clear text access to both the old and the new passwords without storing them anywhere unhashed: because the user has just entered both passwords.

Re: Frequent reauth doesn't make you more secure

#288

Post by eru »

xp84 wrote: post #214
throwaway843 wrote: post #203

Earlier quoted context omitted.

1234abcd@ it is then for all my accounts.

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…

There's one weird trick to get people to have strong passwords (even if you force rotation): don't allow them to pick their own passwords. Randomly generate the passwords for them.

Re: Frequent reauth doesn't make you more secure

#289

Post by repeekad »

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…

I’ve personally experienced the password change require that “more than X characters be different than the old password”

Re: Frequent reauth doesn't make you more secure

#290

Post by sakesun »

lytedev wrote: post #283
sakesun wrote: post #262

Earlier quoted context omitted.

Password similarity rule was not enforced ?

Doesn't enforcing this require storing the password in cleartext somewhere, which is a much more dangerous concept to begin with?

Interesting perspective. Wonder why so many SaaS service currently enforce this.
Post reply on HN