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

501–510 of 539 posts

Re: Frequent reauth doesn't make you more secure

#501

Post by andrewaylett »

jandrese wrote: post #480
Rexxar wrote: post #478

Earlier quoted context omitted.

Something like that could probably be implemented by storing multiple hash of some automatically modified version of the password. For example, if your password is "PassWorD" they can additionally store the hash of the lowercase version of the password. So if you change it from "PassWorD" to "paSswOrd", they will see it has the same lowercase hash than the previous one without knowing it.

This doesn't seem practical at all. The combinatoral explosion would make the storage requirements impractical for everything but the absolutely most trivial cases like incrementing a number as the very last digit. Even in your simple example you're talking about storing 256 different hashes just to catch one possible mutation on a way too short password.

You can store a normalised form -- so if the password is `PaSsWoRd` and the user tries to change it to `pA55wOrD`, a normalisation that lower-cases, turns 1 and i into l, turns 2 and 5 into s, and turns 4 into a, would normalise both to `password`.

Or if you want a slightly more convoluted mechanism, when someone changes their password you have both in plain-text and you can take a copy of the old password at that point -- after all, it's not being used as a password any more! For bonus fun, submit all previous passwords to pwned passwords. Password reuse makes this a bad idea in general, specific policies attempting to mandate it will not be an issue notwithstanding.

Re: Frequent reauth doesn't make you more secure

#502

Post by andrewaylett »

lofties wrote: post #330
Mtinie wrote: post #273

Earlier quoted context omitted.

> If the password length is 12 to 15 characters, it will be valid for 180 days > If the password length is 16 to 32 characters, it will be valid for 365 days Madness.

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

Word list based passphrases mostly avoid this, by not including those words. Which still doesn't mean you won't get something offensive, of course, it'll just be a string of four words instead of four letters.

Re: Frequent reauth doesn't make you more secure

#503

Post by radicality »

jesseendahl wrote: post #485
radicality wrote: post #458

Earlier quoted context omitted.

HomeDepot’s is even crazier. You input just your email and hit Next. Then a button appears to “Send magic link” to login via that annoying method. And then there is a tiny text below: “Want to use a different login method? Wait 10s…9s…8s…”. Only after 10s are you able to select a tiny text link “Use Password” to unlock using the password field

FYI Home Depot supports passkeys which are a significantly better* sign-in user experience than magic links. *faster + easier (fewer steps)

Oh nice, thanks, just set this up! Though seems like I needed to do enable it separately for the web version and iOS app.

Re: Frequent reauth doesn't make you more secure

#504

Post by makeitdouble »

carlosjobim wrote: post #151
makeitdouble wrote: post #142

Earlier quoted context omitted.

People are _required_ to have complicated passwords in most services. Yet they'll still make you type it out in so many situations, including on account creation confirmation where some service will even block copy/paste to push you to type it. Services will accept losing an user over password grating issues ("no compromise on security"), so it just gets worse and worse.

It's much more practical for me as a user to use biometric identification to fill in passwords. That means I can have different auto generated passwords for each service, that are impossible to crack. And if one gets leaked, then that's the only password that gets cracked. The security benefits are enormous, and the ease-of-use benefits are enormous. I haven't seen any service block paste when filling in or making a…

> Not good business.

As you guessed, most of those aren't businesses and we need them more than they need us.

Re: Frequent reauth doesn't make you more secure

#505

Post by mazone »

yardstick wrote: post #491
mazone wrote: post #398

Earlier quoted context omitted.

PCI DSS from 4.0 actually have something called customized approach for everything. If you can prove and the QSA agrees that you fullfill the goal of a requirement, you can be quite flexible. Example i am doing things like not using passwords at all and only passkeys, or only ssh keys protected by hardware security key etc. Together with agents trying to verify the devices connected are company owned and hardened in…

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 dont have those problems but with passkeys, many times you cannot decide on what device a user have registrated the passkeys in a enterprise setting. example they could be apple passkeys, chrome passkeys, windows, hardware key(yubikey) etc and all of them behave different when it comes how they ex can be copied/ synced between users devices. So from where they can be used.

So for any authentication flow, you need to look at the full picture. What is the process when credentials are lost? How do user onboard etc.

Is a good entry point to say. We should use MFA or similar but the details matter.

Re: Frequent reauth doesn't make you more secure

#506

Post by notpushkin »

mrspuratic wrote: post #373
notpushkin wrote: post #344

Earlier quoted context omitted.

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

Yes, via PAM, and this works fine with OpenSSH. But the couple of OTP implementations I've used are the same, you can either provide password and PIN or passwordPIN. In the end they get concatenated, passed to the next layer, and taken apart for checks. This lets it work with brain-dead http basic auth too, if you're unlucky enough to have to use that...

Yeah, I’ve seen it in a couple places, too. (Once I’ve had to write my own wrapper for openfortivpn that did exactly that!)

Re: Frequent reauth doesn't make you more secure

#507

Post by RadiozRadioz »

fastball wrote: post #282
ars wrote: post #73

Earlier quoted context omitted.

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.

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.

Re: Frequent reauth doesn't make you more secure

#508

Post by 1oooqooq »

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…

this is only because of all the lawsuits about apple store chargebacks because they allowed kids to make purchases.

article is shot Enterprise software and you're talking about games and predatory dark patterns in consumer devices. or do you company distribute software to employees via app store?

Re: Frequent reauth doesn't make you more secure

#509

Post by strken »

jandrese wrote: post #480
Rexxar wrote: post #478

Earlier quoted context omitted.

Something like that could probably be implemented by storing multiple hash of some automatically modified version of the password. For example, if your password is "PassWorD" they can additionally store the hash of the lowercase version of the password. So if you change it from "PassWorD" to "paSswOrd", they will see it has the same lowercase hash than the previous one without knowing it.

This doesn't seem practical at all. The combinatoral explosion would make the storage requirements impractical for everything but the absolutely most trivial cases like incrementing a number as the very last digit. Even in your simple example you're talking about storing 256 different hashes just to catch one possible mutation on a way too short password.

You could use a Bloom filter, and just gaslight your users when a false positive happens.

Re: Frequent reauth doesn't make you more secure

#510

Post by yencabulator »

notpushkin wrote: post #345
tiltowait wrote: post #333

Earlier quoted context omitted.

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

It would be fun to make a passphrase generator that always includes a profanity.

Dibs for calling it misenthropy. Entropy mixed with misantrophy.
Post reply on HN