[Tutor] mod_python authentication

[Alan Plum]

On Mo, 2009-12-07 at 23:10 -0500, Marc wrote: 
> While I agree with the cookie (as long as it has a short expiration),
> another way to do this is by using expiring tokenization (credentials+ some
> unique data for the transaction) in the URL header (see section 14.8 at
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html).  Tokenization
> substitutes some random string for confidential data (such as credentials).

This is essentially what I said about passing variables in the URL. The
important thing still is information hiding, though: you don't want the
user to have any clue what those variables mean so they can't modify
them too easily. This is also why you should never expose critical
variables (e.g. user ID) to possible modification.

> The payment card industry uses this in the form of an authorization code for
> card transactions.  Add to the data represented by the token some unique
> data (maybe a random number or some data from the last transaction - it
> doesn't matter as the token does not expose the data in any way) for each
> http transaction so you have unique token in each header and you can get an
> essentially stateful session with a method of checking authentication that
> has some spoof protection built in. 

The problem to keep in mind, though, is that your users may be
multi-tabbing, i.e. keeping several pages open at the same time. Don't
ever rely on a linear experience unless you're dealing with something
inherently linear like a survey (though in that case you should probably
try to keep it to one page, possibly updated with JavaScript requests if
the form doesn't look too friendly on one page) or a check-out process.

> Wrap it all in SSL/TLS and then you've
> got something.  Granted, this requires some serious server side work, and is
> probably not a good beginner exercise, but if this level is what you
> need....  I have never coded anything like this in Python, but I can see
> abstractly how it could be done (I'm a novice with Python). If you're bored,
> you can read http://www.shift4.com/pdf/TokenizationWhitePaper.pdf especially
> sec1:7.

I agree that if you're going for high security/safety tokenization can
help, but for most intents and purposes it really isn't necessary. The
idea is to avoid re-submission (especially of counter-intuitively
side-effect non-free actions like GET requests) and make each action
uniquely identifiable, if I understand the method correctly.

This is normally only necessary for things like checkouts (keep track of
the order ID and make sure the customer can't accidentally place an
order twice e.g. by double-clicking the submit button or re-clicking it
if the connection hangs) or form submission that affects the server
state (e.g. posting a message to a forum, sending an e-mail, ...).

SSL/TLS is also usually overkill for most purposes. Certificates
provided by many non-commercial authorities will still trigger security
warnings in most browsers, so the only way to get one that isn't
counter-productive (i.e. diminishes trust rather than increasing it --
dodgy certificates are still valid certificates) is to shell out the big
money -- and unless you're into serious business (i.e. anything big
enough to justify the expenses), you probably can't be arsed.


Cheers,

Alan Plum