13 ms·

The Copenhagen Book: general guideline on implementing auth in web applications

750 points by sebnun 2y ago

wetpaws 2y ago
[dead]
deleted 2y ago
[deleted]
fuddle 2y ago
This is a great guide, thanks.
apitman 2y ago
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 2y ago
  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 2y ago
  > 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 2y ago
    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 2y ago
      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 2y ago
        "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 2y ago
        > 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 2y ago
        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.
  - jenny91 2y ago
    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.
    - littlestymaar 2y ago
      I wish I could upvote more than once!
  - miki123211 2y ago
    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.
    - Quothling 2y ago
      > 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.
      - vaylian 2y ago
        After you have logged in, you will get a session cookie/key that you have to send on every request. An adversary can just steal that session key from the compromised connection.
      - mwwaters 2y ago
        https end-to-end encrypts what’s in the address, except for the domain.
    - littlestymaar 2y ago
      And that's also a great way to piss the user off…
    - portaouflop 2y ago
      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.
- swatcoder 2y ago
  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 2y ago
  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.
  - jpc0 2y ago
    You are assuming a lot about who your oAuth provider is... Sure many places only implement Google/Meta/Githun/Discord etc but that's not a requirement, specially for your own app. You can implement and run your own oAuth server if you so wished, much good it would be. But regardless, that's why FIDO2 and webAuthN was developed, but even that has it's issues.
    - godelski 2y ago
      > You are assuming a lot about who your oAuth provider is > Sure many places only implement This doesn't change my concern, but yes, it deepens it. Sure, I known there can be an arbitrary authority, but does it matter when 90% don't allow another authority? I can't think of more than once I have seen another authority listen.
- efitz 2y ago
  > 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 2y ago
    In 10 years time everyone will be using passkeys, not passwords.
    - gomox 2y ago
      Please, for the love of god, no.
    - efitz 2y ago
      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.
    - homebrewer 2y ago
- wg0 2y ago
  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 2y ago
    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 2y ago
      Good explanation, IMO.
    - miki123211 2y ago
      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?
- dahousecat 2y ago
  You need the password for the lost passkey flow. Well, you don't need it, but it's an extra layer.
awestroke 2y ago
What's with the name?
efitz 2y ago
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 2y ago
  They discuss session tokens, passwords and webAuthn so both.
  - crabmusket 2y ago
    All of those things are authentication, not authorisation. https://www.okta.com/identity-101/authentication-vs-authorization/ https://www.okta.com/identity-101/authentication-vs-authoriz...
    - bbor 2y ago
      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 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
      - efitz 2y ago
skrebbel 2y ago
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).
- throw88888 2y ago
  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.
  - skrebbel 2y ago
    I did not make my point well enough. I don't mind that crypto is inscrutable, that's fine (and unavoidable). Plenty other tech that I use every day is inscrutable (eg TCP, or HyperLogLog, or database query planners, or unicode text rendering, etc). I mind that resources about how to use crypto in software applications are often inscrutable, all the way down to library design, for no good reason. I mean stuff like: - I learned the other day here on HN that SHA256 is vulnerable to a length extension attack, so if you want 256 bits of SHA goodness, you should use SHA512 and truncate it to 256 bits. This is terrible naming! Name the bad one "SHA-DoNotUse" if it's broken and this is known from the start. Why does it even exist? - For the first decade or so of JWT library support, many verifiers happily accepted "alg: 'none'" payloads, letting attackers trivially bypass any actual verification. If you wanted JWT safely, you were supposed to know to tell the verifier to only accept the algorithms you were going to use when creating tokens. - Hash algorithms have names such as "MD5", "SHA1", "bcrypt" and "argon2", ie meaningless character soup. I can't blame novice programmers for just using whatever hash algorithm is the default of their language's hash function, resulting in MD5-hashed passwords being super common until about a decade ago. Security resources and libraries for programmers should be focused on how a thing should be used, not on how it works. That's what this book gets right (and what its page on elliptic curves gets so wrong). Or, for another example, my favourite bit of crypto library design is PHP's `password_hash()` function[0]. They added it to the language after the aforementioned decade of MD5-hashed passwords, and that fixed it in one fell swoop. `password_hash()` is great, because it's designed for a purpose, not for some arbitrary set of crypto properties. The purpose is hashing a password. To verify a hashed password, use its brother `password_verify()`. Easy peasy! It's expertly designed, it supports rehashing passwords when necessary, and you don't need to understand any crypto to use it! I don't understand why all other high level programming languages didn't immediately steal this design. I mean why can't all security libraries be like this? Why do most encryption libs have functions named "crypto_aead_chacha20poly1305" instead of "encrypt_message_symmetrically"? Why do they have defaults that encourage you to use them wrong? Why do they have 5 nearly identically named functions/algorithms for a particular purpose but actually you shouldn't use 4 of them and we won't tell you which ones? Do you want GCM or CCM? Or do you prefer that with AEAD? Do you want that with a MAC, and HMAC, or vanilla? Gaah I just want to send a secret! Tell me how to get it right! [0] https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-hash.php
