[HN Gopher] The Copenhagen Book: general guideline on implementi...
___________________________________________________________________
The Copenhagen Book: general guideline on implementing auth in web
applications
Author : sebnun
Score : 190 points
Date : 2024-10-10 18:37 UTC (4 hours ago)
(HTM) web link (thecopenhagenbook.com)
(TXT) w3m dump (thecopenhagenbook.com)
| fuddle wrote:
| This is a great guide, thanks.
| apitman wrote:
| 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
| canadiantim wrote:
| 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
| tommica wrote:
| > 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.
| LoganDark wrote:
| 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).
| tommica wrote:
| 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.
| simonw wrote:
| "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.
| stickfigure wrote:
| > 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.
| philsnow wrote:
| 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.
| 9dev wrote:
| > 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.
| LoganDark wrote:
| 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.
| jonjojojon wrote:
| 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.
| efitz wrote:
| 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.
| godelski wrote:
| > 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.
| philsnow wrote:
| > 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
| jenny91 wrote:
| 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.
| swatcoder wrote:
| 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.
| godelski wrote:
| 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.
| efitz wrote:
| > 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.
| dahousecat wrote:
| In 10 years time everyone will be using passkeys, not
| passwords.
| bzmrgonz wrote:
| 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??}).
| philsnow wrote:
| Can you imagine a world where instead of sites prohibiting
| pasting into password fields, they prohibit hunt-and-pecking
| passwords? It's beautiful.
| wg0 wrote:
| 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.
| lovethevoid wrote:
| 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.
| jms703 wrote:
| Good explanation, IMO.
| dahousecat wrote:
| You need the password for the lost passkey flow. Well, you
| don't need it, but it's an extra layer.
| awestroke wrote:
| What's with the name?
| efitz wrote:
| 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.
| dahousecat wrote:
| They discuss session tokens, passwords and webAuthn so both.
| crabmusket wrote:
| All of those things are authentication, not authorisation.
| https://www.okta.com/identity-101/authentication-vs-
| authoriz...
| marcosdumay wrote:
| The first two are both authn. Is webAuthn about authz? (I
| don't doubt it.)
| skrebbel wrote:
| 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).
| zoogeny wrote:
| 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.
| kmoser wrote:
| I would have liked to see a section on SAML and a high-level
| overview of how to implement it.
| slieschke wrote:
| There's an issue tracking that at
| https://github.com/pilcrowOnPaper/copenhagen/issues/3
| grinich wrote:
| we at workos wrote about it here:
| https://workos.com/blog/the-developers-guide-to-sso
| ozuly wrote:
| 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/
| swyx wrote:
| > 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.
| ozuly wrote:
| 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
| TechDebtDevin wrote:
| Been rolling my own auth today for luls. Thanks for this :)
| sgarland wrote:
| 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.
| simonw wrote:
| Anyone know why it's called the Copenhagen Book?
| playingalong wrote:
| 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.
| renewiltord wrote:
| 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.
| beginnings wrote:
| you only need to roll your own auth once and you can drop it in
| anywhere
| palistine wrote:
| free palisten
| RadiozRadioz wrote:
| 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.
| lovethevoid wrote:
| 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.
___________________________________________________________________
(page generated 2024-10-10 23:00 UTC)