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 allow something once, or to allow something for a limited time.
Tokens are
- system-issued shared secrets
- known by only the endpoints that need to know
- typically completely random values (not e.g. derived keys)
- often time limited - the issuer forgets it after a time reasonable for the the mechanism it's being used in.
- often single use
The token values themselves have no meaning. The meaning comes from the issuer remembering it, for a specific purpose.
Upsides:
- if their use is snooped on, their one-time use means they aren't useful again
- 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 minutes to an hour - it is relatively unlikely someone else gets that information within that time (even with social engineering, etc)
- if are snooped on at any point, the values don't reveal anything
Downsides:
- 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 specific
- 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.
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.
Ticket granting ticket http://en.wikipedia.org/wiki/TGT
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.
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