jamesbetts 2y ago
[flagged]
- LargoLasskhyfv 2y ago
  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...)
- dkarras 2y ago
  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.
- bzmrgonz 2y ago
  [flagged]
zoogeny 2y ago
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 2y ago
  I would have liked to see a section on SAML and a high-level overview of how to implement it.
  - slieschke 2y ago
    There's an issue tracking that at https://github.com/pilcrowOnPaper/copenhagen/issues/3 https://github.com/pilcrowOnPaper/copenhagen/issues/3
  - grinich 2y ago
    we at workos wrote about it here: https://workos.com/blog/the-developers-guide-to-sso https://workos.com/blog/the-developers-guide-to-sso
- stult 2y ago
  > 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.
- GoblinSlayer 2y ago
  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.
ozuly 2y ago
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 https://github.com/lucia-auth/lucia [1] https://github.com/lucia-auth/lucia/discussions/1707 https://github.com/lucia-auth/lucia/discussions/1707 [2] https://lucia-next.pages.dev/ https://lucia-next.pages.dev/
- swyx 2y ago
  > 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 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 2y ago
    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://github.com/lucia-auth/lucia/discussions/1707 https://x.com/pilcrowonpaper/status/1843258855280742481 https://x.com/pilcrowonpaper/status/1843258855280742481
  - lovethevoid 2y ago
    What an insanely impressive dude. All that and he just started going to university this year.
    - eastbound 2y ago
      I often wonder what universities brings to students who are already performing in professional life. I’m tempted to ask “So what is he going to teach?” to such stories.
sgarland 2y ago
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.
- GoblinSlayer 2y ago
  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.
  - sgarland 2y ago
    RFC4122 doesn’t require the use of a CSPRNG. From Section 4.4: > Set all the other bits to randomly (or pseudo-randomly) chosen values. Section 4.5, which is actually scoped to UUIDv1, does hint at it being a good idea: > Advice on generating cryptographic-quality random numbers can be found in RFC1750. But absolutely nothing stops you from doing this: import random import string def terrible_prng(k: int) -> int: _int = int("".join(random.choices(string.digits, k=k))) return _int << (128 - _int.bit_length()) def make_uuid_v4(_int: int) -> str: _int &= ~(0xC000 << 48) _int |= 0x8000 << 48 _int &= ~(0xF000 << 64) _int |= 4 << 76 _uuid_hex = "%032x" % _int return "%s-%s-%s-%s-%s" % ( _uuid_hex[:8], _uuid_hex[8:12], _uuid_hex[12:16], _uuid_hex[16:20], _uuid_hex[20:], ) They'll all be RFC4122-compliant (depending on how you interpret "randomly chosen values", since with `k=10`, for example, only the first field will be unique), but terrible, e.g. '83f1a1ea-0000-4000-8000-000000000000'. In fairness, RFC9562, which supersedes RFC4122, says this in Section 6.9: > Implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). And the RFC2119 definition of SHOULD requires that you "[understand and carefully weigh the] full implications before choosing a different course."
simonw 2y ago
Anyone know why it's called the Copenhagen Book?
- playingalong 2y ago
  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.
  - siegers 2y ago
    He said that that he picks the names of the projects by randomly picking locations from a map.
