NYCPHP Meetup

[Paul A Houle]

Michael B Allen wrote:

> Otherwise, you wouldn't need to use
> cookies at all - you could just store the authenticator in the HTTP
> session on the server. From a security perspective, cookies can be
> sniffed just like session ids so there's not a great benefit there.
> But the paper also has a section that says "do not use persistent
> cookies" since another user on the system could copy the cookie and
> gain access to your account but that would completely defeat the
> purpose of using cookie authenticators as it would be easier to simply
> use a server side authenticator.
>
>   
    Four things.

     (1) The server has to give the browser something to connect the 
browser to a particular server side session.  This either going to be a 
cookie or it's going to be a token in the URL or maybe it's going to be 
private data in a flash or silverlight app. 

    (2) Server-side sessions have all sorts of problems.  The details 
depend on your language,  but there's always a devil in them.  For 
instance,  there's a global lock on PHP sessions that hurts the 
scalability of PHP apps that use sessions.  ASP.NET,  on the other 
hand,  dumps the session jar on the floor whenever the server has a 
glitch or when the .NET assemblies from the sites are reloaded.  This is 
why imeem.com logs me out two to three times a day:  it's fair to say 
that I think about joining another music site every time that that happens.

    (3) Server-side session mechanisms are also bound to a particular 
environment:  in the real world,  organizations often need to work with 
multiple languages:  it's quite possible to use signed cookies to 
authenticate against applications in PHP,  Java,  Perl,  Ruby,  Cold 
Fusion and ASP.NET.  (I've done it)  A decent implementation is about 
100 lines of code.

    (4) Signed cookies scale,  since you don't need to look at a 
database to validate them.

> It seems to me, if you want persistent authentication, cookie
> authenticators must persist. And the only real benefit they provider
> in terms of security is that session ids can be leaked in URLs whereas
> cookies cannot (minus browser bugs that allow stealing cookies).
>
> Are client side cookie authenticators really more *secure* than server
> side session authenticators? Or do cookie authenticators actually
> reduce security but are used anyway because persistent authentication
> is a required user experience feature?
>   
   You have to look at the details.  The signed cookie system described 
in that paper can be analyzed on it's own.  A security analysis of a 
system based on say PHP or ASP.NET sessions requires an analysis of the 
session mechanism.  A one-line code change in the session system in a 
future version of your platform could break the security of the system 
without you even noticing it.  Systems that put a token in the URL can 
be manipulated:

http://en.wikipedia.org/wiki/Session_fixation

    Since mainstream server-based sessions are passing some token in the 
clear,  sessions can be stolen by packet sniffing.  You can certainly 
use some cryptography powered by Javascript or Silverlight or something 
to defeat certain packet sniffing attacks,  but public key methods need 
some kind of trusted authority to defend against man-in-the-middle 
attacks.  That's what SSL certificates should provide -- and you should 
be using SSL if this is a concern.

------------

    Another issue that you're talking about is the "remember me" option 
that we see on a lot of public facing sites.  Amazon.com is a good 
example,  because they support different kinds of activities:  (i) 
community and (ii) commerce.  Community sites really need "remember me" 
to be viable.  If I had to log into facebook every time I got an e-mail 
saying that a friend tagged a photo of me,  I wouldn't do it.  Amazon 
lets you use the low-security functions of the site with a remembered 
token,  but forces you to type your password to do anything that's 
security sensitive.

    "Remember me" is generally done by generating a random token in the 
database,  putting it in a cookie,  and checking the cookie against a 
database -- if there is a match,  you create a cryptographically signed 
session.  The database lookup is required because you need the ability 
to revoke a token when a user wants to "log out".