> he no longer feels that the Lucia library is an ergonomic way of implementing auth

has he written up why? lots to learn here

edit: oh: https://github.com/lucia-auth/lucia/discussions/1707

this is great. he saw the coming complexity explosion, that the library was no longer useful to him personally, and took the humble route to opt out of the Standard Model of library slop development. rare.

Yeah, but Lucia is just going to be immediately replaced with some other popular auth library.

The thing is, 99% of people really do just need 'log in / log out', and this is an incredibly useful thing to have as a library.

If you need Web 8.0 passkeys served via WASM eliptic curve sockets or whatever, sure, roll your own or use Auth0. But it feels really silly for the consensus around auth to be 'oh, you're making a CRUD cooking app to share your love of baking? cool, well here's the OAuth spec and a list of footguns, go roll some auth'. It's not a good use of that person's time - they should be focussed on their actual idea rather than being forced to reinvent plumbing - and tons of people are going to get it wrong and end up with effectively no auth at all.

Been rolling my own auth today for luls. Thanks for this :)

The top stackoverflow answer you link to disagrees with you: "In practice though, no widely used mail systems distinguish different addresses based on case."

The standard says one thing, yet implementers do another. In this case following the letter of the standard gets you in trouble in the real world.

My practice on this is to store the user-provided case, but do case insensitive lookups.

This means that you send emails to the case-sensitive address originally entered, but the user is free to login case insensitively.

The downside is that you cannot have two distinct users with emails that only differ in their case. But I feel rather OK about that.

I had case where you could register with your email and the email then became your username which was used to login. The email was case insensitive but the username created from the email was case sensitive, if you created the account with uppercase capital letter email, that was your username and case insensitive email didn’t work to login.

Let’s abolish capitalization altogether. Such a waste. And time zones next. UTC FTW! Then we can do away with languages, and cultural differences. Gazillions of LOC down the drain. I can hear the repositories shrinking already

While in theory it's true, in practice I've seen multiple systems that due to early implementation bugs they had multiple cases for the same email, which obviously were from the same person, think JohnDoe@example.com on one user entry and johndoe@example.com in another user entry. These were also coming from different systems, which made it all even more troublesome.

I would argue the risk matrix of having case-insensitive emails looks much better than the risk matrix of having case-sensitive emails (meaning, you should lowercase all the emails and thus The Copenhagen Book is right, once again).

It's worth noting that most reputable transaction email services only accept ASCII characters in email addresses so it's at least worth notifying the user that non ASCII emails are not allowed.

In most cases an accented character is a typo. If you have a non ASCII email I guess you are used to pain on the internet.

Just a small comment/opinion on the inscrutability of crypto:

Crypto relies on number theory and a complexity theoretical assumption that N!=NP (i.e. that there exists one-way/trapdoor functions).

I think it is opaque by the very nature of how it works (math).

Understanding finite fields or elliptic curves (integer groups really) made me able to grok a lot of crypto. It is often a form of the discrete-logarithm problem somehow.

> when user token is almost expired - instead of generating new security token Lucia suggesting just to extend life of existing one

