Security notes / Kinds of auth setup

Security related stuff. Linux - PAM notes · SELinux Securing services Public key encryption; SSL and TLS SSH: tunnels, X forwarding · keypair logins · SSH jails · loose notes · agent Apache config and .htaccess - security A little more practical security for the everyday person not-so-formal notes Ingredients that might be useful to know - MFA / 2FA · One-Time Passwords; also, authenticators 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 · encrypted connections pre-boot authentication 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 multi-factor authentication

See Security notes / Multi-Factor Authentication