NYCPHP Meetup

[Paul A Houle]

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.