Ken Hornstein writes:
>
> I don't know everything about cookies, so maybe I'm missing something
> obvious - how does this prevent replay attacks? If you're just requesting
> a stored cookie, you don't generate an authenticator.
>
Ah yes, I knew there were some ugly things about cookies, which
I couldn't remember.
You can prevent (or at least discourage) replay attacks by
marking it "secure". "Secure" cookies are only sent over
an https link, never over an ordinary http link (at least in theory),
so only the sender and the server should be able to see the
cookie. Of course, the default https security (40 bit key) isn't all
that wonderful, and you can't specify *how* secure the https link
need be when you mark a cookie secure.
Another scheme to prevent replay attacks would be to keep some
state information on the server, and supply a new cookie each
time an authenticated request is made, and reject cookies
with "old" state information. It's not really elegant, but
it would work.
The other two bad things I can think of about cookies are,
how to generate them, and how to get rid of them.
The problem with cookie generation is that you really *don't*
want to do it through the browser. You want to train your users
*NEVER* to supply their password to *any* prompt in the browser,
to avoid the possibility of a rogue web page stealing passwords.
That means, unfortunately, you still need the cooperation of
some other application to generate the cookies.
The other problem with cookies is getting rid of them. The
concern here would be a computer at a shared site (such as
a campus student lab) where a number of people in series use
a machine. Judging by people's behavior when using web browsers
to send mail, people find it very easy to "forget" to reset the
state of the web browser when they start using it. People who get
up and leave a machine are also likely to forget to clear any
state. The result is that there is a good chance the next
user of the machine will silently inherit the credentials
of the previous user. Now, it's tempting to claim it's just
a matter of "user education", but it's still a weakness of
the scheme. There are only two ways I know of that the
user *can* force cookies to be flushed:
(1) quit the browser
(2) select a web page that deletes the cookie.
It's also possible for cookies to be deleted through natural
causes - there is only limited space in the browser. The
space is actually fairly generous, but if web based advertising
really takes off (which seems to be the primary current user
of cookies), then cookie space could become scarce.
"User sensitive" advertising also bothers some users,
who are then tempted to disable cookies. There is reportedly at
least one advertising site that notices what kinds of URL's you
are following through their clients, and customizes the
ads you see. So, if you have followed a bunch of links for
macintosh information, you might start seeing ads for macintosh
games. No doubt somebody is going to get smart & figure out
how to map any accompanying e-mail address into a street address
and send you targetted physical junk mail someday soon.
These problems aren't really the fault of the cookie
protocol, but they are kind of disheartening.
-Marcus Watts
UM ITD PD&D Umich Systems Group
