Because the alternative is that a very long or unlimited session cookie can be stolen and used for months to impersonate you. That’s the tradeoff

I'll take that risk, especially since I've basically never heard of a successful attack hinging on a stolen session cookie being used for months. Either you do what you'll do within a few minutes, or you never do.

That's a great way for someone to siphon a lot of session tokens and then auction them off to a black hat.

It's also a great way to lose everything if you happen to lose your phone or laptop and it gets found a few hours or a day later and the antagonistic finder guesses your weak PIN.

In the US, service providers and manufacturers are often held liable for losses if they make something that has sub-standard security. Kia, for example, was held liable for making their cars too easy to steal. Banks have boatloads of things they have to do to protect their customers.

It's not really your choice to take the risk here, apparently.

When was the last time that happened to a Gmail account? It has unlimited cookie sessions.

I actually did this for my small saas Ive sold to a couple dozen companies, and while all my programming friends at the coworking office said I was crazy, Gmail and facebook were my go to answers. If they can do it safely, I might as well try.

Username checks out!

Yes, they made the account to post that comment. Might as well make the username relevant.

Ugh. Account created 1 day ago. My mistake. I do apologize for wasting everyone's time and thank you for pointing it out.

Maybe Gmail, but definitely not GCP. I have to re-auth every day or two for that.

And even with Gmail there's a decent chance it isn't just "blindly trust unlimited-duration token". Cookie stealing is now one of the main forms of credential compromise, so I bet there's some form of browser and/or IP verification going on to demand a reauth when some `curl` instance from a Russian VM tries to make use of it...

Then connect the browser directly to the secure element of the device, so the session cookie is cryptographically signed by something you are physically in possession of.

Logging and alerting the user that their account is being used from a new context and requiring reauthentication when accessing the account from an unfamiliar IP/user agent would mitigate this to some extent.

The alternative is offering offline versions of apps to students and allow students to open downloaded items off the cloud locally. It also means students don't require internet access when off campus.

TPMs / secure enclaves can (in theory) prevent sessions or cookies from being stolen. Not claiming there aren't other attack vectors though.

Are those used in practice, though? I'm not aware of any "sign request headers with private key cookie stored in TPM" HTTP extension, but I would love to be proven wrong.

Of course, in practice that would just turn cookie-stealer malware into request-proxying malware.

It's also crazy that as far as technology has advanced, the concept of the username/password is still so prevalent. Passkeys are sort of changing things, it all still feels decidedly low-tech.

What is really crazy is that things that should be just an application locally installed on the device (such as PowerPoint) need a login at all.

There's a secondary issue of schools pushing children to use proprietary applications when perfectly serviceable alternatives exist (especially for school level work).

How the hell we all normalized this crap is maddening.

It's not even new. 20 years ago I got a bad grade in highschool because I used StarOffice and not Office 2003 for a project

My father and I had an unreasonably long conversation with the dean of students about how requiring someone to purchase a $300 software suite for a basic highschool English class was egregious

The school in the linked post actually requires 3 separate logins before you can see the presentation, that’s just…

One of the "best" parts being the first one of those was meant to be an "SSO" but apparently is design-by-committee and very bad at it. (Requiring too frequent logins, not saving usernames between logins [for kids?!], requiring login dances at downstream logins.)

> that’s just…

I think they call it UX.

Username/password is the easiest way to log in, assuming there is no stupid format requirements. It's just two strings stored in your password manager. The most retarded way to implement log in is actually magic email link, which requires opening your email client, waiting for the email to arrive, and copying the code. If you want to make it even worse, you can require that to be done using the same browser that is trying to log into the account.

[delayed]

Is it a slur if it's describing a process, rather than a person?

Yes.

There are still plenty of technical and scientific uses of the word in various forms, including retard, retarded, retardant, and retardation. One that’s in common use outside the sciences is “flame retardant”.

Technical usage, where the word is describing a quantity, process, or function include: retarded time, retarded position, retardation time, regarded coordinates, retarded Green’s function, retarded potential, retarded acceleration, and retarded ignition.

In all these cases, it’s used to refer to something whose progress is delayed or impeded in some way, which is the original meaning of the word “retard”, that also ended up being used in medicine and psychology and becoming a slur in those contexts.

So the correct answer to my original question is either “no” or “it depends”, with the latter requiring some qualifying criteria.

[delayed]

The correct answer is that the manner in which you used the word in the context above was as a slur. As you're no doubt well aware.

Full stop.

> the concept of the username/password is still so prevalent

How can you improve on it? You have the identity part and the auth part. What is better than that?

Passkeys. That has both and it can’t be set insecurely, written on paper or given to an Indian call centre who assures you they are from the finance department.

How do you identify whose passkey it is without an identity? They're a decent defensive auth method for people who can't use a password manager but they can't replace username/password.

username/passkey works just fine. No password needed. Nobody said drop usernames, the idea is drop passwords.

> the idea is drop passwords

and replace them with passwords (passkeys). Very clever.

Passkeys as they are currently-marketed are resident credentials. This means a passkey stored on your Yubikey (or smartphone, or Windows account, or...) is not only a private key, but also contains a UID to identify it. A website doing authentication can trivially use this to look up which user it is associated with. Very convenient for single-press login, but it requires a decent bunch of per-website storage on the hardware token. Which is of course a net positive for the big tech companies, because it forced you into using smartphones as the token, and doing silly things like cloud sync with them.

The original FIDO U2F credentials were not resident. You'd enter your username, and the website would sent over a bunch of opaque blobs representing the associated hardware tokens. The hardware token would decrypt their blob using a key derived from a combination of the website's domain name and the hardware token's single stored secret, and then do the whole auth shenanigans using the data retrieved from the blob.

Making it phishing-resistant, for starters. And having a built-in way to prevent people from reusing their password across multiple websites, so that any single compromise doesn't instantly turns into having all of their accounts pwned.

> And having a built-in way to prevent people from reusing their password across multiple websites

"Sign in with Google/Facebook/etc" - epic fail. /s

> Passkeys are sort of changing things,

Yeah, like changing poo with diarrhoea.

Because everything is sitting out on the public internet now, only protected by those things.

My web app makes you enter your password two times before you can log in. It’s twice as secure!

Microsoft's auto-logout appears to be implemented in the frontend. If I leave the Outlook or Teams tabs opened but idle for a few hours I get kicked and have to log in again, but I have an addon that will unload tabs I haven't interacted with for an hour, and one day I noticed that if I intentionally let those tabs get unloaded, and only keep them loaded when I'm using them, I can stay logged in for weeks or months.