views:

216

answers:

5

Most web sites you can log on to also provide the feature so it remembers you between sessions. What's the accepted and secure techniques for implementing that ? (What do you put in the cookies and how do you handle it on the server/db?)

A: 

It's just a cookie with a long life value assigned. However it will only work so long as the cookie exists. For example, I have my Firefox set to clear my cookies when I close the browser. So this wouldn't work for me.

IllusivePro
Well, I'm assuming you do something a bit more clever than stuff the say, hex encoded, username in a persistent cookie .. ?
nos
A user id in one cookie and then an encrypted password would work. I wouldn't store a username as they are typically known to other users of the website and therefore easy to recreate. Although you could encrypt the username and use the password as a key which is a lot more secure.
IllusivePro
Put a session ID or some unique hash in the cookie. Store it server side. Whent he user returns you can look him up in the DB.
Antony Carthy
@IllusivePro Never put a password in a cookie, encrypted, hashed or otherwise.
Cheekysoft
A: 

Cookies, but the user can decide to delete it.

In the same spirit there is some kind of solution, using Flash. Flash can store informations on the client-side, not a cookie, it's not erased (usually) by the browser. With it, you can remeber which user is asking for pages, but you're stuck using a plugin-using solution, and need to know Flash..

I don't see any other solutions.

Clement Herreman
+2  A: 

Signed cookies that can not be tampered with can be a good idea when you don't require a whole server-side state ... lean mean and efficient.

You still run the risk of cookie theft but you can always sign the cookie using IP address, User-agent and other things to help minimize the threat.

Aiden Bell
Hard to counter cookie stealing, as it's to the user to secure his computer :/
Clement Herreman
But you can validate that the cookie hasn't moved to a different environment in some ways.
Aiden Bell
Signing the cookie in some way is important. Otherwise someone can easily copy the cookie value and use it on another machine. Also, this may seem like common sense, but don't store the cookie value as plain text. Encrypt it in some way so it is harder to tamper with. I've seen very novice web designers be too trusting with cookie values.
Dan Herbert
@Dan, I agree. I also think that landing ID's that are trusted as an authentication "they have the ID so they must have signed in" is dangerous. Even alot of session-ID type stuff is dangerous. Encryption, signing and a good deal of automatic distrust are the only ways to go.
Aiden Bell
A: 

Do not try to implement session cookies yourself.

Most web frameworks give you an abstraction over this, leaving you care-free about the many security issues you might be exposing yourself to.

A simple API in pseudo-code in a web framework might look something like this, on login:

authFrwk.loginUser(request.POST.get(username), request.POST.get(password));

This will return a cookie to the client (handled exclusively by the framework).

A securely authorized operation will look something like this:

if (authFrwk.isLoggedOn()) // implicitly checks user session cookie
    doSomethingImportant();
else
    return notLoggedInMsg();

Basically, a session cookie is given a unique ID on the server-side, which a malacious user cannot generate/guess by himself, and which identifies the client as a logged-on user.

Yuval A
+5  A: 

This recent 2009 chapter in Spring Security 3.0 discusses Remember-Me type authentication. The general concepts are not specific to Spring Security so you should be able to benefit from it even if you are not using it. The chapter also cites a Barry Jaspan's 2006 blog posting which is an improvement over the techniques described in Charles Miller's 2004 blog posting.

The blog entry basically comes down to:

  1. When the user successfully logs in with Remember Me checked, a login cookie is issued in addition to the standard session management cookie.
  2. The login cookie contains the user's username, a series identifier, and a token. The series and token are unguessable random numbers from a suitably large space. All three are stored together in a database table.

  3. When a non-logged-in user visits the site and presents a login cookie, the username, series, and token are looked up in the database.

  4. If the triplet is present, the user is considered authenticated. The used token is removed from the database. A new token is generated, stored in database with the username and the same series identifier, and a new login cookie containing all three is issued to the user.
  5. If the username and series are present but the token does not match, a theft is assumed. The user receives a strongly worded warning and all of the user's remembered sessions are deleted.
  6. If the username and series are not present, the login cookie is ignored.
0sumgain
Those blog posts is indeed interesting
nos