- fleb 2y ago
  Authentication with Danish services tends to rely on MitID ("my ID"): https://www.mitid.dk/en-gb/about-mitid/ 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+mitid 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.audkenni.is/, https://www.samleikin.fo/ https://www.samleikin.fo/. Things are a bit more fragmented in Finland, Norway and Sweden: https://www.norden.org/en/info-norden/electronic-identification-e-id-finland https://www.norden.org/en/info-norden/electronic-identificat..., https://www.norden.org/en/info-norden/electronic-identification-e-id-norway https://www.norden.org/en/info-norden/electronic-identificat..., https://www.norden.org/en/info-norden/electronic-identification-sweden 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/ https://www.mitid.dk/en-gb/broker/broker-certification/
renewiltord 2y ago
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 2y ago
you only need to roll your own auth once and you can drop it in anywhere
palistine 2y ago
[flagged]
RadiozRadioz 2y ago
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 2y ago
  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.
  - RadiozRadioz 2y ago
    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.
- Tubelord 2y ago
  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 https://thecopenhagenbook.com/sessions#session-lifetime
BodyCulture 2y ago
[flagged]
d_burfoot 2y ago
- 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.
- chris_st 2y ago
  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.
  - littlestymaar 2y ago
    Somehow with password managers we collectively decided that single points of failure where good…
    - abenga 2y ago
      All password managers should support downloading and backing up your passwords, right? You can even self host if you want, at least for Bitwarden.
      - littlestymaar 2y ago
        You misunderstood: the risk isn't that the password managers can lose your password, it's that they can be compromised and when they are then all your accounts are compromised at once.
    - chris_st 2y ago
      I definitely see your point, but let's look at what Bitwarden does: 1. Back up my passwords on their server for a fee. Well, that's (alas) hackable, so if someone gets their password they will have everyone's password file. 2. Except each one is encrypted with that user's password, and in my case it's really long. So they'd then have to break each individual one. 3. Except signing in with my password on a new device requires my YubiKey as well, or one of my lost-my-YubiKey tokens, which also only I possess. So I'm not as worried as I probably should be :-)
yazzku 2y ago
Great guide, thank you.
dullcrisp 2y ago
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?
- jeltz 2y ago
  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.
  - TheBigRoomXXL 2y ago
    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
    - GoblinSlayer 2y ago
      Suppose you used the timing attack to recover the hash of a token, now you need to compute a preimage of the hash.
- sieabahlpark 2y ago
  [dead]
- nmadden 2y ago
  Exactly that. (Hijack session rather than account: any competently designed system should require re-auth before any action that would allow permanent account takeover).
dector 2y ago
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 https://thecopenhagenbook.com/sessions#session-lifetime
- Nathanael_M 2y ago
  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.
  - dector 2y ago
    Usually on low-risk projects where I don't want to bother myself with handling token pairs (or where it's impossible) I have similar simplified approach but regenerating token: - Session token has two timepoints: validUntil and renewableUntil. - If now > validUntil && now < renewableUntil - I'm regenerating session token. This way user is not logged out periodically but session token is not staying the same for 5 years. But maybe I'm just overthinking it. :)
    - kevincox 2y ago
      I agree with this. I think all tokens should expire. If you accidentally zip up an auth token in an application's config directory it is nice if it becomes inert after a while. If you extend the token it could live forever. For my application the token is valid for a few months, but we will automatically issue you a new one when you make requests. So the old token will expire eventually. But the client will update the token automatically making your "session" indefinite. So when you throw away a drive that you had sitting in the junk drawer for a year that token is inert. Even if you are using a cloned machine that is still extending the same "session".
ashton314 2y ago
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_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
- GoblinSlayer 2y ago
  Its adoption was hindered by patents.
lifeisstillgood 2y ago
I like it but and I know it’s nit picky- is there a off or other book like thing one can “hold”
jschrf 2y ago
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.
- xixixao 2y ago
  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)
- rank0 2y ago
  > The other thing devs and auth frameworks miss is the "state" parameter. What do you mean?
- raxxorraxor 2y ago
  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.
- Kabukks 2y ago
  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.
- aayjaychan 2y ago
  There is no "one-time" over the network. Invalidating the refresh token immediately when the server recieves it is asking for trouble.
