If I'm not mistaken, this is written by the author of Lucia, a popular auth library for TypeScript [0]. He recently announced that he will be deprecating the library and be replacing it with a series of written guides [1], as he no longer feels that the Lucia library is an ergonomic way of implementing auth. He posted an early preview of the written guide [2] which I found enjoyable to read and complements The Copenhagen Book nicely.
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.
Haha I've been working on my cooking app[0] (not ready yet, join the waiting list!), and for the last 1 month I've been implementing auth with AuthKit (bad experience IMHO, should have just self host SuperTokens in hindsight), experiencing what you described here 1:1
Wow, this is very nice. One of my pet peeves is how 90% of security resources seem designed to be absolutely inscrutable by non-security experts - especially anything from cryptography. Every single page in here however is clear, concise, to the point, and actionable, love it! (except the one on elliptic curves, which I find about as incomprehensible as most crypto resources).
There are two things that everybody misses about OAuth and they fly under the radar.
Nice to hear someone touch on one of them: you absolutely NEED to use a transaction as a distributed locking mechanism when you use a token.
This goes double/quadruple for refresh tokens. Use the same token more than once, and that user is now signed out.
It doesn't matter if your system runs on one machine or N machines; if you have more than one request with a refresh token attached in flight at once - happens all the time - you are signing out users, often via 500.
Refresh tokens are one-time use.
The other thing devs and auth frameworks miss is the "state" parameter.
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)
Would be nice to see alternative documents for similar topics (e.g. something like OWASP Cheatsheet but from more practical point of view).
With all the respect, I'm a bit skeptical about this document for such reasons:
- Name is quite pompous. It's a very good marketing trick: calling some document like if it was written by group of researchers from a Copenhagen university. :)
Yes, Lucia is a relatively popular library but it doesn't mean that it is promoting best practices and that its author should be considered an authority in such important field unless opposite is proven.
- I don't like some aspects of Lucia library design: when user token is almost expired - instead of generating new security token Lucia suggesting just to extend life of existing one. I see it as a very insecure behavior: token lives forever and can be abused forever. This violates one of the security best practices of limited token lifetime.
But both Lucia and "Copenhagen Book" encourages this practice [1]:
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.
I recently learned about the SRP protocol [1], and I’m surprised that it’s not more widely used/mentioned: with a relatively simple protocol, you can do a ZKP and generate a session token between the server and client in one fell swoop.
I wish more websites would grant you the option to say "I never want my session to expire until I log out, I understand the risks". The "remember me" button does nothing these days.
I'm so tired of having my day constantly interrupted by expiring sessions. GitHub is my least favourite; I use it ~weekly, so my sessions always expire, and they forced me to use 2FA so I have to drag my phone out and punch in random numbers. Every single time.
As well as being terrible UX, though I have no evidence to back this up, I'm pretty sure this constant logging in fatigues users enough to where they stop paying attention. If you log into a site multiple times a week, it's easy for a phishing site to slip into your 60th login. Conversely if you've got an account that you never need to log into, it's going to feel really weird and heighten your awareness if it suddenly does ask for a password.
Regardless, companies should learn that everyone has a different risk appetite and security posture, and provide options.
Side-note, Github's constant session expiry & 2FA annoyed me so much that I moved to Gitea and disabled expiry. That was 90% of the reason I moved. It's only available on my network too, so if anything I feel I gained on security. Companies 100% can lose customers by having an inflexible security model.
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.
Random users might not, but this is HN. You're getting down voted for your condescending tone about an issue that, for most technical people here, has extremely obvious risks.
Instead of implying that others are ignorant in a low-value comment, list out why you think this is a bad idea.
Seems like an "I understand the risks, keep me signed in" button would affect more than just HN users. Unless you have to prove you know the risks by logging into a HN profile with at least 1000 karma, or taking a short quiz on authentication best practices, or something.
Nah, it's a stupid opinion to think you should just cache creds forever and doesn't deserve more than I've given. On a fuckin tech site of this caliber. This isn't a Facebook group and it's frankly frightening that I'd have to here, of all places.
Just chiming in that I appreciate this resource. A lot of security advice is esoteric and sometimes feels ridiculous. Like a lawyer who advises you not to do anything ever. This guide was refreshingly concise, easy to follow and understand, and has good straight forward advice.
I'll keep an eye on these comments to see if there are any dissenting opinions or caveats but I know I'll be reviewing this against my own auth projects.
One thing I would like to see would be a section on JWT, even if it is just for them to say "don't use them" if that is their opinion.
> 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.
A) fair, b) I think this common distinction is a little overblown. Authorization is just a particularly straightforward CRUD feature, perhaps with some inheritance logic — authentication seems to be where 99% of all security sadness comes into play.
Plus there’s the less-often-discussed task of protecting some of your users from other users, such as Google vetting their html5 ads for malware, and military (all B2B?) contractors trying to write tools that aren’t useful to insider threats. It’s worse than either auth* domain IMO, as it usually involves unavoidable tradeoffs for benign users; I haven’t read this book in full but I suspect it didn’t make the list!
TBF, I’m not sure it even has a standard name yet like the other two… anyone know enough to correct me? Maybe… “encapsulation”? “Mitigation”? The only “auth*” term left is arguably “authorship”, which doesn’t really fit https://www.thefreedictionary.com/words-that-start-with-Auth
Edit; I think I just taught myself what complex authorization is! I’ve always treated it as role management, but “what roles can do what” does also fit, I have now realized. Sorry y’all - leaving it up in case it’s a learning experience for others lol
What people want is authorization. Authentication is a painful activity that must be performed in order to do authorization properly in most cases.
Side note: there is a trivial case where authentication is reduced to “whoever is physically holding/interacting with the system”. This is when either the operation to be authorized is relatively low risk (changing the channel on the TV with the line-of-sight IR remote control) or when you’re depending on physical security controls to prevent access to people who shouldn’t be doing the thing, e.g. requiring data center technicians to badge in before they can go into the server room and start disconnecting things.
To be fair, once someone has physical access to the machine, them having full access is just a matter of time and effort. So at that point it's security-through-too-much-effort-to-bother.
There should be a unified theory that all auth can be stacked on top of. Like, a theory of secure communication, that deals with the problem of adding security/reliability/etc. properties to a communication channel.
Authz is usually much more complex than strict authN since authz gets much more into the thorny people problems, things like "how do you build a system allowing arbitrary organizations of people (your customers) to systematize how they want the people within their organization to be able to access/change things." A better term I've heard is "governance" which is more indicative of the stodgy, thorny, people-oriented nature of the problem, just like governments!
There's also lots of potential levels of granularity and thus complexity, with the most granular (that I've seen) being able to model access through time as a continuum down to the individual field of each object in the business, based on wide arrays of arbitrary other factors. Think modeling problems like:
> "If condition X in the business is true then I want user X to be unable to view/edit the 'foobar' field of entity 'powzap', and I only want this rule to be true on Tuesdays of the months April and October".
That's a tough problem to tackle with a lot of subtlety to wrangle.
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.
I wonder why they recommend hashing server tokens in some cases. Is it so that someone who can read the database can’t hijack an account? Or am I misunderstanding why hashing is used?
Exactly that. (Hijack session rather than account: any competently designed system should require re-auth before any action that would allow permanent account takeover).
More generally it protects against anybody who has access to the database, including bad actors if it's leaked.
I don't think it protects against timing attack because the common way of doing it is just to use sha256 and use the resulting hash to do a lookup in the database. This is not a fixed time operation
It’s nice to see something other than “don’t roll your own, it’s dangerous.”
I especially appreciated the note that while UUIDv4 has a lot of entropy, it’s not guaranteed to be cryptographically secure per the spec. Does it matter? For nearly all applications, probably not, but people should be aware of it.
Good stuff. The model of "how to build" vs. "library that does" is a good idea when there's combinatorial explosion and you want to reduce the design space.
At a previous employer, people built some tool that auto-built Kube manifests and so on. To be honest, I much preferred near raw manifests. They were sufficient and the tool actually added a larger bug space and its own YAML DSL.
- Passwords must be at least 8 characters long....
- Use libraries like zxcvbn to check for weak passwords.
These rules might be good for high-security sites, but it's really annoying to me when I have to generate a length-15 string password with special characters and uppercase for some random one-off account that I use to buy a plane ticket or get reimbursed for a contact lens purchase.
If you're doing auth in 2024, please consider not supporting passwords. Most people will never use a password manager, and even if they did it's not as secure as key-based approaches or OAuth2.
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.
And then losing access to everything when moronic automated Google systems ban your account for $REASON with no chance to appeal it.
I recently ran into an interesting problem -- my Microsoft account (used as a spam lightning rod) borked a passkey stored on a Fido token and refused a paswordless sign in. Same thing happened with a second backup token made by a different company. If I didn't have a password fallback, and that account was important, I would have a massive problem with no way to solve it. But the world has not yet gone completely insane, so I fired up my trusty KeePassXC and was in in less than a minute.
I love the idea of passkeys; I hate the experience of passkeys, especially when it comes to having to reach for my phone to log into a desktop web site.
It certainly looks that way. It's either going to be cell phone integration, or ER GLASSES(ex meta raybans). I would like to see the incorporation of a ring(real unintrusive wearable NFC I can activate or press<for presence confirmation> with my thumb by just raising my hand above the keyboard{For illustration, you ever seen guys spin their wedding band with their thumb as a twiddling activity??}).
> 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.
Every project has some amount of "being quirky/different" capital. If your project is not explicitly trying to innovate, or does not for some particular reason need to be very secure, then do not spend that capital on confusing users with the login flow. You'll turn a bunch of users away and cause a whole lot of support tickets, for very little benefit. Make users only think about stuff by making it unintuitive or different if it's really worth it to your product.
Email + magic link is a lot better for most use cases.
It's a lot simpler to implement (just one flow instead of signin / signup / forgot), less catastrophic when your data is breached, piggybacks on the significant amount of work that already goes into securing email, gives you 90% of the benefits of 2FA / FIDO / Web Authn / whatever for free with 0 implementation cost, makes account sharing harder (good for business), and is easy to extend/replace with oAuth for specific domains.
> Email + magic link is a lot better for most use cases.
Wouldn't systems like this put a lot of trust on their users? Say you use a magic link on an compromised wifi network, like in a hotel, coffee shop, airport and so on without being on a VPN. Which some users will inevitable do.
I completely agree with the "most use cases" though. As long as you can't change the associated e-mail without additional requirements.
Email + magic link is a pattern I keep seeing that's far more secure in practice. So is email + email OTP.
(I've also seen phone + phone OTP, but oh please never ask me for a phone number ever again. My phone number should always only be for making and receiving calls, not for verifying any sort of identity or personhood.)
Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how).
Hell, I've seen at least one site that keeps the login username (what you actually use to sign into your account) separate from the public username (what everyone else sees), just to even more disconnect the login credentials from anything a potential attacker would have access to. But this is overkill for most scenarios (that particular platform does have a good reason).
I find it problematic if I do not have access to my email in the moment, or there is a glitch in the flow and I need to wait for the mail for some minutes, but that can also happen during 2FA, if email is used for that.
Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC.
Though I've really enjoyed using QR codes to login, that has been a really smooth modern experience.
"Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC."
I feel that way too - I hate it when I'm trying to log in on desktop and the email shows up as a push notification on my phone.
The problem is what happens if someone enters someone else's email address and that person unwittingly clicks on the "approve" link in the email they receive. That only has to happen once for an account to be compromised.
So now you need "enter the 4 digit code we emailed you" or similar, which feels a whole lot less magical than clicking on a magic link.
Presumably there are well documented patterns for addressing this now? I've not spent enough time implementing magic links to have figured that out.
> someone enters someone else's email address and that person unwittingly clicks on the "approve" link
Eh? In a sane magic link system, clicking the magic link grants the clicker access to the account. Right then and there, in the browser that opened the link.
That's a bit weird for me: I sat down at my laptop and attempted to sign into a site on my laptop, and at the end of the sign-in flow I'm not signed in on my laptop, I'm signed in on my phone.
I would argue that a magic link system has to only allow the click-through to grant access on the machine that initiated the login flow.
If I enter my email in SomeSite, they send a magic link to my email address, and then Mallory intercepts that email and gains access to my SomeSite account just by opening the link (i.e. the link acts as a bearer token), that's completely broken.
> Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC.
No.
If magic links only log you in on the device you click them on, they prevent a lot of phishing attacks.
With a setup like that, there's literally no way to impersonate your website and steal user credentials.
This comes at a cost of making logins on public computers less secure, and which of these is more important should be weighed on a service-by-service basis.
A website for making presentations should obviously choose "more phishing and easier to use on public computers", a service for managing your employees' HR records should obviously choose the opposite.
Two scenarios I had recently, where I absolutely, utterly hated this pattern:
* I did not remember the mail address for such a thing because I started (too late) to use a different mail address for every service, thanks to Apples iCloud hidden addresses. And because there was no corresponding password, there was no entry in my password manager. I since rectified that, but it’s annoying.
* I tried to login on an older Windows PC - the magic mail landed on my iPhone. And because cross-system technical standards are a thing of the past the only possibility to get the magic link to the other system was to transcribe it.
> Email + magic link is a pattern I keep seeing that's far more secure in practice.
I absolutely despise this. Every time I want to quickly log into an app and check something, just to sit in front of my synchronising mail client, wondering if the email will arrive, be caught by the spam filter, or just have random delay of a few minutes. Awful.
I first saw this with Anthropic. I clear my browser pretty regularly and this flow just adds so much friction. With a password manager plus totp I never really felt burdened by logging in every time I used a service. I hope this doesn't catch on.
> Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how).
Honestly, this just seems like a UX problem.
The ways this is currently implemented are often terrible, but not always. I'll give an example: I recently did a stint at "Green company" and they gave me a yubi key. They also used Microsoft for most things. To login with Microsoft authenticator I type in my username and password, click yes on the next page, and then click yes on my phone. But to use the yubi key was needlessly frustrating. First, Microsoft doesn't let you use it as the default method (hardware key). So then you have to click "use another form of authentication", "hardware key", "next" (why? Idk), and then finally you pin and tap the key. A bunch of needless steps there and I'm not convinced this wasn't intentional. There's other services I've used working at other places where it's clean and easy: username + password, then pin+ tap key (i.e. hardware key is default!).
I seriously think a lot of security issues come down to UX. There's an old joke about PGP
How do you decrypt a PGP encrypted email?
You reply to the sender "can't decrypt, can you send it back in clear?"
It was a joke about the terrible UX. That it was so frustrating that this outcome was considered normal. But hey, we actually have that solved now. Your Gmail emails are encrypted. You have services like Whatsapp and Signal that are E2EE. What was the magic sauce? UI & UX. They are what make the tools available to the masses, otherwise it's just for the nerds.
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.
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.
Your keys are in your password manager of choice, you can create one per service+manager (eg. your google account can have one passkey using iCloud Keychain, and another one using bitwarden). If you lose access to your PM, the other recovery processes would take place.
It might help your mental model to think about them as identical to hardware security keys. Except now you don't need to buy a specific hardware key, your password manager is it. You can also just use your hardware key as your passkey, same thing (as long as the key supports FIDO2).
Specifically for your question on what happens if you lose face/fingerprint sensor. So this would be assuming you use Android/iOS's password managers, in that case even with biometrics failing you can just use the code you set on your device as both have fallbacks.
Couldn't we just make password managers pretend that they're a Jubikey or similar?
Is it that Jubikeys don't offer any extra (master password / biometric) authn, and hence are only suitable as a second factor, where password managers can be used as both?
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.
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
If I'm not mistaken, this is written by the author of Lucia, a popular auth library for TypeScript [0]. He recently announced that he will be deprecating the library and be replacing it with a series of written guides [1], as he no longer feels that the Lucia library is an ergonomic way of implementing auth. He posted an early preview of the written guide [2] which I found enjoyable to read and complements The Copenhagen Book nicely.
[0] https://github.com/lucia-auth/lucia
[1] https://github.com/lucia-auth/lucia/discussions/1707
[2] https://lucia-next.pages.dev/
> 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.
There is a Github Discussion where he goes into more detail. He also talks about it on his twitter:
https://github.com/lucia-auth/lucia/discussions/1707
https://x.com/pilcrowonpaper/status/1843258855280742481
What an insanely impressive dude. All that and he just started going to university this year.
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.
Haha I've been working on my cooking app[0] (not ready yet, join the waiting list!), and for the last 1 month I've been implementing auth with AuthKit (bad experience IMHO, should have just self host SuperTokens in hindsight), experiencing what you described here 1:1
[0] https://prepbook.app
Been rolling my own auth today for luls. Thanks for this :)
Wow, this is very nice. One of my pet peeves is how 90% of security resources seem designed to be absolutely inscrutable by non-security experts - especially anything from cryptography. Every single page in here however is clear, concise, to the point, and actionable, love it! (except the one on elliptic curves, which I find about as incomprehensible as most crypto resources).
There are two things that everybody misses about OAuth and they fly under the radar.
Nice to hear someone touch on one of them: you absolutely NEED to use a transaction as a distributed locking mechanism when you use a token.
This goes double/quadruple for refresh tokens. Use the same token more than once, and that user is now signed out.
It doesn't matter if your system runs on one machine or N machines; if you have more than one request with a refresh token attached in flight at once - happens all the time - you are signing out users, often via 500.
Refresh tokens are one-time use.
The other thing devs and auth frameworks miss is the "state" parameter.
> The other thing devs and auth frameworks miss is the "state" parameter.
What do you mean?
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)
Would be nice to see alternative documents for similar topics (e.g. something like OWASP Cheatsheet but from more practical point of view).
With all the respect, I'm a bit skeptical about this document for such reasons:
- Name is quite pompous. It's a very good marketing trick: calling some document like if it was written by group of researchers from a Copenhagen university. :)
Yes, Lucia is a relatively popular library but it doesn't mean that it is promoting best practices and that its author should be considered an authority in such important field unless opposite is proven.
- I don't like some aspects of Lucia library design: when user token is almost expired - instead of generating new security token Lucia suggesting just to extend life of existing one. I see it as a very insecure behavior: token lives forever and can be abused forever. This violates one of the security best practices of limited token lifetime.
But both Lucia and "Copenhagen Book" encourages this practice [1]:
``` if time.Now().After(session.expiresAt.Sub(sessionExpiresIn / 2)) { session.ExpiresAt = time.Now().Add( updateSessionExpiration(session.Id, session.ExpiresAt) } ```
[1]: https://thecopenhagenbook.com/sessions#session-lifetime
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.
Nice.
I recently learned about the SRP protocol [1], and I’m surprised that it’s not more widely used/mentioned: with a relatively simple protocol, you can do a ZKP and generate a session token between the server and client in one fell swoop.
[1]: https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
I wish more websites would grant you the option to say "I never want my session to expire until I log out, I understand the risks". The "remember me" button does nothing these days.
I'm so tired of having my day constantly interrupted by expiring sessions. GitHub is my least favourite; I use it ~weekly, so my sessions always expire, and they forced me to use 2FA so I have to drag my phone out and punch in random numbers. Every single time.
As well as being terrible UX, though I have no evidence to back this up, I'm pretty sure this constant logging in fatigues users enough to where they stop paying attention. If you log into a site multiple times a week, it's easy for a phishing site to slip into your 60th login. Conversely if you've got an account that you never need to log into, it's going to feel really weird and heighten your awareness if it suddenly does ask for a password.
Regardless, companies should learn that everyone has a different risk appetite and security posture, and provide options.
Side-note, Github's constant session expiry & 2FA annoyed me so much that I moved to Gitea and disabled expiry. That was 90% of the reason I moved. It's only available on my network too, so if anything I feel I gained on security. Companies 100% can lose customers by having an inflexible security model.
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.
Logout on a Saturday and reset the cycle
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.
Yes I am definitely confident with how my browser is configured. Our usage patterns/tolerances must simply be different.
Part of the issue is I use it weekly from 3 different devices, so there's always one device that needs another login.
I know it's not my browser, as on my own web apps I set the maxAge of my session cookies to 10 years and they work perfectly.
Um, my session with GitHub never expires - weird.
Some authentication providers cap token lifetime depending on pricing plan.
You don't understand the risks, that's why we enforce shit like that, sincerely, all admins.
Edit: For a site that just loves to quote "Chestertons Fence" y'all don't really seem to understand what it means.
Random users might not, but this is HN. You're getting down voted for your condescending tone about an issue that, for most technical people here, has extremely obvious risks.
Instead of implying that others are ignorant in a low-value comment, list out why you think this is a bad idea.
Seems like an "I understand the risks, keep me signed in" button would affect more than just HN users. Unless you have to prove you know the risks by logging into a HN profile with at least 1000 karma, or taking a short quiz on authentication best practices, or something.
Nah, it's a stupid opinion to think you should just cache creds forever and doesn't deserve more than I've given. On a fuckin tech site of this caliber. This isn't a Facebook group and it's frankly frightening that I'd have to here, of all places.
Just chiming in that I appreciate this resource. A lot of security advice is esoteric and sometimes feels ridiculous. Like a lawyer who advises you not to do anything ever. This guide was refreshingly concise, easy to follow and understand, and has good straight forward advice.
I'll keep an eye on these comments to see if there are any dissenting opinions or caveats but I know I'll be reviewing this against my own auth projects.
One thing I would like to see would be a section on JWT, even if it is just for them to say "don't use them" if that is their opinion.
> 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.
There's an issue tracking that at https://github.com/pilcrowOnPaper/copenhagen/issues/3
we at workos wrote about it here: https://workos.com/blog/the-developers-guide-to-sso
By “auth” do they mean “authn” (authentication) or “authz” (authorization)?
It looks like they mean authentication but it would be nice if they were clear.
They discuss session tokens, passwords and webAuthn so both.
All of those things are authentication, not authorisation. https://www.okta.com/identity-101/authentication-vs-authoriz...
A) fair, b) I think this common distinction is a little overblown. Authorization is just a particularly straightforward CRUD feature, perhaps with some inheritance logic — authentication seems to be where 99% of all security sadness comes into play.
Plus there’s the less-often-discussed task of protecting some of your users from other users, such as Google vetting their html5 ads for malware, and military (all B2B?) contractors trying to write tools that aren’t useful to insider threats. It’s worse than either auth* domain IMO, as it usually involves unavoidable tradeoffs for benign users; I haven’t read this book in full but I suspect it didn’t make the list!
TBF, I’m not sure it even has a standard name yet like the other two… anyone know enough to correct me? Maybe… “encapsulation”? “Mitigation”? The only “auth*” term left is arguably “authorship”, which doesn’t really fit https://www.thefreedictionary.com/words-that-start-with-Auth
Edit; I think I just taught myself what complex authorization is! I’ve always treated it as role management, but “what roles can do what” does also fit, I have now realized. Sorry y’all - leaving it up in case it’s a learning experience for others lol
What people want is authorization. Authentication is a painful activity that must be performed in order to do authorization properly in most cases.
Side note: there is a trivial case where authentication is reduced to “whoever is physically holding/interacting with the system”. This is when either the operation to be authorized is relatively low risk (changing the channel on the TV with the line-of-sight IR remote control) or when you’re depending on physical security controls to prevent access to people who shouldn’t be doing the thing, e.g. requiring data center technicians to badge in before they can go into the server room and start disconnecting things.
To be fair, once someone has physical access to the machine, them having full access is just a matter of time and effort. So at that point it's security-through-too-much-effort-to-bother.
There should be a unified theory that all auth can be stacked on top of. Like, a theory of secure communication, that deals with the problem of adding security/reliability/etc. properties to a communication channel.
There is a lot of formal research on both authentication and authorization. IIRC Butler Lampson’s Turing Award was based on work he did in that area: https://amturing.acm.org/award_winners/lampson_1142421.cfm
Authz is usually much more complex than strict authN since authz gets much more into the thorny people problems, things like "how do you build a system allowing arbitrary organizations of people (your customers) to systematize how they want the people within their organization to be able to access/change things." A better term I've heard is "governance" which is more indicative of the stodgy, thorny, people-oriented nature of the problem, just like governments!
There's also lots of potential levels of granularity and thus complexity, with the most granular (that I've seen) being able to model access through time as a continuum down to the individual field of each object in the business, based on wide arrays of arbitrary other factors. Think modeling problems like:
> "If condition X in the business is true then I want user X to be unable to view/edit the 'foobar' field of entity 'powzap', and I only want this rule to be true on Tuesdays of the months April and October".
That's a tough problem to tackle with a lot of subtlety to wrangle.
The first two are both authn. Is webAuthn about authz? (I don't doubt it.)
Anyone know why it's called the Copenhagen Book?
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.
I wonder why they recommend hashing server tokens in some cases. Is it so that someone who can read the database can’t hijack an account? Or am I misunderstanding why hashing is used?
Exactly that. (Hijack session rather than account: any competently designed system should require re-auth before any action that would allow permanent account takeover).
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.
More generally it protects against anybody who has access to the database, including bad actors if it's leaked.
I don't think it protects against timing attack because the common way of doing it is just to use sha256 and use the resulting hash to do a lookup in the database. This is not a fixed time operation
i see that most examples are implemented in golang, if possible would also request the author to consider adding python and node.js snippets
It’s nice to see something other than “don’t roll your own, it’s dangerous.”
I especially appreciated the note that while UUIDv4 has a lot of entropy, it’s not guaranteed to be cryptographically secure per the spec. Does it matter? For nearly all applications, probably not, but people should be aware of it.
I like it but and I know it’s nit picky- is there a off or other book like thing one can “hold”
This is a great guide, thanks.
you only need to roll your own auth once and you can drop it in anywhere
Good stuff. The model of "how to build" vs. "library that does" is a good idea when there's combinatorial explosion and you want to reduce the design space.
At a previous employer, people built some tool that auto-built Kube manifests and so on. To be honest, I much preferred near raw manifests. They were sufficient and the tool actually added a larger bug space and its own YAML DSL.
What's with the name?
Great guide, thank you.
- Passwords must be at least 8 characters long....
- Use libraries like zxcvbn to check for weak passwords.
These rules might be good for high-security sites, but it's really annoying to me when I have to generate a length-15 string password with special characters and uppercase for some random one-off account that I use to buy a plane ticket or get reimbursed for a contact lens purchase.
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.
Somehow with password managers we collectively decided that single points of failure where good…
All password managers should support downloading and backing up your passwords, right? You can even self host if you want, at least for Bitwarden.
Yeah, at least most people eventually abandoned the ridiculous idea of mandatory password renewal ever six months …
If you're doing auth in 2024, please consider not supporting passwords. Most people will never use a password manager, and even if they did it's not as secure as key-based approaches or OAuth2.
Obviously there are exceptions
> 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.
Can you imagine a world where instead of sites prohibiting pasting into password fields, they prohibit hunt-and-pecking passwords? It's beautiful.
In 10 years time everyone will be using passkeys, not passwords.
And then losing access to everything when moronic automated Google systems ban your account for $REASON with no chance to appeal it.
I recently ran into an interesting problem -- my Microsoft account (used as a spam lightning rod) borked a passkey stored on a Fido token and refused a paswordless sign in. Same thing happened with a second backup token made by a different company. If I didn't have a password fallback, and that account was important, I would have a massive problem with no way to solve it. But the world has not yet gone completely insane, so I fired up my trusty KeePassXC and was in in less than a minute.
Well, they'd have to ban your account and destroy your device with the passkey before you could change it. I don't think they have that power (yet).
Hahahaha good one.
I love the idea of passkeys; I hate the experience of passkeys, especially when it comes to having to reach for my phone to log into a desktop web site.
In 10 years time we'll have as many “why you should never use passkeys” on HN as we have for JWT nowadays.
Please, for the love of god, no.
It certainly looks that way. It's either going to be cell phone integration, or ER GLASSES(ex meta raybans). I would like to see the incorporation of a ring(real unintrusive wearable NFC I can activate or press<for presence confirmation> with my thumb by just raising my hand above the keyboard{For illustration, you ever seen guys spin their wedding band with their thumb as a twiddling activity??}).
> 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.
Yes, made this mistake in the past.
Every project has some amount of "being quirky/different" capital. If your project is not explicitly trying to innovate, or does not for some particular reason need to be very secure, then do not spend that capital on confusing users with the login flow. You'll turn a bunch of users away and cause a whole lot of support tickets, for very little benefit. Make users only think about stuff by making it unintuitive or different if it's really worth it to your product.
I wish I could upvote more than once!
Email + magic link is a lot better for most use cases.
It's a lot simpler to implement (just one flow instead of signin / signup / forgot), less catastrophic when your data is breached, piggybacks on the significant amount of work that already goes into securing email, gives you 90% of the benefits of 2FA / FIDO / Web Authn / whatever for free with 0 implementation cost, makes account sharing harder (good for business), and is easy to extend/replace with oAuth for specific domains.
Is actively avoid services that only offer magic link Auth - it’s the most annoying shitty method that pushes all the work on me.
No I won’t log into my email multiple times per day because you are too lazy to hash passwords.
It always depends on the audience but if your users are somewhat technically literate you need passwords.
> Email + magic link is a lot better for most use cases.
Wouldn't systems like this put a lot of trust on their users? Say you use a magic link on an compromised wifi network, like in a hotel, coffee shop, airport and so on without being on a VPN. Which some users will inevitable do.
I completely agree with the "most use cases" though. As long as you can't change the associated e-mail without additional requirements.
And that's also a great way to piss the user off…
Email + magic link is a pattern I keep seeing that's far more secure in practice. So is email + email OTP.
(I've also seen phone + phone OTP, but oh please never ask me for a phone number ever again. My phone number should always only be for making and receiving calls, not for verifying any sort of identity or personhood.)
Of course, nothing beats the security and privacy of username + password + TOTP (or security key), but you can't necessarily expect normal users to know to do that (or how).
Hell, I've seen at least one site that keeps the login username (what you actually use to sign into your account) separate from the public username (what everyone else sees), just to even more disconnect the login credentials from anything a potential attacker would have access to. But this is overkill for most scenarios (that particular platform does have a good reason).
I find it problematic if I do not have access to my email in the moment, or there is a glitch in the flow and I need to wait for the mail for some minutes, but that can also happen during 2FA, if email is used for that.
Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC.
Though I've really enjoyed using QR codes to login, that has been a really smooth modern experience.
"Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC."
I feel that way too - I hate it when I'm trying to log in on desktop and the email shows up as a push notification on my phone.
The problem is what happens if someone enters someone else's email address and that person unwittingly clicks on the "approve" link in the email they receive. That only has to happen once for an account to be compromised.
So now you need "enter the 4 digit code we emailed you" or similar, which feels a whole lot less magical than clicking on a magic link.
Presumably there are well documented patterns for addressing this now? I've not spent enough time implementing magic links to have figured that out.
> someone enters someone else's email address and that person unwittingly clicks on the "approve" link
Eh? In a sane magic link system, clicking the magic link grants the clicker access to the account. Right then and there, in the browser that opened the link.
That's a bit weird for me: I sat down at my laptop and attempted to sign into a site on my laptop, and at the end of the sign-in flow I'm not signed in on my laptop, I'm signed in on my phone.
I would argue that a magic link system has to only allow the click-through to grant access on the machine that initiated the login flow.
If I enter my email in SomeSite, they send a magic link to my email address, and then Mallory intercepts that email and gains access to my SomeSite account just by opening the link (i.e. the link acts as a bearer token), that's completely broken.
If someone has access to your email, they can recover passwords to everything. Email is the master key, treat it that way.
Use MFA and that is not the case.
If email is your master key to everything I would worry.
> Also, magic links need to be designed so that I can login on my PC, and click the link on my phone, and be logged in on the PC.
No.
If magic links only log you in on the device you click them on, they prevent a lot of phishing attacks.
With a setup like that, there's literally no way to impersonate your website and steal user credentials.
This comes at a cost of making logins on public computers less secure, and which of these is more important should be weighed on a service-by-service basis.
A website for making presentations should obviously choose "more phishing and easier to use on public computers", a service for managing your employees' HR records should obviously choose the opposite.
> Email + magic link
Two scenarios I had recently, where I absolutely, utterly hated this pattern:
* I did not remember the mail address for such a thing because I started (too late) to use a different mail address for every service, thanks to Apples iCloud hidden addresses. And because there was no corresponding password, there was no entry in my password manager. I since rectified that, but it’s annoying.
* I tried to login on an older Windows PC - the magic mail landed on my iPhone. And because cross-system technical standards are a thing of the past the only possibility to get the magic link to the other system was to transcribe it.
> Email + magic link is a pattern I keep seeing that's far more secure in practice.
I absolutely despise this. Every time I want to quickly log into an app and check something, just to sit in front of my synchronising mail client, wondering if the email will arrive, be caught by the spam filter, or just have random delay of a few minutes. Awful.
If the authentication session is long-lived then this is usually not too onerous; one round trip the first time you use it.
It’s a nightmare if they also insist on short lived sessions.
I hate it too. I always prefer TOTP. I never said this isn't shitty. Just that for normal users, it's more secure than passwords.
I first saw this with Anthropic. I clear my browser pretty regularly and this flow just adds so much friction. With a password manager plus totp I never really felt burdened by logging in every time I used a service. I hope this doesn't catch on.
> nothing beats the security and privacy of username + password + TOTP (or security key)
security key is at least somewhat better than TOTP because it's not (or less-)phishable
The ways this is currently implemented are often terrible, but not always. I'll give an example: I recently did a stint at "Green company" and they gave me a yubi key. They also used Microsoft for most things. To login with Microsoft authenticator I type in my username and password, click yes on the next page, and then click yes on my phone. But to use the yubi key was needlessly frustrating. First, Microsoft doesn't let you use it as the default method (hardware key). So then you have to click "use another form of authentication", "hardware key", "next" (why? Idk), and then finally you pin and tap the key. A bunch of needless steps there and I'm not convinced this wasn't intentional. There's other services I've used working at other places where it's clean and easy: username + password, then pin+ tap key (i.e. hardware key is default!).
I seriously think a lot of security issues come down to UX. There's an old joke about PGP
It was a joke about the terrible UX. That it was so frustrating that this outcome was considered normal. But hey, we actually have that solved now. Your Gmail emails are encrypted. You have services like Whatsapp and Signal that are E2EE. What was the magic sauce? UI & UX. They are what make the tools available to the masses, otherwise it's just for the nerds.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.
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.
Your keys are in your password manager of choice, you can create one per service+manager (eg. your google account can have one passkey using iCloud Keychain, and another one using bitwarden). If you lose access to your PM, the other recovery processes would take place.
It might help your mental model to think about them as identical to hardware security keys. Except now you don't need to buy a specific hardware key, your password manager is it. You can also just use your hardware key as your passkey, same thing (as long as the key supports FIDO2).
Specifically for your question on what happens if you lose face/fingerprint sensor. So this would be assuming you use Android/iOS's password managers, in that case even with biometrics failing you can just use the code you set on your device as both have fallbacks.
Why did we need a new standard for this, exactly?
Couldn't we just make password managers pretend that they're a Jubikey or similar?
Is it that Jubikeys don't offer any extra (master password / biometric) authn, and hence are only suitable as a second factor, where password managers can be used as both?
Good explanation, IMO.
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.
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