Security notes / Kinds of auth setup

From Helpful
Jump to navigation Jump to search

Security related stuff.


Linux - PAM notes · SELinux

Securing services


A little more practical


More techincal waffling

Message signing notes · Hashing notes ·
Auth - Kinds of auth setup · identity and auth notes ·· OAuth notes · OpenID notes Kerberos notes · · SASL notes
Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections

Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted


Local, centralized, or shared authentication

Delegated authentication / delegated access

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Federated identity, Single Sign On

This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.


Ingredients of implementations

Tokens and tickets

Mechanically

Tokens are often used to signify allowing something - often once (forgotten on use), and/or for a limited time (forgotten after a time).

The token itself has no meaning - they are typically completely random values (and not e.g. derived keys).

The meaning comes from the issuer remembering it, for a specific purpose.


Tokens make a lot of sense between systems, in that it leads them to think about fine grained permission systems, and most of their exchanges avoid any secret.


Upsides:

  • if their use is snooped on, their one-time use means they aren't useful again
  • if snooped on, the values don't reveal anything
  • if their issuing is snooped on, they're only useful for a limited time
this is e.g. why password reset links time out after e.g. an hour - it is relatively unlikely someone else gets that information within that time (even with social engineering, etc)


Downsides:

  • if the token is snooped, it might beat the legitimate use in time, though
  • bunches of exchange
  • ...which itself is ideally already non-snoopable by some other means


You can set up token systems between related systems to manage what actions imply what grants to what entities.

For example:

  • login token issued on login (e.g. hours), used purely to signify a user
  • granting token, for a specific action
  • session cookie, automatically issued based on login token (e.g. hour, tops)
some systems use the login token as a session cookie. It doesn't reveal a lot more, but is still lazy.
also, it blurs the terms - cookies are reusable, tokens are not.


When the user tries to access a secured application, the application will check for the presence of a granting token. If found, it will issue a session token. The session token exists for the duration of the user’s session with that application.

If not found, the user is redirected to the login server where they authenticate. Then the user is issued a login token and a granting token and is redirected back to the application which uses the granting token as a basis for trust that the user has been authenticated.




Login tokens represent "this specific user has previously successfully authenticated". (the server end will often also remember "authenticated at DATETIME" and "is valid until DATETIME").

Many systems will reuse this token, making it a session token.

Assuming an attacker steals such a token, they may well be able to act as you being logged in.

Ideally, there are actions that require more than that token, in particular:

  • things that amount to stealing the the account (changing email address, changing password)
  • authorizing external interactions (such as credit card purchases)



XSRF tokens

  • One-use
  • Named because their main purpose is to avoid XSFR attacks





Practical details:

  • forget/revoke after a time limit - both for safety and for manageability of the backing storage
  • forget/revoke after use - whenever that's the point


-->

OTP

MOVED

On authenticators

On passwordless login

Given that passwords have issues, one proposal is to not use user-generated secrets at all.


Most proposals of passwordless actually amount to

a shift away from what you know
and towards what you have.


This does not of course presents a shift in risks, ones that you need to teach your users to not be riskier, but for a lot of localized uses (like businesses) can be pretty convenient.


In fact, you could argue that the main reason this is currently a good idea is only because things that you know are often easier to share than most things that you have.

Sometimes purely because they are harder to pronounce or write down than short things that are easier to remember (a.k.a. passwords).


Passwordless login typically amounts to 1-factor based on either

  • or something you are -- typically biometrics like fingerprints, retinal scans, face or voice recognition
  • something you have
cellular phone
smart card
OTP token or hardware token - any sort of hardware that you need to interact with
control over an account (like sending a token to phone or email)
doing this without anything else has limited value
and doing it with a password is just typical 2FA


In some ways, we have taken password+device 2FA and removed the password. Or left it symbolically in, but don't really count it towards our


A smart card or hardware token are a bad idea to use as a single one factor, because theft of the device basically means theft of the identity in ways that the system can never hope to detect.

(...not that it's much worse than "something you have that knows your password")


This is why the typical suggestion is

  • a modern take on smart cards, like your phone providing a user key
(that preferably is stored in TPM or similar)
ideally with extra factors like a fingerprint check, otherwise it has all the issues of the above two
which is really 2FA with something you have and something you are.


Downsides:

  • each host you need to log into needs extra hardware and integration.
...or imply that you're only partially passwordless
  • if your phone is stolen, you cannot log in at all in the meantime, and re-registering may be a pain

On biometrics

On multi-factor authentication

See Security notes / Multi-Factor Authentication

On TPM auth

On one-time passwords

Software/phone authenticators

Hardware authenticators

Yubikey