vivzkestrel 2y ago
i see that most examples are implemented in golang, if possible would also request the author to consider adding python and node.js snippets
wg0 2y ago
It doesn't talk about ID tokens and JWT etc with the API only security/use case?
sylware 2y ago
Well, web applications are not web sites, as the latest would support authentification for noscript/basic (x)html browsers.
nh2 2y ago
This is wrong: > Email addresses are case-insensitive. From https://thecopenhagenbook.com/email-verification https://thecopenhagenbook.com/email-verification The email standard says they are case sensitive. If you lowercase emails during send operations, the wrong person may get the email. That's bad for auth. Some (many) popular email providers choose to offer only case-insensitive emails. But a website about general auth should recommend the general case. https://stackoverflow.com/questions/9807909/are-email-addresses-case-sensitive https://stackoverflow.com/questions/9807909/are-email-addres... Side remark: It is not always clear/obvious what's the other case of a given character is, and may change over time. For example, the German capital ß was added in 2008 to Unicode. So it's best to avoid case sensitivity where you can, in general programming.
- tiborsaas 2y ago
  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.
  - eesmith 2y ago
    That still doesn't make it a good idea to normalize to lowercase. Some people are very particular about capitalization. MacAdam is a surname, like the Scottish engineer John Loudon McAdam who invented the road construction known as "macadam". "Sandy.MacAdam@example.com" comes across rather different than "sandy.macadam@example.com". A hypothetical DrAbby@example.com probably would prefer keeping that capitalization over "drabby@example.com". I'm sure there are real-world examples. On a related note, I knew someone with an Irish O'Surname who was very particular that the computer systems support his name. (As https://stackoverflow.com/questions/8527180/can-there-be-an-apostrophe-in-an-email-address https://stackoverflow.com/questions/8527180/can-there-be-an-... puts it, "People do have email addresses with apostrophes. I see them not infrequently, and have had to fix bugs submitted by angry Hibernians.") No doubt some of them also want to see the correct capitalization be used. A possibly better alternative is to recommend that the normalization be used only for internal use, while using the user-specified address for actual email messages, and to at least note some of the well-known issues with normalizing to lower-case.
black_puppydog 2y ago
This looks ver useful if you're about to implement an Auth system. But I thinks it's worth noting that many things can be offered without authentication, i.e. without an account. I think it's worth noting that e.g. e-commerce can be (and in some rare but appreciated cases is) offered in "guest mode". Especially for smaller or more niche shops where return customers are less frequent, it's just good to keep that in mind.
myprotegeai 2y ago
Somewhat related, I have a short rant about embedded browsers killing the web. Embedded browsers make it impossible (literally in some cases, figuratively in others) to use social OAuth. If you click a link on Instagram, which by default opens in Instagram's browser, and that link has "Sign in with Google", it simply will not work, because Google blocks "insecure browsers", which Instagram is one. There are even issues getting "Sign in with Facebook" to work, and Meta owns Instagram and Facebook! The Facebook embedded browser suffers from similar issues.
- pphysch 2y ago
  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.
