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

531–539 of 539 posts

Re: Frequent reauth doesn't make you more secure

#531

Post by zavec »

tiltowait wrote: post #333
lofties wrote: post #330

Earlier quoted context omitted.

I'm a big fan of "should not include profanity, words of a vulgar nature". It's not unthinkable my password manager comes up with a chain of letters that at one point will include "fuck".

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

Now I'm trying to remember where I read the story about somebody who was in a programming class and was writing some program that took user input, and figured that it should be smart enough not to repeat curse words. So they started writing down all the curse words it should know not to say, and that was about the extent of what they had done when the teacher came around to see how everything was going.

Re: Frequent reauth doesn't make you more secure

#532

Post by xp84 »

tharkun__ wrote: post #329
pylotlight wrote: post #284

Earlier quoted context omitted.

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

Different difference ;) I also don't want to type 30 chars, when 15 _properly randomly chosen_ characters would suffice but the "stupid people" chose those 15 characters as "passwordP@55w0rd" and now everyone requires us to write 30 instead because it's "so much more secure" when they write "passwordP@55w0rdpasswordP@55w0rd"

You're all missing the point.

There are different attack vectors. Yes, 15 random chars is sufficient if random, but recalling and typing 15 truly random characters is a big challenge for most everyone.

You shouldn't be having to remember and type your password for Hacker News, for Gmail, or your bank, ever, not even one time.

By making them 30 characters, you're ensuring one of two things:

A. Users at least use a passphrase such as "my dad liked to drink 6 packs of Miller Lite" which is brute-force-proof so, that's fine

B. Users who aren't masochists use a password manager properly and never have to even see their password let alone type it.

That's it, that's the whole endgame. By keeping passwords short enough to memorize and type, you're just enabling people to use P455w0rd. And if you think that only impacts stupid people, most people are stupid and many of them are in charge of keeping your data (and infrastructure, and government, etc) safe. You need them to be protected, to protect you.

Re: Frequent reauth doesn't make you more secure

#533

Post by tharkun__ »

xp84 wrote: post #532
tharkun__ wrote: post #329

Earlier quoted context omitted.

Different difference ;) I also don't want to type 30 chars, when 15 _properly randomly chosen_ characters would suffice but the "stupid people" chose those 15 characters as "passwordP@55w0rd" and now everyone requires us to write 30 instead because it's "so much more secure" when they write "passwordP@55w0rdpasswordP@55w0rd"

You're all missing the point. There are different attack vectors. Yes, 15 random chars is sufficient if random, but recalling and typing 15 truly random characters is a big challenge for most everyone. You shouldn't be having to remember and type your password for Hacker News, for Gmail, or your bank, ever, not even one time. By making them 30 characters, you're ensuring one of two things: A. Users at least use a pas…

I don't think that is correct at all.

Users are not "at least using a passphrase". They will do the simplest thing ever.

What happened when people used the password "123" and we added "Must have at least 8 chars"? They make it "password".

What happened when people used the password "password" and we added "Must have one upper case char"? They make it "Password" or "passworD".

What happened when people used the password "Password" and we added "Must have one number"? They make it "Password1".

What happened when people used the password "Password1" and we added "Must have one special char"? They make it "Password1!".

Guess what happened when people used the password "Password1!" and we added "Must be 30 chars long"? They make it "Password901234567890123456789!".

(or anything else stupidly easy based on whatever password they used to have anyway)

As in, you are missing the point I'm making. You cannot solve a people education problem by adding more and more "stringent" requirements. You need to educate them. You need to make them understand why it matters. Only then might they actually care enough to use a proper passphrase like you suggested.

In that sense I do agree with you that using a password manager is the best most people can do. I use one at work and it's a game changer. But I only use it, because it's provided by work and thus it's free for me. If they didn't provide it, guess what I would do too? If they have obnoxious rules, then I will thwart them any which way makes it easier for me. So my "change your password every 30 days and it can't be one of the last 8" password of course was my last password but it went up to 8 until I went to again.

Re: Frequent reauth doesn't make you more secure

#534

Post by RadiozRadioz »

fastball wrote: post #529
RadiozRadioz wrote: post #507

Earlier quoted context omitted.

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.

Dude, you can't have it both ways, pick one. You didn't want load on the DB, so you need to cache things somehow. Dealing with cache invalidation is a natural consequence.

Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all your requirements.

Re: Frequent reauth doesn't make you more secure

#535

Post by gausswho »