The link you posted shows code to extend the session, which is common practice (it's called rolling session), not to "extend" the token's life (which should be impossible, a token needs to be immutable in the first place, which is why refreshing a token gives you a new token instead of mutating the original).

If you destroyed a token and send a reply to the client with a new token, but the client already sent you a new request with old token, that request will be denied.

I don't think there's any difference between extending the existing session and creating a new one in Lucia's context.

In the first scenario, the attacker steals the token and uses it forever. In the second, the attacker steals the token and they'll get a fresh one near its expiry. They can still impersonate the user forever. The user might notice something when they get kicked out (because the attacker renewed the token, rendering the old one invalid) but it's unlikely. For good UX, you need a grace period anyway, otherwise legitimate users can have problems with parallel requests (request one causes a token refresh, request two gets rejected because it was initiated before the first one was completed).

You can use a second token (a refresh token) but it only pushes the risk to the second token. Now we need to worry about the second token being stolen and abused forever.

Refresh tokens are useful for not having to hit the database on every request though: Typically, the short lived session token can be validated without hitting the db (e.g. it's a signed JWT). But it means that you can't invalidate it when stolen, it will be valid until expiry time so the expiry time has to be short to limit the damage. For the refresh token, on the other hand, you do hit the db. Using a second token doesn't add any security, hitting the db does, because the refresh token can be invalidated (by deleting it from the db).

Lucia always hits the db (at least in their examples), so you can invalidate tokens anytime. To mitigate risks, you can allow the user to see and terminate their active sessions (preferably with time, location, and device info: "Logged in 12 AM yesterday from an iPhone in Copenhagen"). You could also notify the user when someone logs in from a new location or device.

That's about all you can do. There's simply no fully secure way of implementing long-lived sessions.

I think you’re reading into the name a little, haha. I’m interested in your alternative method for session token replacement, though! I think you make a good point, but I’m not an expert by any means.

There is no "one-time" over the network. Invalidating the refresh token immediately when the server recieves it is asking for trouble.

Too complicated, not suitable for everyday authentication in my opinion.

Seriously, the way auth in general is developing right now, I think we approach a point of insecurity through obscurity.

And with applications states, you need to adapt the application logic to authentication and the application then would have to check if someone maybe stole your refresh token.

Most systems implement a grace period for refresh token reuse for similar reasons. Transactions don’t really solve it. (Ex: You open two tabs quickly, hitting the server with the original refresh token twice)

You are probably familiar with a document called OAuth Threat model.

In that document, refresh token rotation is preferred, but it also addresses the obvious difficulty in clustered environments: https://datatracker.ietf.org/doc/html/rfc6819#section-5.2.2....

Sorry, but that doesn't work in real world applications. Multiple requests are fired simultaneously all the time. E. g. browsers starting with multiple tabs, smartphone apps starting and firing multiple requests etc.

> The other thing devs and auth frameworks miss is the "state" parameter.

What do you mean?

This resource has a good recommendation on how session lifetimes should work.

Roughly, that it should continue for 30 days if used within 30 days.

https://thecopenhagenbook.com/sessions#session-lifetime

Notion is the worst offender for me, not because of its frequency but because it will actually interrupt an active session and forces you to log back in. Worse, the session seems to last just a minute or two longer than one week, which means it will boot you this week just a little bit after you started your work last week.

A few weeks back I logged in right before a recurring meeting to take notes, and for several weeks running it's been interrupting me in the middle of that meeting to force me to log in again.

Are you sure you haven't toggled something in your browser settings? There are a plethora of settings that would wind up rendering those "remember me" buttons useless. Anecdotally, I haven't had any issues with staying logged into websites. Github being one of them.

Some authentication providers cap token lifetime depending on pricing plan.

At least you can enjoy security theater.

Um, my session with GitHub never expires - weird.

[flagged]

Its adoption was hindered by patents.

> Like a lawyer who advises you not to do anything ever.

One of my most frequent criticisms of teams responsible for security is that they spend a lot of time telling people what not to do instead of proactively providing them with efficient tools or methods for doing what they want to do.

I would have liked to see a section on SAML and a high-level overview of how to implement it.

I'd recommend email flow like email verification and password reset to last for several days if the secret token is strong enough. Email can be seen as a more secure system, so it may not be available immediately and everywhere.

They discuss session tokens, passwords and webAuthn so both.

Embedded browsers have many great use cases, but navigating to arbitrary links is not one of them.

It's virtually never useful to me when I click on a link in Slack or whatever, then respond to a text message, and go back to my browser expecting to find my page there, and it's nowhere because Slack has gobbled it up in its own browser.

Fortunately I just checked and there's a way to disable the embedded browser in Slack.

The guy seems to have quite a few projects with geography references for no specific reason. So I guess the answer is: it's catchy and easy to remember for most people.

Authentication with Danish services tends to rely on MitID ("my ID"): https://www.mitid.dk/en-gb/about-mitid/

It seems MitID isn't mentioned in The Copenhagen Book: https://www.google.com/search?q=site%3Athecopenhagenbook.com...

Iceland and the Faroes follow the same one-for-all approach: https://www.audkenni.is/, https://www.samleikin.fo/.

Things are a bit more fragmented in Finland, Norway and Sweden: https://www.norden.org/en/info-norden/electronic-identificat..., https://www.norden.org/en/info-norden/electronic-identificat..., https://www.norden.org/en/info-norden/electronic-identificat...

So, it's maybe not too much of a stretch to say that "a Copenhagen way" to authenticate is to integrate with MitID, either through a certified broker or by becoming one: https://www.mitid.dk/en-gb/broker/broker-certification/

UUIDv4 has no more entropy than its generator, that's why it can be generated only by a CSPRNG. If you use a generator with 32 bits entropy, you can generate only 4 billion uuids and they will begin to collide after 64k ids due to birthday paradox.

My guess is that so people who manage to access database backup cannot hijack accounts plus it gives a good defence against timing attacks as a bonus.

Exactly that. (Hijack session rather than account: any competently designed system should require re-auth before any action that would allow permanent account takeover).

[dead]

This is why password managers are wonderful - let it make one for you, and then it remembers it for the next time you need to hit that site.

Yeah, at least most people eventually abandoned the ridiculous idea of mandatory password renewal ever six months …

your antivirus is arguably a malware itself. you don't need to give a 3rd party your entire internet browsing content to have a secure computer.

[flagged]

Why would that be? Did they try to sell you some silly con snake-oil?

Or is it just that AVAST is aghast because some site is trying to spread some common sense? (against silicon snake-oil maybe?)

Do you think you should blindly trust AVAST?

Maybe it's just their servers suffering from some hiccups, causing their clients to have burps?

This happened before to all of those applications from any vendor, including that built-in microsoft-thing.

Multiple times.

Maybe it's just because it's using too many technical terms about cryptology, in unusual ways.

Must be a bad h4xx0r then!

Bang! Automagically blacklisted by some black-box.

Don't be a cargo-culting fashion victim.

(...zalgorithms on crack, brainz out of whack...)

> Most people will never use a password manager

Prediction: in 10 years nearly everyone will be using a password manager; it will come with their OS (Android or iOS) with browser plugins for other OS’s, and the integration with mobile apps and mobile web will be so tight that people will not even realize they are using passwords, most of the time.

Apple just massively revamped their own manager in the latest iOS release. They already have pretty good integration with mobile web and with App Store apps.

In the next couple of years I expect to see pw manager integration made a firm requirement for App Store apps, and I expect to see web standards for account signup and login that make pw managers reliable.

I suspect Google will follow suit although I am not familiar with Android’s capabilities in that area.

So in a few years you will not type an email address and password to sign up for things; the OS will prompt you: “foo.com is asking you to sign up, would you like to do this automatically?” and if you respond in the affirmative you’ll get a site-specific email address and password automatically created and stored for you, and that will be used whenever you want to log in. Recovery will shift to a mobile account centric workflow (Apple ID or Google account) rather than email based password reset links.

If a data breach is reported the pw manager app can notify you and give you a one-button-click experience to reset your password.

The downside is that if you get canceled by Apple or Google it will be a special kind of hell to recover.

> If you're doing auth in 2024, please consider not supporting passwords.

And then realize that you need to support them, because they are the most universal solution there is for an average user. Email/Username + Password is the most portable way to do login as a user that we have invented.

Better advice is to be honest about your product/project's social scope and make appropriate choices for that scope, or else let your users make that choice for themselves.

The world is not improved or made more robust if every experience online must be gated through some third-party vendor's physical widget (or non-trivial software).

There are parts of our lives that benefit from the added securiry that comes alongside that brittleness and commercial dependence, and parts that don't. Let's not pretend otherwise.

That seems false. Key-based approaches I understand to be less secure than passwords, albeit of course not if someone is reusing passwords found in breaches

And I can't get my head around passkeys yet. Haven't switched to them. Haven't developed a clear model of where's my private key exactly how many of them and how to get to them if my camera or fingerprint sensor isn't working etc.

I hate this take. I understand it and I don't want OAuth2 to not exist, but it isn't a *replacement*.

There are two critical things you lose with OAuth. First, it's centralization so you must trust that player and well now if that account is compromised everything down steam is (already a problem with email, who are the typical authorities). Second is privacy. You now tell those players that you use said service.

Let me tell you as a user another workflow. If you use bitwarden you can link Firefox relay, to auto generate relay email addresses. Now each website has not only a unique password, but a unique email. This does wonders for spam and determining who sells your data, AND makes email filters much more useful for organization. The problem? Terrible UX. Gotta click a lot of buttons and you destroy your generated password history along the way (if you care). No way could I get my parents to do this, let alone my grandma (the gold standard of "is it intuitive?" E.g Whatsapp: yes; Signal: only if someone else does the onboarding).

There's downsides of course. A master password, but you do control. At least the password manager passes the "parent test" and "girlfriend test", and they even like it! It's much easier to get them (especially parents) to that one complicated master passphrase that the can write down and put in a safe.

A lot of security (and privacy) problems are actually UI/UX problems. (See PGP)

OAuth recognized this, but it makes a trade with privacy. I think this can be solved in a better way. But at minimum, don't take away password as an option.

You need the password for the lost passkey flow. Well, you don't need it, but it's an extra layer.