franciscop 2y ago
I was just reading this and was gonna recommend it to a friend! Saw the announcement from Lucia moving to a resource-based repo and digging deeper saw The Copenhagen Book, which IMHO is the best resource Auth-related I've seen in my 10+ years of career, all very well put together. Two tradeoffs I see is that it is a bit abstract, and also a bit brief/succinct in some places where it just says it as it is and not the why. But neither of those are really negatives on my book, just concessions you have to make when doing a project like this. You can dig deeper in any topic, and nowadays libraries have pretty good practical setups, so as a place where it is all bound together as a single learning resource is AMAZING. I'm even thinking of editing it and printing it!
blocko 2y ago
What is the rationale behind the following? > When comparing password hashes, use constant time comparison instead of ==. If you were comparing plaintext you'd get some info, but it seems overly cautious when comparing salted hashes. Maybe anticipating an unknown vulnerability in the hash function?
Aachen 2y ago
> CSRF protection must be implemented when using cookies, and using the SameSite flag is not sufficient. Also when it's set to strict? Or if it requires a PUT or other method that doesn't work with top-level navigation? Is it about ancient or obscure browsers that didn't/don't implement it (https://caniuse.com/same-site-cookie-attribute https://caniuse.com/same-site-cookie-attribute)?

750 points by sebnun 2y ago

wetpaws 2y ago

[dead]

deleted 2y ago

[deleted]

fuddle 2y ago

This is a great guide, thanks.

apitman 2y ago

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 2y ago
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 2y ago
> 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 2y ago
  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 2y ago
    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 2y ago
      "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 2y ago
        > 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 2y ago
        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.
- jenny91 2y ago
  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.
  - littlestymaar 2y ago
    I wish I could upvote more than once!
- miki123211 2y ago
  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.
  - Quothling 2y ago
    > 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.
    - vaylian 2y ago
      After you have logged in, you will get a session cookie/key that you have to send on every request. An adversary can just steal that session key from the compromised connection.
    - mwwaters 2y ago
      https end-to-end encrypts what’s in the address, except for the domain.
  - littlestymaar 2y ago
    And that's also a great way to piss the user off…
  - portaouflop 2y ago
    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.
swatcoder 2y ago
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 2y ago
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.
- jpc0 2y ago
  You are assuming a lot about who your oAuth provider is... Sure many places only implement Google/Meta/Githun/Discord etc but that's not a requirement, specially for your own app. You can implement and run your own oAuth server if you so wished, much good it would be. But regardless, that's why FIDO2 and webAuthN was developed, but even that has it's issues.
  - godelski 2y ago
    > You are assuming a lot about who your oAuth provider is > Sure many places only implement This doesn't change my concern, but yes, it deepens it. Sure, I known there can be an arbitrary authority, but does it matter when 90% don't allow another authority? I can't think of more than once I have seen another authority listen.
efitz 2y ago
> 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 2y ago
  In 10 years time everyone will be using passkeys, not passwords.
  - gomox 2y ago
    Please, for the love of god, no.
  - efitz 2y ago
    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.
  - homebrewer 2y ago
wg0 2y ago
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 2y ago
  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 2y ago
    Good explanation, IMO.
  - miki123211 2y ago
    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?
dahousecat 2y ago
You need the password for the lost passkey flow. Well, you don't need it, but it's an extra layer.

awestroke 2y ago

What's with the name?

efitz 2y ago

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 2y ago
They discuss session tokens, passwords and webAuthn so both.
- crabmusket 2y ago
  All of those things are authentication, not authorisation. https://www.okta.com/identity-101/authentication-vs-authorization/ https://www.okta.com/identity-101/authentication-vs-authoriz...
  - bbor 2y ago
    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 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
    - efitz 2y ago

skrebbel 2y ago

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).

throw88888 2y ago
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.
- skrebbel 2y ago
  I did not make my point well enough. I don't mind that crypto is inscrutable, that's fine (and unavoidable). Plenty other tech that I use every day is inscrutable (eg TCP, or HyperLogLog, or database query planners, or unicode text rendering, etc). I mind that resources about how to use crypto in software applications are often inscrutable, all the way down to library design, for no good reason. I mean stuff like: - I learned the other day here on HN that SHA256 is vulnerable to a length extension attack, so if you want 256 bits of SHA goodness, you should use SHA512 and truncate it to 256 bits. This is terrible naming! Name the bad one "SHA-DoNotUse" if it's broken and this is known from the start. Why does it even exist? - For the first decade or so of JWT library support, many verifiers happily accepted "alg: 'none'" payloads, letting attackers trivially bypass any actual verification. If you wanted JWT safely, you were supposed to know to tell the verifier to only accept the algorithms you were going to use when creating tokens. - Hash algorithms have names such as "MD5", "SHA1", "bcrypt" and "argon2", ie meaningless character soup. I can't blame novice programmers for just using whatever hash algorithm is the default of their language's hash function, resulting in MD5-hashed passwords being super common until about a decade ago. Security resources and libraries for programmers should be focused on how a thing should be used, not on how it works. That's what this book gets right (and what its page on elliptic curves gets so wrong). Or, for another example, my favourite bit of crypto library design is PHP's `password_hash()` function[0]. They added it to the language after the aforementioned decade of MD5-hashed passwords, and that fixed it in one fell swoop. `password_hash()` is great, because it's designed for a purpose, not for some arbitrary set of crypto properties. The purpose is hashing a password. To verify a hashed password, use its brother `password_verify()`. Easy peasy! It's expertly designed, it supports rehashing passwords when necessary, and you don't need to understand any crypto to use it! I don't understand why all other high level programming languages didn't immediately steal this design. I mean why can't all security libraries be like this? Why do most encryption libs have functions named "crypto_aead_chacha20poly1305" instead of "encrypt_message_symmetrically"? Why do they have defaults that encourage you to use them wrong? Why do they have 5 nearly identically named functions/algorithms for a particular purpose but actually you shouldn't use 4 of them and we won't tell you which ones? Do you want GCM or CCM? Or do you prefer that with AEAD? Do you want that with a MAC, and HMAC, or vanilla? Gaah I just want to send a secret! Tell me how to get it right! [0] https://www.php.net/manual/en/function.password-hash.php https://www.php.net/manual/en/function.password-hash.php