pfych wrote: post #224
gausswho wrote: post #170

Earlier quoted context omitted.

Do tell!

I set up Authentik[^1] on my NAS in a docker container and went from there! Just had to add a .well-known webfinger file to my domain that pointed to the Authentik instance and it "just worked" with Tailscale. [^1]: https://goauthentik.io/

Interesting, I'll have to try this. It's still not the anonymity I desire from my private VPN (due to domain requirements) but at least the giants can't rug pull you.

Re: Frequent reauth doesn't make you more secure

#536

Post by fastball »

RadiozRadioz wrote: post #534
fastball wrote: post #529

Earlier quoted context omitted.

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.

Dude, you can't have it both ways, pick one. You didn't want load on the DB, so you need to cache things somehow. Dealing with cache invalidation is a natural consequence. Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all yo…

I can have it both ways, that is the entire point of the refresh/access token system. The access tokens are used for 99% of requests (every request except "refresh" requests) and I am not persisting them anywhere – there is no cache/db read. It is a quick, CPU-bound check to decrypt the token, no i/o required.

Your newly proposed solution sounds much more complicated than the above.

Re: Frequent reauth doesn't make you more secure

#537

Post by jjav »

qualeed wrote: post #465
jjav wrote: post #149

Earlier quoted context omitted.

> the policy isn't a requirement for e.g. SOC2 or whatever It is a PCI requirement and probably from other sources. Of course it is brain dead and we even have authoritative documentation from NIST explaining why it is stupid, but nobody at PCI has any technical skills to understand that so the madness lives on.

> It is a PCI requirement The only requirement for password rotation in PCI DSS v4.0 is if the password is the only form of authentication (i.e. no MFA). Use MFA (which you should be anyways) and you don't need to enforce password rotation. > Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementa…

> The only requirement for password rotation in PCI DSS v4.0 is if the password is the only form of authentication (i.e. no MFA). Use MFA (which you should be anyways) and you don't need to enforce password rotation.

We just completed our PCI audit for the year and the auditor is adamant that this is the requirement.

Perhaps they're wrong, but fighting with the auditors is like wrestling with pigs, best avoided.

Re: Frequent reauth doesn't make you more secure

#538

Post by RadiozRadioz »

fastball wrote: post #536
RadiozRadioz wrote: post #534

Earlier quoted context omitted.

Dude, you can't have it both ways, pick one. You didn't want load on the DB, so you need to cache things somehow. Dealing with cache invalidation is a natural consequence. Ok then, keep the DB, provision a distributed array of read replicas, make them use synchronous replication to maintain your atomicity, force them all of them to keep the session table in memory. Now your cache is managed by the DB and meets all yo…

I can have it both ways, that is the entire point of the refresh/access token system. The access tokens are used for 99% of requests (every request except "refresh" requests) and I am not persisting them anywhere – there is no cache/db read. It is a quick, CPU-bound check to decrypt the token, no i/o required. Your newly proposed solution sounds much more complicated than the above.

Ah right, my apologies, I seem to have misunderstood here. For some reason I thought your initial comment was narrowly discussing the issue of DB load in a system that doesn't use refresh tokens.

Upon re-reading the thread context I have no idea why I thought that. Yes of course, refresh tokens are the best solution

Re: Frequent reauth doesn't make you more secure

#539

Post by Xevion »

crazygringo wrote: post #113
Xevion wrote: post #99

Earlier quoted context omitted.

Then why'd you pick a 50+ character password? No one made you do that. That's your fault, not Apple's. - As you said, it's a multi-platform account, so probably multiple devices in multiple locations will need the password. Meaning you won't have easy access to your password manager. - Popular account, so you'll likely be using it often, probably re-typing or pasting it. Common sense says that manually typing out a p…

> Switch to a phrase-based password. I assume that's why it's 50+ characters long , as opposed to 20 gibberish characters. Because phrase-based passwords are longer. And whether it's 40 or 50 or 50+ doesn't even matter, the point is it's not short like a 6-digit PIN. I have the exact same problem. It's still incredibly annoying to type on a touchscreen keyboard. If you mistype one character... So no, it's not the com…

Phrase-based passwords are far easier to type and remember than random gibberish at 20 characters. I would much rather type a 10x longer sentence than type random characters, even on mobile. It's far easier to validate a passphrase because we, as humans, will notice mispellings quite fast. It's only difficult if you're not english speaking, or have dyslexia - where I would refer you back to the original point: you don't need a 50 character password. Ever.
Post reply on HN