Security notes / Identification, authentication, authorization

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

Hashing notes · Message signing notes · Key Derivation Functions

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

(temporarily elsewhere)

Bearer tokens

WWW-Authenticate

HTTP Basic Auth notes

✎ 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.

HTTP Basic auth is Base64-ing of username:password

Interaction-wise

When you do a regular request, a server can respond with 401 ('Authorization Required') to signal HTTP-based auth is needed, and signals using Basic auth by adding a response header like:

WWW-Authenticate: Basic realm="Friendly name of area you are authenticating"

...and for which the body is usually a very minimal HTML document telling you that you are unauthorized -- which most browsers will only show if you fail or refuse the following: Most browsers will pop up a dialog for login (mentioning the realm name), and automatically do a HTTP request on the same URL with this authentication attempt in it.

That second (and successive) requests will include an Authorization header, like:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

...which is the Base64 encoding of plain text, here of Aladdin:open sesame, a colon-separated username and password.

There is not really a means of logout, no HTTP signaling for it.

Upside:

means people have to enter something valid to enter

Downside:

sends passwords in what amounts to plain text (as base64 is reversible trivially, and by design)

No protection against CSRF

This is not secure

When this is sent over anything unencrypted, anyone with the ability to sniff traffic can read out the password.

Over HTTP, this was a bad thing to do.

Now that HTTPS is the default (...mostly...) this is much less of an issue, but you must never accidentally disable that, and it's a separately configured thing.

Just... don't use it. If you need something basic, even Digest is steps better.

HTTP Digest Auth notes

✎ 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.

Originally described by RFC 2069, replaced by RFC 2617 which also describes a somewhat stronger variant (that can be backwards compatible with 2069).

Once you understand Basic auth, you can consider this a variant that

sends a hash instead
also includes uses a client-generated nonce (lessens replay attacks, some pre-image attacks)

It's not ideal, but it's already much better than Basic auth.

The headers and exchange is similar to Basic, though exactly how the exchange should work depends on the 'qop' (quality of protection, which can be missing, 'auth', or 'auth-int'), which is part of why implementation of both sides is more involved than Basic -- and you'll probably want a library, or web server, handling this for you.

Exactly how the exchange should go seems to depend on two variables of the exchange (see qop), but it'll be be some variation on the theme of:

HA1 = MD5( username + ':' + password  )
HA2 = MD5( method   + ':' + digestURI )
response = MD5( HA1 + ':' + nonce + ':' + HA2  )

Security

Two rounds of MD5 including a client nonce is a solid few steps better than Basic auth, in that it should help against chosen plaintext attacks and some optimizations, and some replay attacks (...in that a server can more easily do certain checks - it's not guaranteed that it will).

Still vulnerable against man-in-the-middle, CSRF, and more.