[ale] POST from HTML email

Michael B. Trausch mike at trausch.us
Thu Jan 27 11:24:08 EST 2011


On Thu, 2011-01-27 at 04:28 -0500, Mike Harrison wrote:
> I sometimes feel I'm the last person in the world using simple/digest auth 
> methods..

Maybe not the last person in the world, but I certainly don't use those
methods of authentication.  I'll tell you why:  You do not have nearly
as much control of them as you do an authentication token.  Sadly,
however, most people don't get authentication tokens correct, either
(most don't even try).

Basic or digest authentication requires some browser-specific trickery
to force a logout, and session timeouts don't work.  Such sessions are
for the lifetime of the browser process.  That's perfectly okay if you
are in a situation where you can safely make the assumption that all of
the workstations are perfectly secure.  However, I have found that such
an assumption cannot be made even in a corporate environment.  Any time
someone has physical access to the computer, all bets are off.  Any time
someone is expecting even a locked-down Windows box to be secure, all
bets are off.

This is why I don't use such methods of authentication, because I care
about preventing illegitimate access to systems.  Instead, I will
describe how I perform access control (and I welcome any feedback that
says "I am doing it wrong" if and only if it also comes with a
suggestion for improvement!):

 * HTTPS is required for any application that is not public, and
   all public applications that contain or collect sensitive data.

 * A valid set of credentials is required to access any page in
   said application.  Credentials are defined as one of: "valid
   username and password" or "authentication token".  Valid usernames
   and passwords are provided by a login form.  Authentication tokens
   are provided using HTTP cookies.

 * The authentication token is, as far as the client is concerned,
   an opaque blob.  It is encrypted.  The encryption key is derived
   from a salted version of the user's salted password, further salted
   with a random 8-octet salt stored in their DB record.  The token
   contains a lifetime.  And the token contains a checksum.  If any of
   these things are off, particularly, if the checksum does not match,
   or the session does not match, the token is invalid and
   re-authentication from the user is required.

 * The session token/identifier in the authentication token is updated
   at every page view.  This prevents against replay attacks.

 * The authentication token _does_ include the user's ID prefixed to
   the encrypted blob.  The user's ID is represented as a hexadecimal
   number, and decoded either to an integer or a UUID, depending on what
   type of identifier the underlying system uses.  I prefer UUIDs,
   for no reason other than they make the splitting and merging of
   databases a lot easier.  This is how the server system is able to
   find (well, actually, re-derive) the key for encryption and
   decryption of the token.

Essentially, the user has to input a username and password, or they have
to have this token which is the proof that the server has acknowledged
their authentication credentials.  The server can optionally cache the
key itself, though it does not have to unless performance is a serious
problem; it can be derived upon every client/server interaction.

The goal is to ensure that clients can never present themselves as
authenticated users without being forced to authenticate.  Assuming no
compromise of the server's database, I *believe* the token is secure
enough for that purpose.  (I won't say that I know for sure, because I
have no ability to logically prove that.)  But I can say that replays
aren't permitted, and that without access to the server's database it's
very difficult (but probably not impossible) to derive the encryption
key for the cookie.  And that's all that's necessary for now.

Also, the token becomes invalidated if a password change is made, or if
the session is deleted server-side.  Thus forcing a re-authentication by
the user.  And, the applications that I manage do not always trust the
token; for example, when the user goes to change their password, they
must first authenticate again.

Ultimately, honestly, I'd like to be using Kerberos + LDAP for
authentication and authorization purposes for Web applications.  But
doing so in a cross-browser, cross-platform manner is exceedingly
difficult (though again, probably not impossible).  I honestly don't
want my applications prompting for usernames or storing passwords at
_all_.  I want that handled by code that has been well-tested and
well-reviewed for as long as possible.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110127/a32be131/attachment.bin 


More information about the Ale mailing list