pilcrowonpaper / copenhagen

A basic guideline on implementing auth for the web

The Copenhagen Book

thecopenhagenbook.com

The Copenhagen Book provides a general guideline on implementing auth in web applications. It is free, open source, and community maintained. It may be opinionated or incomplete at times but we hope this fills a certain void in online resources. We recommend using this alongside the OWASP Cheat Sheet Series.

If you have any suggestions or concerns, consider opening a new issue.

copenhagen's Issues

Update CSRF info in Sessions page's "Client storage" section

Hey, really loving the book! I did notice on section that seemed a bit out of date.

Similar to #12, CSRF can be mitigated on 96%+ of browsers by using a dual cookie method described here.

The current page reads:

CSRF protection must be implemented when using cookies, and using the SameSite flag is not sufficient.
...
Lax should be preferred over Strict for the SameSite attribute as using Strict will cause the browser to not send the session cookie when the user visits your application via an external link.

I suggest updating this to be in line with the changes in #15, and ideally linking citations.

Guide: Cross-site scripting (XSS)

I'm not sure if this should be part of the book since it's more general security rather than auth related

Guide: JWT sessions

Guide: Basic cryptography

• Hash (SHA-1/2/3)
• HMAC
• Private/public key (RSA, ECDSA)

email verification & password reset

You should even mark a user's email address as verified if they reset their password.

This is counter intuitive to me. Why?

Guide: SAML

Unfortunately I've never implemented SAML before

Extra information around SameSite cookies and CSRF

The "Sessions" guide contains the following:

CSRF protection must be implemented when using cookies, and using the SameSite flag is not sufficient.

This is somewhat true, but there is some additional nuance here.

My understanding is that SameSite=Lax (or Strict) is sufficient CSRF protection if the following conditions are met:

• The user's browser supports it. Global support is currently ~96%
• GET requests aren't used to mutate data on the server.
• The website/application doesn't surface user-generated content (such as the ability to post links, forms, etc).

As with anything related to auth, there are plenty of edge-cases (as listed above) but generally I think SameSite=Lax or SameSite=Strict could be recommended as a sufficient method of CSRF protection in certain circumstances.

Interested to hear your thoughts and, if you agree, I'm happy to modify the "SameSite cookie attribute" section of the "CSRF" guide to include this info.

Guide: Rate limiting

Describe and compare different ways to implement rate-limiting

Consider Inference Opportunities

In various journeys of an applications functions it's possible to infer the presence of a identity such as

New user sign up is provided an email that is checked 'that account already exists' <-- this is a point of enumeration
Forgotten Password is often a point of enumeration too altho often a little noisier <-- user doesn't exist versus email sent
Login page also a point of enumeration <-- user does not exist versus incorrect password

Areas like these should either send to the user's provided email address actions to authenticated such as how Spotify's magic link works or send an email suggesting someone has attempted to sign up using this email address if the account doesn't exist yet

where an application cannot do this, it must be aware of the enumeration and scraping potential

Does this make sense ?

I can put something in long form if needed, but in principle, how are re defending from scraping and inference based learning for unauthenticated visitors

Seems like the domain is blocked in the UK

Hi,

I found a link to your website from Lucia Auth, and I thought your website was down at first, but then as soon as I used a VPN (location of Switzerland), it worked immediately. Perhaps there isn't something you can do, but I thought it may be useful to inform you. 😄

translate to different languages

I can translate the book to Arabic, but we need malta to support internationalization first

Language version

Hey man, i follow your work since a while now, i read your copenhagen book few times and i wanted to know if you allow me to rewrite it in french. With the aim of facilitating French-speaking students and extending its impact. I'm a student like you who wants to improve and discover new things.

Thank you.