[ale] POST from HTML email

[Mike Harrison]

On Thu, 27 Jan 2011, Michael B. Trausch wrote:

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

In practice, I use both, both valid auth and a cookie (set during
a specific login sequence) are required. Deleting or expired cookie
invalidates the auth and they must re-login.

> 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

Yeah.. we even add in client certificates from a private CA in places 
where we can.. but that's only 1 out of 3 install average. The IT
departments don't want to deal with the hassle of the client certificates.
Aack. In one place the ISA firewall (old proxy style) freaks on them and I 
can't get them to upgrade their firewall. The real/default M$-IT world 
sucks.


Pretty good list below, I make em "simple auth and cookie check for every 
page load.." and my cookie magic is not quite as convoluted, but I agree
with your list as valid good practices.



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

-- 
Mike Harrison   bogon at geeklabs.com - heavily filtered public address
423-605-6943    http://geeklabs.com