Security notes / Kinds of auth setup
Security related stuff.
Securing services
Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted |
Delegated authentication / delegated access
Federated identity, Single Sign On
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