jamesbetts 2y ago

[flagged]

LargoLasskhyfv 2y ago
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...)
dkarras 2y ago
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.
bzmrgonz 2y ago
[flagged]

zoogeny 2y ago

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 2y ago
I would have liked to see a section on SAML and a high-level overview of how to implement it.
- slieschke 2y ago
  There's an issue tracking that at https://github.com/pilcrowOnPaper/copenhagen/issues/3 https://github.com/pilcrowOnPaper/copenhagen/issues/3
- grinich 2y ago
  we at workos wrote about it here: https://workos.com/blog/the-developers-guide-to-sso https://workos.com/blog/the-developers-guide-to-sso
stult 2y ago
> 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.
GoblinSlayer 2y ago
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.

ozuly 2y ago

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 https://github.com/lucia-auth/lucia [1] https://github.com/lucia-auth/lucia/discussions/1707 https://github.com/lucia-auth/lucia/discussions/1707 [2] https://lucia-next.pages.dev/ https://lucia-next.pages.dev/

swyx 2y ago
> 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 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 2y ago
  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://github.com/lucia-auth/lucia/discussions/1707 https://x.com/pilcrowonpaper/status/1843258855280742481 https://x.com/pilcrowonpaper/status/1843258855280742481
- lovethevoid 2y ago
  What an insanely impressive dude. All that and he just started going to university this year.
  - eastbound 2y ago
    I often wonder what universities brings to students who are already performing in professional life. I’m tempted to ask “So what is he going to teach?” to such stories.

sgarland 2y ago

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.

GoblinSlayer 2y ago
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.
- sgarland 2y ago
  RFC4122 doesn’t require the use of a CSPRNG. From Section 4.4: > Set all the other bits to randomly (or pseudo-randomly) chosen values. Section 4.5, which is actually scoped to UUIDv1, does hint at it being a good idea: > Advice on generating cryptographic-quality random numbers can be found in RFC1750. But absolutely nothing stops you from doing this: import random import string def terrible_prng(k: int) -> int: _int = int("".join(random.choices(string.digits, k=k))) return _int << (128 - _int.bit_length()) def make_uuid_v4(_int: int) -> str: _int &= ~(0xC000 << 48) _int |= 0x8000 << 48 _int &= ~(0xF000 << 64) _int |= 4 << 76 _uuid_hex = "%032x" % _int return "%s-%s-%s-%s-%s" % ( _uuid_hex[:8], _uuid_hex[8:12], _uuid_hex[12:16], _uuid_hex[16:20], _uuid_hex[20:], ) They'll all be RFC4122-compliant (depending on how you interpret "randomly chosen values", since with `k=10`, for example, only the first field will be unique), but terrible, e.g. '83f1a1ea-0000-4000-8000-000000000000'. In fairness, RFC9562, which supersedes RFC4122, says this in Section 6.9: > Implementations SHOULD utilize a cryptographically secure pseudorandom number generator (CSPRNG) to provide values that are both difficult to predict ("unguessable") and have a low likelihood of collision ("unique"). And the RFC2119 definition of SHOULD requires that you "[understand and carefully weigh the] full implications before choosing a different course."

simonw 2y ago

Anyone know why it's called the Copenhagen Book?

playingalong 2y ago
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.
- siegers 2y ago
  He said that that he picks the names of the projects by randomly picking locations from a map.
