David Mintz wrote:
Moreover, are you sure you want to rely on cookies for testing whether
a user is authenticated?
Uh, don't Google, Facebook, Yahoo, and most of the other
top-1000 sites use cookies to tell if users are authenticated? When's
the last time you logged onto a public-facing site using http basic?
The trouble with what Michelle is doing is that her cookies are
easily forged. If, for instance, the cookie says
isLoggedInAs: michelle
somebody can try logging in as somebody else by just changing the
text of the cookie. You'd do a little better if you did
usernameAndPassword: michelle:somepasswordIpicked
in that case, you'd need to know somebody's password to forge a
token. Both of these schemes have the problem that somebody with a
packet sniffer or token sniffer could steal tokens. You can make a
system ~resistant~ to that using the methods in the following paper:
http://pdos.csail.mit.edu/papers/webauth:sec10.pdf
(it seems to be the greatest CS paper that nobody has ever read)
Note that I say ~resistant~ because somebody can steal a token,
however, a timeout value built into the cookie means that an attacker
has to act fast. The cookie also contains a session id which can be
invalidated, which also limits the range of the attack.
Packet sniffing attacks on web authentication systems don't seem to be
that common in the wild. If you're worried about them, the right
answer is to use SSL. It can be a pain to get an SSL certificate and
install it, but you'd spend more on engineering time to build a system
that looks secure (but probably isn't,) even if you were hiring
Oompa-Loompas to do your design and coding.
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
