Frequent reauth doesn't make you more secure

> Turns out, this rule was not from IT. It was a requirement from the cybersecurity insurance policy the organization had taken.

I wonder if some of these constraints are to try to find a way not to pay out on the policy.

It's not money but inertia of very large systems. All these password changes cost money as well. If anything it's a market failure that insurance companies seem to have too little incentive to update their security requirements. This would likely be solved by reducing friction with both evaluating insurers in detail and switching between them.

Not money; incentives

There are policies to prevent changing the password more than once a day to prevent that. I've encountered it in several places

Password changed.

Password changed.

Password changed.

Error at : broken pipe

Um, that's a really bad sign...

Whenever I don't have to type it, that's what I do. It's the login (or password manager password) needing this counterproductive crap that gets the "append a date" treatment. It's a 10-word diceware passphrase, only used for that login anyway, it's not getting breached if it's stored in even a remotely secure manner (even an unsalted hash would be safe).

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.

They do it because their IT departments are checklist monkeys with no actual brainpower there, AND/OR they have cybersecurity insurers that mandate it who also have nobody with actual brainpower working there.

Or just if they changed to a more secure hash algorithm themselves and want to upgrade users still on the older insecure one.

Your broker/bank still needs to do it, unfortunately... someone please fix this :(

[0] https://www.finra.org/filing-reporting/entitlement/password-...

"Trust this device" is the modern day elevator door close button.

I agree with you, but it's the same reason why Microsoft asks you to type a numeric code generated by their Outlook app in order to login. It's to prevent people from dismissing the alert by clicking "OK" without even reading (especially if they're in the middle of something else, e.g. during a scam phone call).

To prevent an attack where someone steals your username and password, triggers the 2-factor notification, and waits for you to accept it. This can be automated and repeated until you eventually click the wrong button for one reason or another.

By requesting a short-lived code, attackers now need to communicate with you at the same time of the attack and somehow convince you to give them that code. Much harder.

It does also increase friction for non-first party applications and Apple has a strong history of using product design to discourage non-first party apps.

I wonder how many millions of productivity hours have been lost due to millions of people having to click through these stupid, useless prompts countless times per day.

That is the single most useless dialog/question in IT. I wonder how much money that costs the global economy a year.

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.

You’re right except in the very specific case of the App Store purchase or download process. You only get one chance at FaceID and then it demands a password. But, if you cancel and do it again, you get another chance at FaceID. It’s mystifying why they’d make that UX choice.

Are you using a single Apple Account for both the primary account on device (iCloud, etc) and for iTunes? That is the other scenario where I see people hitting this.

Hmm, might be worth reporting if you haven't already. I just tried installing something with IAPs, which usually triggers the prompt. I had the option to use FaceID on my phone. I tried the same on macOS and I had the prompt to use TouchID. I'm on Tahoe beta right now but it worked the same even while on Sequoia. It's once in a blue moon I see the password prompt, not sure exactly what causes it to appear.

"The best minds of my generation are thinking about how to make people click ads."

-Jeff Hammerbacher

I feel like advertising relies on getting it right "enough" not for everyone and ... they don't care.

Auth and settings people will tell you when it is wrong and that is generally thought of as a problem. Yet advertising doesn't care.

For years Amazon kept showing me women's products. I never once bought any or looked them up but man they were sure I wanted to buy some.

Google thought I was a Nebraska Cornhuskers fan but really I'm a fan of a rival, that's why I had to google a few things about them, but my old google news feed was sure I was a fan... even when they gave me a chance to say "no news about this team" they kept doing it ...

I hate how in macOS, I can double click a window's title bar to maximize it, and five minutes later the original window size will be forgotten so you can't restore it.

Windows 95 had this shit figured out on systems running a 486 and 6MB of RAM.

That stops the computer asking, but it doesn't stop the phone asking.

Apple changed this a few years ago, because of a potential security venerability: https://imazing.com/blog/ios-backup-passcode-prompt

Yeah, but passphrases don’t require switching keyboards as often in mobile. And if you’re using a 16 character P@s5w0R6, a 50 character passphrase can be just as secure.

What I can’t stand if when I’m prompted to type a password on my Apple TV and can’t use my phone for some reason. Scrolling across the alphabet for a passphrase is torture.

Remember how 1Password used to install itself as a custom keyboard that could "type" your passwords into arbitrary text fields anywhere in the OS, before password management specific hooks were added?

It would be nifty if your phone could just connect to other devices as a BT keyboard and type in passwords there too. Probably not worth the actual fuss of pairing a BT device, but if that part were not so painful it could be quite a nice solution.

> 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 commenter's fault. And it's certainly not mine. I'm doing the best with the tools I have available. It's Apple's fault, mainly.

If only everyone involved with security compliance could learn the lesson that John learned in The Phoenix Project, developers and ops folks would experience a lot less pressure to treat the pantry like Fort Knox. There is not only evidence that goes against the expectations of many auditors, but there's also no requirement that compliance of everything be implemented through costly software and network changes, because physical security and process can be used for compliance as well.

> because it is security theatre, something they can point to if anything goes wrong.

Yeah, there is space between "this is a good practice and it's nice to be able to check the box" and "this is a standard someone else dictated but it will cover my butt if anything happens" unfortunately.

I get it, I depend on standards all the time (food safety, equipment certification) so I understand the desire, but darn it's frustrating when they are viewed as a cure-all.

Customers need to ask for these changes, which is why this is hard to solve. At least in my field, many of the measures we end up having to fall in line with are the result of our customers deciding that those who bid on their contracts must have these certain credentials. If those same customers had more competent decision-makers determining technical qualifications then this would be less of an issue. Unfortunately, that also means that we will be stuck with these audits in their current form until the vast majority of our customers first decide they’re not needed.

Stop paying them, I guess, and find a different audit firm that's more knowledgeable. Just like anything else—you get the level of competence you pay for. (Although I guess there's probably a "sweet spot" at which you can pay less AND get better first-level auditors if you're not looking at the biggest firms that are going to charge the most money and also have the most churn)

In a free market, you don't - you start your own company that doesn't waste half of everyone's time on security, and do stuff twice as efficiently, for half the price and outcompete the other one.

Then you get outcompeted by a company with no security at all, which is twice as efficient as you until they get hacked.

It is, but its an architectural decision that forces expiry by default. So you should probably even have both. AWS runs 12 hour session tokens, but you can still revoke those to address a compromise in that 12 hour gap. The nice thing that forced expiry does is you just get token revocation For Free by virtue of not allowing renewal

Having a short session expiry is a workaround for not being able to revoke a token in real time. This is really the fault of stateless auth protocols (like OAuth) which do offline authentication by design. This allows authentication to scale in federated identity contexts.

Yeah but depending on how you set it up, you could have a very short expiry. If your auth system is as simple as: Verify refresh token -> Check a fast datastore to see if revoked -> Generate new auth token, this is very easy to scale and and you could have millions of users refreshing with high regularity (<10s) at low cost, without impacting on your actual services (who can verify the auth token offline).

Say you had 1,000,000 users, and they checked every ten seconds, that's 100,000 requests per-second. If you have 1,000,000 users and can't afford to run a redis/api that can handle an O(1) lookup with decode/sign that can handle that level of traffic, you have operational issues ;)

It's all a tradeoff. Yes, it means some user may have a valid token for ten more seconds than they should, but this should be factored into how you manage risk and trust in your org.

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.

If you've built a local app that has to authenticate you against a remote web service even when offline, and all the actual work is being done locally, you have much bigger design issues than authn IMHO

Access tokens are used for network calls so if the network is down nothing works anyway ?

That sounds like a horrible setup though and is a good way to MFA fatigue and other security issues.

In our case - I counted this morning too - I have 2 MFA authentications (VPN and the IDP used by Keycloak) until I have my Keycloak session. This session has an idle timeout of I think 2 hours, so if I don't do anything for 2 hours I'd have to re-auth. And it has a max session length of 10 or 11 hours so it lasts even for long workdays. This has been setup so users generally have to login via MFA once a day in the morning. Since we're using the same authentication and setup, we know this works.

Further token refreshes and logins then bounce off of that session. So our Jenkins just bounces us over to Keycloak, we have a session there, it redirects us right back. Other systems similarly drop you to the Keycloak on first call of the day and Keycloak just sends you back. It's very nice and seamless and dare I say, comfortable to use.

It is however supposed to be easy and we spent some time getting it working this well.. because now people just integrate with the central auth because it's quick and easy and we have full control and tracking of all access :)

Whether or not you can be compelled to unlock your phone doesn't really have anything to do with passkeys. If you can be compelled to unlock your phone, then whatever you have on your phone (including the stuff in your password manager/credential manager) is potentially up for grabs. In this threat modeling scenario there's nothing unique about a passkey vs. a password.

And if you're against using credential managers at all, because you only want to have the password stored in your brain and nowhere else.... then that creates different problems, namely it dramatically increases the odds that you will use the same password across multiple services, which is bad because then attackers can steal your password from one service and use it to login to a bunch of other services.

> The police department getting a court order and forcing you to unlock your phone

If you live under a tyrannical regime, neither passkeys nor passwords will help you. The police state will find a way to do what they want with you.

> Of course, that only really works that well in an homogeneous environment

It works if no monopoly abuses their position by sabotaging the standard.

OAuth is getting a chance to work because neither Google, Apple nor Facebook are big enough, and they don't play well with each other. At least right now.

And on top of that, the session is probably gonna expire in less than day. I hate logging in to Anthropic because of this signin-email dance

Nothing tempts me so strongly to give up and leave a site than needing to use a magic link to get in.

Sometimes it takes minutes. I have, on more than one occasion, given up on buying a product because of this. It's actually insane to me how much effort sites put into preventing users from using them.

I get it, most people are idiots with completely non-existent security hygiene, but man does it suck being punished because of just how low the common denominator is here.

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

My point is that on sites that force email 2FA you have to do the email dance anyway. A username and password are basically theater.

Note that by doing it that way they don't have to have a special case for handling input of username/password when that password is a new password. Making security critical code simpler is generally a good idea.

Whether it is worth annoying some users in the password reset case to avoid making the login code slightly more complicated is going to depend on your specific situation.

> Signal app periodically prompts you for the encryption PIN to make sure you don't forget it.

At least Signal does not block the app until you enter the PIN. WhatsApp forces you to enter it before you can reach your messages, which not only is annoying when you're in a hurry, but also forces you to type the PIN even when you're in a place where it might be seen by someone else.

On the other hand, on Signal it's possible to leave the warning forever at the bottom of the screen without acknowledging it and typing the PIN, which kind of defeats its purpose.