Live data from Hacker News

Frequent reauth doesn't make you more secure

tailscale.com

341–350 of 539 posts

Re: Frequent reauth doesn't make you more secure

#341

Earlier quoted context omitted.

I despise this. With username and password my password manager just fills it in and it is one click to click "login". With email magic link I need to enter my email (it seems to rarely auto-fill for some reason), then wait (often it takes 10s for the email to be sent for some reason), then if I was logging in on something that isn't my default browser I need to copy+paste the link (often just clicking the link author…

My preferred workflow as well, but now many websites are starting to do this thing where you have to enter only your username, hit next, and then the password input shows up; however, the username only input breaks my password manager from trying to autofill! Argh

Google has been doing this for years, if not over a decade at this point. Password managers have gotten wise about it though, so for some websites it actually works.

Re: Frequent reauth doesn't make you more secure

#342
Google Workspace defaults to making you sign in every 2 weeks unless you have a certain upper tier of paid account with them.

Even worse is that if you try to search for the feature and click on it, it presents a page that unhelpfully returns 404.

It's annoying AF.

"By default, the web session length for Google services is 14 days." https://support.google.com/a/answer/7576830?hl=en

Re: Frequent reauth doesn't make you more secure

#343
post #237
post #222

Earlier quoted context omitted.

I’m doubtful a 30 digit minimum password is a meaningful improvement over a 20 digit password here. Meanwhile actually typing in very long passwords adds up across a workday/year especially with mistakes.

I think if done right, typing that password should be more like a once a quarter exception rather than a daily occurrence. Granted - there are blockers to getting there. IDK why for example, macOS can't use Touch ID from a cold boot, that's stupid, at least when there haven't been too many failed attempts or anything.

> macOS can't use Touch ID from a cold boot

Isn't that because the Secure Enclave (the only place which contains the Touch ID biometric data) is locked by your password?

"When a user's password is set up on an Apple Silicon Mac, the password is passed through a one-way hashing algorithm that produces a key used to encrypt the Secure enclave's key."[0]

[0] https://blog.greggant.com/posts/2023/04/14/the-security-encl...

Re: Frequent reauth doesn't make you more secure

#344
post #327

Earlier quoted context omitted.

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.

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?

Re: Frequent reauth doesn't make you more secure

#345

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

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

Re: Frequent reauth doesn't make you more secure

#346
post #308
post #307

Earlier quoted context omitted.

Is there any way to check that with non-plain-text password?

Actually it can be trivial as long as you can require the user to re-type the current password when entering a new password; check hash first, then check edit distance with the entered "current password" (and, of course, promptly throw it away once you know the edit distance.)

Ohh. I guess that's what Windows does when a user wants to change their own password in the domain.

Re: Frequent reauth doesn't make you more secure

#347
post #154

Earlier quoted context omitted.

Disable anti-tracking features and ad blocks, it turns out cookies and temp storage for ad tracking are how IDPs track your choice to trust the device too.

Adblocking and anti-tracking are mandatory on my company laptop, cannot switch those off. And I wouldn't want to.

This is actually one great use for an MDM policy.

Re: Frequent reauth doesn't make you more secure

#348

Earlier quoted context omitted.

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

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.

Re: Frequent reauth doesn't make you more secure

#349
Humans shouldn't generate passwords. ~0 people are good at that. Websites should just generate a password for a user, letting them regenerate as many times as they like until they get one they like (without breaking password manager based generation). A bit like this: https://peergos-demo.net/?signup=true

Re: Frequent reauth doesn't make you more secure

#350
post #37

Earlier quoted context omitted.

No modern IT organization mandates periodical password changes since, I dunno, mid-2000's. edit : please note the "modern" qualifier, tons of IT orgs continue to mandate this anachronistic policy, sure, but those orgs aren't modern, the policy isn't a requirement for e.g. SOC2 or whatever, it's purely historical inertia.

Even worse. NIS2 in the European Union makes password changes legally required for many organisations. https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=PI_... 11.6.2 (c)

Yikes, whoever wrote that should be ashamed of themselves. On the bright side, it doesn't specify how long the predefined interval should be, and says entities are to 'ensure the strength of authentication is appropriate to the classification of the asset to be accessed' - so, in order to ensure the appropriate strenght the interval should be 100 years is totally defensible IMHO. The whole paragraph doesn't take MFA in account anyway, and FIDO2 does provide for key rotation (even if it's not widely implemented, maybe something to consider if you're covered by NIS2 - or manually rotate keys once every year).
Post reply on HN