fleb 2y ago
Authentication with Danish services tends to rely on MitID ("my ID"): https://www.mitid.dk/en-gb/about-mitid/ 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+mitid 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.audkenni.is/, https://www.samleikin.fo/ https://www.samleikin.fo/. Things are a bit more fragmented in Finland, Norway and Sweden: https://www.norden.org/en/info-norden/electronic-identification-e-id-finland https://www.norden.org/en/info-norden/electronic-identificat..., https://www.norden.org/en/info-norden/electronic-identification-e-id-norway https://www.norden.org/en/info-norden/electronic-identificat..., https://www.norden.org/en/info-norden/electronic-identification-sweden 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/ https://www.mitid.dk/en-gb/broker/broker-certification/

renewiltord 2y ago

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 2y ago

you only need to roll your own auth once and you can drop it in anywhere

palistine 2y ago

[flagged]

RadiozRadioz 2y ago

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 2y ago
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.
- RadiozRadioz 2y ago
  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.
Tubelord 2y ago
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 https://thecopenhagenbook.com/sessions#session-lifetime

BodyCulture 2y ago

[flagged]

d_burfoot 2y ago

- 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.

chris_st 2y ago
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.
- littlestymaar 2y ago
  Somehow with password managers we collectively decided that single points of failure where good…
  - abenga 2y ago
    All password managers should support downloading and backing up your passwords, right? You can even self host if you want, at least for Bitwarden.
    - littlestymaar 2y ago
      You misunderstood: the risk isn't that the password managers can lose your password, it's that they can be compromised and when they are then all your accounts are compromised at once.
  - chris_st 2y ago
    I definitely see your point, but let's look at what Bitwarden does: 1. Back up my passwords on their server for a fee. Well, that's (alas) hackable, so if someone gets their password they will have everyone's password file. 2. Except each one is encrypted with that user's password, and in my case it's really long. So they'd then have to break each individual one. 3. Except signing in with my password on a new device requires my YubiKey as well, or one of my lost-my-YubiKey tokens, which also only I possess. So I'm not as worried as I probably should be :-)

yazzku 2y ago

Great guide, thank you.

dullcrisp 2y ago

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?

jeltz 2y ago
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.
- TheBigRoomXXL 2y ago
  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
  - GoblinSlayer 2y ago
    Suppose you used the timing attack to recover the hash of a token, now you need to compute a preimage of the hash.
sieabahlpark 2y ago
[dead]
nmadden 2y ago
Exactly that. (Hijack session rather than account: any competently designed system should require re-auth before any action that would allow permanent account takeover).

dector 2y ago

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 https://thecopenhagenbook.com/sessions#session-lifetime

Nathanael_M 2y ago
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.
- dector 2y ago
  Usually on low-risk projects where I don't want to bother myself with handling token pairs (or where it's impossible) I have similar simplified approach but regenerating token: - Session token has two timepoints: validUntil and renewableUntil. - If now > validUntil && now < renewableUntil - I'm regenerating session token. This way user is not logged out periodically but session token is not staying the same for 5 years. But maybe I'm just overthinking it. :)
  - kevincox 2y ago
    I agree with this. I think all tokens should expire. If you accidentally zip up an auth token in an application's config directory it is nice if it becomes inert after a while. If you extend the token it could live forever. For my application the token is valid for a few months, but we will automatically issue you a new one when you make requests. So the old token will expire eventually. But the client will update the token automatically making your "session" indefinite. So when you throw away a drive that you had sitting in the junk drawer for a year that token is inert. Even if you are using a cloned machine that is still extending the same "session".

ashton314 2y ago

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_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

GoblinSlayer 2y ago
Its adoption was hindered by patents.

lifeisstillgood 2y ago

I like it but and I know it’s nit picky- is there a off or other book like thing one can “hold”

jschrf 2y ago

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.

xixixao 2y ago
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)
rank0 2y ago
> The other thing devs and auth frameworks miss is the "state" parameter. What do you mean?
raxxorraxor 2y ago
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.
Kabukks 2y ago
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.
aayjaychan 2y ago
There is no "one-time" over the network. Invalidating the refresh token immediately when the server recieves it is asking for trouble.

vivzkestrel 2y ago

i see that most examples are implemented in golang, if possible would also request the author to consider adding python and node.js snippets

