Authentication

What is it?

TODO: talk about verifying identity by posession, knowledge or. …

Guidelines

The National Institute of Standards and Technology (NIST) develops the technical requirements for US federal agencies that implement identity solutions. It is a widely accepted in Europe as well, and may be worth to check local regulations as well, pending to do. The digital identity guidelines rev 3 and ongoing rev 4 covers this topic in depth.

Digital identity model

A digital identity is the unique representation of a subject engaged in an online transaction of a digital service. This transaction can be f.e. creating notes in a TODO app, requesting holidays, sending a mail, etc. This identity can be bounded to only a digital service f.e. my Github account or to many digital services f.e. when I use to sign in another page with my Github account.

There are two systems of this model:

• Non-federated
• Federated

Non-federated

TODO: there is figure (https://pages.nist.gov/800-63-4/sp800-63.html#fig-1) that can be nice to show but it is too crowded. Maybe I can split in two (or three for federated) and put it in each section.

This in practice is the very common email/password implementation. There is a wide variety of implementations that depends on the level of security required.

The process to reach the identity model is splitted in two steps:

1. Enrollment and identity proofing

This is known as “signup”, a process between a subject and a credential service provider (CSP). The subject with the role as applicant at this stage wants to be identify proofed by a CSP, if the applicant is successfully proofed then its role changes to subscriber.

The CSP takes care of:

• Verify your identity: there are different levels of assurance. Depending on the level, there is no need to provide or verify personal information that can lead a connection between your digital identity and your legal identity.
• Uniquely identifying each subscriber: assigning a unique ID f.e. UUID, username or email.
• Register subscriber credentials: a credential is the binding between authenticator(s) and identity of subscriber. At least one authenticator method is requested with the signup, but more methods can be added later and they will still be attached to the same identity (of course!)

Levels of identity assurance from IAL1 (loose) to IAL3 (strict), we can use this useful diagram from guideline to determine how to choose the right assurance level.

2. Authentication and lifecycle management

This is known as “login”, a process between subject and a verifie. The subject with the role as claimant proves possession and control of the authenticator(s) to the verifier through an authentication process, if the claimant is succesfully authenticated then its role changes to subscriber.

The only purpose of verifier is to verify the authenticator(s).

But what is an authenticator? it is a challenge defined by a factor:

• Something you know (f.e. a password, a PIN)
• Something you have (f.e. an ID badge, a YubiKey, a phone)
• Something you are (f.e. a fingerprint, a facial picture)

Multi-factor vs single-factor, we can set a harder challenge (to make it more secure) if we set a multi-factor authentication (MFA). MFA refers to the use of more than one distinct factor, f.e. a PIN and a password will not be a MFA because both are a “somenthing you know” factor, instead a password (“something you know”) can be combined with a YubiKey (“something you have”).

OWASP is a TODO

https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-general-guidelines

• User IDs : should be case-insensitive and unique.

• Email addresss : should be validated and if possible tested with a mail server.

• Implement proper password stregnth controls:

  • passwords shorter than 8 characters are considered to be weak.
  • set a maximum length due to limitation in certain hashing algorithms and to prevent long password DoS attacks.
  • allow usage of all characters

• Implement secure password recovery mechanism: vulnerabilities: user enumeration attack, sql injection

  • use a side channel to communicate the method to reset their password.
  • implement rate-limiting against useless requests from attacker
  • do not make a change to the account until a valid token is presented.
  • use URL tokens for the simplest and fastest implementation
  • remember to prevent SQL injection and do input validation

• Store passwords using the right crytographic tecnique.

• Compare password hashes using safe functions: function should have a max input password length to prevent DoS with very long password. Return in constant time to protect against timing attacks

• Change password feature: ensure to have user authenticated and verify current password.

• Transmit password only over TLS

• Require re-authentication for sensitive features: before updating sensitive account information such as user’s email or password, sensitive transaction, shipping address, to mitigate CSRF, XSS attack and session hijacking.

Do it yourself?

Authentication can be solved with a email/password system. I was starting my first draft of signup and login flow. Of course this is just a way of multiple ways:

• Signup flow: the input is email and password.

1. Validate password policy: min number characters, contain symbols, etc.
2. Backend will hash the password and store email and hashed password in a table.
3. See best practices hashing (write about hashing + salting)
4. From here you can force a verification mail where backend send a verification message with a code/link to the email registered, the code/link will be used by the owner of mail to confirm email’s posession. This enforcement is to protect DoS signup where fake emails are being registered only to saturate capacity of api and storage.

• Login flow: the input is email and password.

1. Get user by email
2. Compared email with hashed password
3. Return a token (session or JWT) back to user. The token will have an expiration. After which user is forced to only refresh token or relogin.

Then,I realize that this can go deeper and deeper.

• New device login: a security step to confirm new login comes from legit user. I will probably have a device info characteristic(s) and set email’s verification when new device has been used to login.

• Password reset: I need to create a one time random token and emailed it to user, I need to make sure to invalidate previous sessions/tokens that did not expire yet.

• Login attempts: set a max login attempts to avoid hackers guessing passwords.

• Multi-factor authentication: an extra layer of security.

• What about other types of login like single sign-on(SSO) that is widely used in companies.