HN Reader

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:

> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)

https://pages.nist.gov/800-63-3/sp800-63b.html

Or by Microsoft

> Password expiration requirements do more harm than good...

https://learn.microsoft.com/en-us/microsoft-365/admin/misc/p...

But these don't seem to be authoritative enough for IT / security, (and there are still guidelines out there that do recommend the practice IIRC).

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 on my spouse's iPhone as well. Almost felt like Apple hasn't changed a bit after all these years. It keeps fucking prompting for password over and over, randomly when installing apps. although the phone is secured with a touch ID. This happens especially when you reset the phone and starting from scratch - it keeps prompting for the Apple password again and again.

The people who need to read these articles are the auditors. Until they change their expectations, the many businesses who have to pass audits are still going to be stuck doing a lot of things that are industry-standard but also very stupid. This is the case even for small businesses in certain fields where security audits are valued. We have at least half a dozen measures in place that we know aren't actually helpful but we also know auditors won't budge on right now.

Something related that's barely touched in the post:

Bad UX is potential security vulnerability. If your system behaves in unreasonable ways, users are much less likely to notice when it behaves in a slightly different unreasonable way, this time because of a spoofing/phishing, etc.

The obvious example: if your system frequently asks for passwords, re-entering passwords becomes a habit (read system one from "thinking fast and slow"), and the user is less likely to use judgement each time they enter the password.

But also, if an OS makes it hard to find all startup applications, allows untrusted code to run in the background without any visible signs, allows terminal code to access all local files by default, etc etc these all can be abused.

One problem is that human psychology is rarely considered as important a factor as it should be by the average security expert. The other is the usual suspect: incentives. The right chain of responsibilities is missing when things go wrong for people because of mistakes that would be avoidable by proper product design.

Regulation should enforce that, but while everyone would benefit from regulation, no one likes the regulation that will regulate the product/services they offer, and the supplier has upper hand when a change in regulation is being considered because they are focused and motivated.

Frequent reauth doesn't meaningfully improve your security posture (unless you have a very, very long expiry), but any auth system worth it's salt should have the capability to revoke a session, either via expiry or by user/device.

In practice, I find that the latency between when you want to revoke a session to when that session no longer has access to anything is more important than how often you force reauthentication. This gets particularly thorny depending on your auth scheme and how many moving parts you have in your architecture.

From the article:

    Now that most OSes can unlock with just a fingerprint or face,
    there's no reason to leave your screen unlocked when you walk away.

This statement seems to be unaware that workstations are a thing. In 30 years of onsite support, I think I've seen one desktop PC with a fingerprint scanner.

Cameras aren't ubiquitous either. Across the 5 locations I currently service, less than 2 percent of desktop PCs have a camera.

Past that, I believe there is a secondary challenge with face scanning; it's the unsettlement factor. I suggest that discomfort with face scanning is reasonable and earned.

The reason: We're constantly subject to face scanning that is non-consensual, intentionally hidden from us and is probably exploitative. Cams also enable snoopy bosses, school admins, corps, LEO and Govs to endlessly peer where they should not.

And even where we own our devices, we don't fully control them. Software corps have no ethical boundaries. Any assumptions that they'll respect us - at all - isn't based on reality or history.

For workstations, I like security keys.

Industry-wide IT security is driven by the "nobody got fired for buying IBM" phenomenon.

It doesn't matter if things are broken. It matters that you did everything by the book. And the book in this case was written 30 years ago and is woefully inadequate. But try convincing your VP of information security that employees shouldn't have to change their password every 3 months...

A client of mine has a 30 min timeout on basically all their systems. I hate using Jira as it is, but having to login pretty much every time I need to go look at my tickets just makes it awful. And then I end up on Hacker News instead of doing actual work.

The flip side of this is that I had a Ring doorbell in a home I lived in. Moved out and split up with my ex. Years later I installed a new Ring doorbell and I got a message from her shortly after installing it saying she was getting notifications again from my new Ring camera.

Kind of scary now to wonder if there's any loose accounts somewhere that's leaking sensitive information due to never requiring reauth.

I think the worse offender is iMessage. It's very easy to not understand that your SMS messages are -sometimes- going over icloud and can be seen on old apple devices you might have given up. I tried to unregister my phone number from iMessage about 5 times and it just doesn't work for me.

