Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> On Mon, 11 Oct 1999, Ofer Inbar wrote:
>
> > Eugene Sotirescu <[EMAIL PROTECTED]> wrote:
> [...snipped...]
> >
> > When a browser session comes in without appropriate authentication
> > cookies, they get a login screen. When they post username and
> > password, check that against the locally stored user table, and if
> > they match, issue a set of authentication cookies. These hold three
> > pieces of information:
> > - the username
> > - the date-time (seconds since epoch) these cookies were issued
> > - an MD5 hash
> >
> > The hash is of: username, per-user secret, application secret,
> > application's version number, IP address of browser session, and
> > time cookies were issued.
> >
> [...lots more snipped...]
>
> I am curious because I've seen this sort of statement a couple times.
>
> Wouldn't passing the username and time of the cookie issuance weaken the
> MD5 hash since you would be giving a perpetrator more information to
> create the MD5 hash themselves? It seems to me that at the very least,
> don't pass the time to the user because that doesn't add value to the
> client side.
Including the time and username in a readable form is necessary,
because without it, there's no way for the web application to *read*
those values when the user accesses the site again and sends in the
cookies. If all you can read is a hash, how do you know who they're
trying to authenticate *as*? Read every user out of the database and
try them all one by one? But if you're not given the time, you can't
even try that brute force strategy, unless you repeat it for every
possible (or likely) time the hash might have been encoded with. You
need to be able to read the user to know who they're claiming to be,
and you need the time to know whether their cookie set is expired or
not, and you need to know *both* in order to test the hash at all.
Now, by the avalanche property of MD5, every single bit of the input
should have a 50% chance of affecting each bit in the resulting hash.
So, letting the user know some of those bits shouldn't help them be
able to break the hash, as long as the stuff they *don't* know is hard
enough to break.
So, of course, the security of this hash is not based on the user not
being able to figure out their own username and the time they got the
cookies, and their IP address. Heck, they could figure all that stuff
out whether they were handed it in a cookie or not. The security is
based on the fact that they can't guess their per-user secret and the
application's global secret. If you want to, you can also add some
other semi-random possibly hard to guess value to the mix, perhaps
your process ID (which by itself is somewhat guessable, but does add a
bit more uncertainty when combined with the secrets).
The reason all that other information (username, time, IP), that the
user does know or can figure out, is in the hash, is to ensure that
they cannot change it. Otherwise, they could log in as one user, then
come back with a perfectly valid hash but pretending to be some other
user, and get that other user's privileges. Or, they could keep
coming back with the current time, so their hash never expired. But
if those values are included in the hash, and the user changes them,
unless they can guess the secrets and come up with a new hash, their
cookie set is no longer valid.
-- Cos (Ofer Inbar) -- [EMAIL PROTECTED] http://www.leftbank.com/CosWeb/
-- WBRS (100.1 FM) -- [EMAIL PROTECTED] http://www.wbrs.org/
A cos is an abstraction for a stream or datagram channel, used in BSD
and BSD derivatives. -- Ben Tober <[EMAIL PROTECTED]>