wg0 2y ago

It doesn't talk about ID tokens and JWT etc with the API only security/use case?

sylware 2y ago

Well, web applications are not web sites, as the latest would support authentification for noscript/basic (x)html browsers.

nh2 2y ago

This is wrong: > Email addresses are case-insensitive. From https://thecopenhagenbook.com/email-verification https://thecopenhagenbook.com/email-verification The email standard says they are case sensitive. If you lowercase emails during send operations, the wrong person may get the email. That's bad for auth. Some (many) popular email providers choose to offer only case-insensitive emails. But a website about general auth should recommend the general case. https://stackoverflow.com/questions/9807909/are-email-addresses-case-sensitive https://stackoverflow.com/questions/9807909/are-email-addres... Side remark: It is not always clear/obvious what's the other case of a given character is, and may change over time. For example, the German capital ß was added in 2008 to Unicode. So it's best to avoid case sensitivity where you can, in general programming.

tiborsaas 2y ago
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.
- eesmith 2y ago
  That still doesn't make it a good idea to normalize to lowercase. Some people are very particular about capitalization. MacAdam is a surname, like the Scottish engineer John Loudon McAdam who invented the road construction known as "macadam". "Sandy.MacAdam@example.com" comes across rather different than "sandy.macadam@example.com". A hypothetical DrAbby@example.com probably would prefer keeping that capitalization over "drabby@example.com". I'm sure there are real-world examples. On a related note, I knew someone with an Irish O'Surname who was very particular that the computer systems support his name. (As https://stackoverflow.com/questions/8527180/can-there-be-an-apostrophe-in-an-email-address https://stackoverflow.com/questions/8527180/can-there-be-an-... puts it, "People do have email addresses with apostrophes. I see them not infrequently, and have had to fix bugs submitted by angry Hibernians.") No doubt some of them also want to see the correct capitalization be used. A possibly better alternative is to recommend that the normalization be used only for internal use, while using the user-specified address for actual email messages, and to at least note some of the well-known issues with normalizing to lower-case.

black_puppydog 2y ago

This looks ver useful if you're about to implement an Auth system. But I thinks it's worth noting that many things can be offered without authentication, i.e. without an account. I think it's worth noting that e.g. e-commerce can be (and in some rare but appreciated cases is) offered in "guest mode". Especially for smaller or more niche shops where return customers are less frequent, it's just good to keep that in mind.

myprotegeai 2y ago

Somewhat related, I have a short rant about embedded browsers killing the web. Embedded browsers make it impossible (literally in some cases, figuratively in others) to use social OAuth. If you click a link on Instagram, which by default opens in Instagram's browser, and that link has "Sign in with Google", it simply will not work, because Google blocks "insecure browsers", which Instagram is one. There are even issues getting "Sign in with Facebook" to work, and Meta owns Instagram and Facebook! The Facebook embedded browser suffers from similar issues.

pphysch 2y ago
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.

franciscop 2y ago

I was just reading this and was gonna recommend it to a friend! Saw the announcement from Lucia moving to a resource-based repo and digging deeper saw The Copenhagen Book, which IMHO is the best resource Auth-related I've seen in my 10+ years of career, all very well put together. Two tradeoffs I see is that it is a bit abstract, and also a bit brief/succinct in some places where it just says it as it is and not the why. But neither of those are really negatives on my book, just concessions you have to make when doing a project like this. You can dig deeper in any topic, and nowadays libraries have pretty good practical setups, so as a place where it is all bound together as a single learning resource is AMAZING. I'm even thinking of editing it and printing it!

blocko 2y ago

What is the rationale behind the following? > When comparing password hashes, use constant time comparison instead of ==. If you were comparing plaintext you'd get some info, but it seems overly cautious when comparing salted hashes. Maybe anticipating an unknown vulnerability in the hash function?

Aachen 2y ago

> CSRF protection must be implemented when using cookies, and using the SameSite flag is not sufficient. Also when it's set to strict? Or if it requires a PUT or other method that doesn't work with top-level navigation? Is it about ancient or obscure browsers that didn't/don't implement it (https://caniuse.com/same-site-cookie-attribute https://caniuse.com/same-site-cookie-attribute)?