Remember when it was called SINGLE sign on? Emphasis on SINGLE? I mean, this whole idea has been such a mess forever. Why am I prompted to SSO hundreds of times a day?

Yahoo published these findings over 20 years ago , that frequent re-auth made customers less secure because it encouraged poor password hygiene like short passwords, writing them down, etc.

It's also risky to have the primary password credential transmitted instead of temporary tokens.

I just can't stand email OTP. Before we had passwords, now we have passwords + email OTP. And doesn't matter if you forgot password - you will receive password reset to the same email. You already prove email ownership by resetting or using password - why sending another useless "security token" to the same email. Pure nonsense. Whoever designs all of this clearly has little idea of what they are doing :(

user clicks a phishing link and is asked to login to M365 again, they do it without hesitation because they are used to doing this 5 times a day

logging into phishing links would make more people pause if they didnt have to login constantly to get work done

My employer just started doing daily reauth for all microsoft logins (teams, ...). The worst thing is that it's just 24h not start of day, so it may just be five seconds before you want to join a meeting.

They haven't found the setting for mobile yet, so I might just stop using desktop teams.

Corporate IT still makes you change your password every N months. Tell them to extend the max session length beyond a day and some VP will have an aneurysm.

This depends on your "world model", that is, what situations do you anticipate the people using your web site / application are in?

The assumption that basically, device = same person (browser session really) over a long period of time is the right one, 99% of the time.

Sometimes it's appropriate to make much more conservative assumptions. People might be in bad family situations (where not everyone with access to a shared device might be entirely trustworthy) or using a shared computer because they access things from a library, etc.

You can't help much (the computer might as well be compromised) but short session timeouts can make sense.

This is spot on. And it's a general misunderstanding of security in practice. Availability is often missed/ignored (but it is part of security) and attention is an important currency that needs to be treated carefully - or you and up with the mentioned MFA fatigue attacks or people writing down their passwords.

Very confused about this point:

> Passwords, Face ID, Touch ID — things that supposedly nobody but you can replicate, but which don't prove you're physically near a given device

Password, sure. But the other 2 surely prove that you're both 1) the correct person and 2) near the physical device that scans your face/fingerprint. The article immediately follows that by saying that face/touch ID do both.

Please just talk to my ssh agent and stop harassing me with authentication modals asking for tokens and fingerprints.

There’s another closely related one, changing passwords periodically.

A lot of infosec authorities move away from this.

However, I always wonder, does it make sense for an org to stop with periodic password resets if: 1. the org is not very capable in detecting all account compromises; 2. in practice, users leak their passwords (e.g. by getting phished) and not all of them lead to direct intrusions, some credentials are sold first and it may take weeks/months to cause an intrusion.

I believe that in practice, forced password changes at least ensure that unknown compromised passwords will become outdated at some point in time, and I think that this is positive.

Ultimately, I believe the best thing to do is to move to FIDO2-authentication here.

But I do wonder what are other peoples takes on this topic?

Finally someone said it. This is a relic from when a row in a database table for a session id cost about $400. I'm joking of course but that's what literally was on the mind of early internet engineers. The only company that fights this is Google and apparently tailscale.

The MFA is getting out of control too. Go to vendor's tool/website, which uses some SSO method and redirects/prompts me to login with the SSO provider. Authenticate to SSO providers, which requires an MFA. Redirects me back to the vendor's tool/website, which prompts for its own MFA. And the vendor's tool's configuration has a security setting that requires all accounts to have MFA, even if they are authenticated via other means.

I hate how prevalent it has become and it's getting even worse. One company that is buying our product has enforced SSO in theirs installation, making access_token lifetime of 15 seconds and refresh_token 4 minutes. For those unaware of OIDC/OAuth/SSO terminology, basically it means "if you lost access to internet for 4 minutes, invalidate your session, invalidate everything, make user go to auth, pick up 2fa, input everything...".

It causes incredible amount of stress in end users, who keep spamming us with tickets how our product logs out them every minute, like when they closed laptop for a minute, went from one building to another or when their VPN simply lost connection while they were on a lunch. It's like hundreds tickets per day when normally it's 3-4 per week.

And you can't really do anything about it, because "muh security standards", "we need to pass audit" and whatever.

I actually want to sit down and calculate how much working hours of everyone involved are wasted every single day, day after day, it's completely bonkers.

This has been bothering me for a while now (few years maybe ?) - websites repeatedly expiring my login for who knows what reason. Sure, maybe I can understand for high value trading platform or something. But no - most mundane sites which most people wouldn’t at all consider sensitive, like HomeDepot / BHPhotoVideo / various online shops, will expire my session within like 24h - seriously, wtf. And significantly more sensitive sites, eg Meta/FB, are usually able to keep my auth for months/years.

I haven’t chatted about it with anyone, as I partly wasn’t sure if something in my setup has changed and whether I’m a minority that fell into some constant reauth bucket. Or whether most of site owners have slowly been using lower and lower auth expiration, causing me a bunch of frustration and friction.

Anything that generates fatigue doesn't work. Passwords expiring every 2 months?? Users will user password like "test1" "test2" test3" and so on.

Companies don't even have a password manager so few employees use the browser to save passwords, others use their own password manager which comes with its own security risks like that service, LastPass IIRC, that got breached.

When working for big companies, there are so many wrong processes and practices which provides the bare minimal and that is fine.

Support team cannot care to report the problems coz they don't wanna more work, my laptop always connect to a restricted network while in the office which kills internet access to everything, that in turn cause the laptop to take 20-30 to turn own while it tries to run AD policies.

The whole process is broken within the companies culture, keep it minimal, repetitive and that "should work, next"!

I was working at a crypto exchange for years and completely burned out on reauth. VPN session would die, 20 different SaaS products would log me out, constant interruptions. I’m amazed I never got phished.

Microsoft has ruined their PC games with this. I hesitate to fire up Minecraft or Master Chief Collection these days because I just _know_ it is going to make me reauth for no apparent reason. I took 2FA off my Microsoft account because of this, so congrats.

These are a video games, not a bank account! Please just let me have fun!

OnShape (web based 3d editing software) is like this. They have a free tier with public-documents-only option, and it's same there.

Open the page... you have to log in, no way to remember you. Sure, you save your password in the browser, but unless you then also click into one of the input fields, the login button is disabled. Then you work on some 3d stuff, export the file, send it to the 3d printer, some time goes by, browser still open, you get the object, and the holes don't line up, you forgot the wall thickness in the measurements, calipers, yep, 3 more milimeters... open onshape tab, nope, you've been logged out. I didn't even close the goddamn window/tab, it's a free account editing a public document.

> Consider enforcing automatic screen lock when you walk away

The corpo "security" dingbats force this on our work machines via profiles -- can't control how long before the screen locks. Thank goodness for the Amphetamine app. I'm not typing in my password every time I stop to think for two minutes, you can fuck all the way off with that.

I hate the corporate office 365. How many times on the same corporate laptop on which I log in from home do I need to reenter outlook password and 2FA.

I seriously think ms365 login chain is straight broken Click here to sign in - enters userID and pass - thanks for logging out :o

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

Pretty rich coming from a company that only let's you create an account via SSO from the largest offenders of this.

IMHO there are only 2 requirements for a good password:

1. It must be close to impossible for a computer to guess.

2. It must be easy for a human to remember.

Virtually all password policies focus exclusively on point #1, with the vast majority just giving cargo cult instructions without really understanding the state of the art. Almost nobody puts any emphasis on point #2, which is arguably more important as it is the source of most breaches. If a person can't create a password, ignore it for a week, and then remember it immediately for the next login it's a bad password. This is where requirements like "no more than two characters from a character set (lower case, upper case, numbers, punctuation) in a row" are actively counterproductive. If the password has to be so convoluted that the user is forced to write it down then you've undermined your own security. Worse, it means the help desk will be forced to reset many many passwords which increases the chances of an impersonation attack succeeding.

I don't get why asking for a password multiple times is perceived as more secure. It's the same password. If an attacker was able to find it and input it once, surely they can do it multiple times too...

They've got the google mail here at work set to make me change the password once per month. The 100-character, unguessable, un-shoulder-surfable password that isn't reused anywhere. In addition to the 2fa I have to use with it. And it will now ask for reauth once per week, which just happens to somehow be 2 minutes before the important weekly meeting I'm supposed to attend which kicks me out of calendar for the link to the Google video meeting.

But at least it makes me reauth.

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

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 been really annoying.

I have really strong opinions against the device-secured biometric stuff. On my own devices, I will never use it as it dramatically lowers my security posture.

Further, the development of this ecosystem is to the exclusion of alternative OSes. Windows Hello and whatever apple wants to call their suite of biometric goo is elevating them to a place in my life that is unacceptable by virtue of the unwarranted trust granted to them.

Needless to say, this is an ad for Tailscale. I hate these short-lived sessions myself, but there are oftenreasons why they're there.

The alternatives proposed are "just always check right before a sensitive action" and "use continuous verification". Both of which are much harder to pull off correctly than short-lived authentication sessions (unless you buy their product, of course, supposedly), especially on third-party services you don't control the source or manage the deployment for.

Oh, and of course, "just make everyone lock their screens". If only it was that easy. If basic rules like that worked, we could ditch half the security measures we have for websites. What's next, "just use unique passwords of 20+ characters for each website"?

Also, this is putting a lot of trust in solutions like Windows Hello. I can't speak for the security of Apple's implementation, but thanks to bad vendor implementations (including Microsoft's own!), Windows Hello hardware is full of security holes. At some point one company decided to take a look at a few of those devices [and found security problems in all of them](https://blackwinghq.com/blog/posts/a-touch-of-pwn-part-i/).

Short token longevity also protects against one use risk Tailscale have a solution for: users logging in to their personal accounts on public computers. That's still an essential use case for people without internet access or computer access at home. Often these people are more vulnerable (homeless, very poor) so relying on them clicking the "log out" button on every website they're forced to interact with is not going to work.

Kerberos (or buying what Tailscale sells) does offer a somewhat nicer authentication flow, but that still doesn't work reliably on every browser on every OS on every device and it requires people to follow basic rules like "lock your screen", which is a massive risk. Passwords will always work anywhere and their security can be somewhat enforced.

I don't know, I still think it's a good idea to change passwords every so often. At the rate databases get leaked, you can't always rely on the strength of the hash and the time it used to take to crack given hardware getting faster and faster. Yes it can cause a minor inconvenience if locked out, but that's better than the alternative depending on what that system was.

But...worry not, we're about to embark on a world with a whole lot less security now thanks to AI and laziness.

Does that mean Tailcale will stop doing it? Currently they require you to log into every node and reauthenticate it every now and then, unless you disable key expiry.

Sure. All true. But PCI compliance requires 90-day password rotation which might not be required if you’re using multi-factor authentication (MFA). In other words, in the case of MFA, that requirement might be waived: and the operative word here is might.

So, if you’re pursuing PCI compliance people don’t rely on assumptions or conditional language like might. Certainty is key when dealing with compliance frameworks.

My problem is that there is a reauth FOMA that gets copied with the most trivial of applications. A good example is the Electrify America charging app. It's job is to be available so you can charge. But they log you out frequently - and they want to do second factor with email. Guess what - that doesn't always work. My wife was trying to charge the other day, was logged out, and couldn't get the email verification to go through. So I had her login with my credentials and I answered the email verification and gave her the token over the phone. super annoying.

But more importantly- mobile phones already have good security mechanisms. It's like all these shitty apps copied web based auth mechanisms with timeouts when they could do something better (and probably are built on web technologies with cookies instead of using the trusted store on the phone).

There are precious few apps out there that tell you ahead of time that reauth is happening (Zoom does this - kudos). But even so - I don't think it's necessary most of the time.

I'm trying to understand why my Rails application constantly logs me out in my iPhone/Chrome.

The same web app stays logged in forever in my mac and I access both of them with the same time intervals.

OWASP still recommends regular expiration: https://cheatsheetseries.owasp.org/cheatsheets/Session_Manag...

Only if you make a bunch of assumptions that may not apply. My employer allows BYO and has a default Outlook Web session timeout.

Is it ok that my son stopped at my desk at home and saw customer PII that was left open?

I enforce these kinds of policies at my company even though I find them personally stupid. I do so because I’m the custodian of my customers property and have a duty to minimize risk of employees or contractors acting poorly.

This reads like paraphrasing of SPIFFE. I’m down for it but I wonder of compromised devices that can figure it out how to keep the auth alive (or replicating user behavior). In those cases expiration still sounds like a good idea.

I very much agree with this article. But many companies are still under the idea of a complex password, instead of a long one. A "secure" password is not random character vomit. A secure password is a pass-phrase with multiple words and characters intermingled.

And then there is AWS which has 3 different products to log in and will sign out randomly and then redirect you to the wrong login page seemingly at random whilst in the middle of incident response

> What are we really checking?

That the security policy for the user and the resulting access key hasn't changed their level of access?

Identity, while the most common use case, is only half the system when federating logins.

My personal pet peeve is restrictions on what characters can go, have to go, into a password

Security theater, not really as it makes passwords less secure

Please repeat this to every moron involved in security theatre. This is turning into a pain in the ass in the industry for no reason

I just joined a fintech company. It is so crazy, everything logs out daily, to login you have to input a complex password plus the 2FA, you have to run everything through a Citrix VDI. Really bad.

Stealing session tokens is a common technique to get around MFA, deployed by malware everywhere.

I don't like it, but frequent reauth does limit the blast radius of stolen session tokens.

OMG I wish that someone would tell this to Apple.

Apple's developer services, such as App Store Connect, actually use session cookies. It's infuriating.

The previous company I worked for did this kind of frequent expiration, made for a good 2-3 days off every 3 months because I sure as hell wasn't going to set an alarm on the date.

Zero trust states that you don’t implicitly trust an entity even if they were previously authenticated. So is this a critique of zero trust? More productive might be to say that we shouldn’t blindly force reauth if our risk profile doesn’t warrant it - just like any security mechanism.

No, but it's a good excuse to require MS authenticator on my phone...

Google hasn't asked me to re-enter my password for years. If your users are the product this must make financial sense.

Here's 2 or 3 cents:

- Websites should (in agreement with TFA) just remain logged in (at least for 24 hours). Let the OS handle it.

- Public computers should only ever provide ephemeral login sessions. Everything cleared upon each login. Never persist anything to disk.

- Personal computers should reauth frequently, but should use adaptive authentication: i.e., password sometimes, and pin/fingerprint other times, where reasonable. Since "reasonable" is debatable, this should be configurable by the user at the OS level.

But it is easier to implement and maintain so it will continue to be the default.

recently came to appreciate the irony in proving who we are via catchpas, password complexity, and context switching 2FA is that any security method without personal irritation will get automated and broken. therefore, all security requires for us to prove the authenticity of our being by demonstrating suffering somehow- and an authentication method without evidence of suffering cannot prove we are real.

it's funny, but tracks infosec life pretty well, that we've stumbled into a proof that the necessary condition for a system to verify we are alive and are our authentic being is to offer up some minor suffering to it.

Funny because tailscale arbitrarily expires tokens on machines and doesn’t expose a way to see token age to the user (but does allow your IT admin to renew a token).

A minor recommendation: remove the word “just” from the following paragraph.

> At Tailscale, we believe in security that’s adaptive, intelligent, and actually useful — not —just- security theater.

Might be tangent, but Cursor has this the worst. Each time you close the browser and open, you're logged out. I have no idea why they do this.

Wouldn't frequent reauth be beneficial for stolen sessions?

E.g. If you set your session timeouts to a ~1 day then by the time your session cookies are up for sale on the dark web, they will be expired.

The article doesn't mention this and it's the main reason I advocate for auth sessions that are as short as practical.

Okta / Lumos are the biggest offenders of this.

They dodged what to do about SSO and SAML. With SAML I don't necessarily know (as a coder) who will be the IdP or what protocol there will be for up to date authorisation info.

This kind of goes along with my ongoing pet peeve about DX in general. There are very few organizations I’ve worked with that actually care and put their devs first. Case in point, I worked on a contract a few years ago with very frequent reauths where you had to enter your PIV card PIN about every 30 min. Obviously something was not configured correctly, but when we complained we were told that that was their security policy and to go pound sand. It made everyone so frustrated that productivity took a huge nosedive. I remember one day I was in the middle of trying to analyze something very tedious and having anxiety about the next time that dialog would prompt me for my PIN. Sure enough it happened, and I just gave up. I left my laptop, took a walk, and did nothing for the rest of the day. Eventually someone important petitioned for us and it was fixed, but I can’t begin to calculate how much money this wasted in terms of unproductive contract hours.

That's okay, soon we'll have 8 hour ssl certs to go with this crap.

Zoom has been driving me nuts with this lately. I have to reauth with OTP 3 times a day, while logging in on the same computer on the same LAN with the same browser. I spend over $1500 a year with Zoom, and this issue is seriously making me think about how I can migrate to something else.

I disagree with the general advise behind this, even when I'm in a household with trusted (most of the time) family members. Forcing a re-auth ensures that even if I forget to lock my machine/browser, someone can't snoop around. I want this to be the norm especially for my Macbook since for whatever reason, I might forget to lock or have some program running that'll force the laptop to not auto lock out (e.g. while downloading something that takes a long time) so I don't want someone to be able to seize that opportunity.

It's the same reason I intentionally lock up apps with TouchID when there's remotely anything sensitive in there. I just don't want someone to be able to snoop if I forget to lock my phone.

I'll say however, there should be easier ways to reauth in such scenarios. Like in my case, TouchID is not very disruptive to my work even if a prompt appears. I'll also say it's probably stupid to lock out when there's continuous activity (should lock based on inactivity period).

The worst offenders in my experience are banking apps. They:

  - Force logout sometimes regardless of ongoing activity
  - Log out as soon as I close the tab
  - Log out when I press the back/reload button
  - After logging out, impose a mandatory inactivity period before I can login again (this is just the most idiotic thing EVER)
  - Use JS to block any kind of copy/paste operation on username/password fields
  - Never integrate with modern auth mechanisms, not even app-based TOTP!
  - Have crazy password expiry windows (like every quarter) and force password change when your previous password expires, regardless of how strong they are

Looking at you Beatport!

lol tell that to the people that want 15 day length TLS Certs.

I litigated the "sign back into SSO and every downstream login every four hours" with my IT team. They held their ground. So much money is being lit on fire with the time wasted.

Heroku's 25 hours comes to mind... this is so infuriating and annoying.

I'm so tired of the enforced password changes, that I just write them on a post-it note now.

A curious thing with security is that a lot of measures companies take aren't about your security but about liability and control. Most security theater is motivated by that. Your inconvenience is collateral damage to that. Apple and Google don't worry about you getting hacked but about you suing them after you get hacked. That's the risk they are mitigating. Or worse, you jumping ship to the competitor. They want you dependent on your account with them.

So, when Google single signs you out mid meeting (has happened to me), they don't care about how stupidly annoying that is. That's just them asserting that if anything bad happens to you, it was your own fault and not their failing.

And then a secondary thing that makes life even harder is that instead of working together they are considering single sign on mechanisms as control points that they can leverage to keep the relationship with 'their' users exclusive. So Google and MS both do very similar things but they don't trust each other's Identity Providers (IDP). That's not an accident. That's intentional. MS has been on a decades long mission to 'own' all logins, and of course they've been failing to get there just as long. Likewise, Google and Meta have been fighting over this as well. And the net result is that you don't have just 1 account to worry about but gazillions. That's why every silly little app has its own stupid email/password thing and why onboarding friction is the biggest hurdle to users adopting these.

These are the primary motives driving this mess. Companies don't collaborate, so security stays complex and messy. It's also the reason that passwords (long discredited as a reliable way to authenticate) are still a thing. If we had effective federated IDPs like OpenID where everybody could use and IDP of their choice and use it to authenticate it with pretty much everything and the kitchen sink, you wouldn't be using passwords ever. That was envisioned as early as 20 years ago. Google, MS, Meta, etc. blocked every attempt to make that happen by never mutually trusting each other, or any other IDP not operated by them. They all implement some version of OpenID 2.0 (with enough differences to make supporting all of them a bit of a journey) but they deliberately don't whitelist any external IDPs and jealously continue to fragment the security landscape by guarding their walled gardens.

They've been engaging with each other in backroom standardization attempts ensuring that the status quo is never allowed to change for decades. The latest move in this war: pass keys. Nice solution on paper. But you got to have the Google version of it. And the MS version. And all the rest. Sigh. Because, obviously, by design these will never delegate to each other. They trust each other even less than they trust you.