[OWASP-GUIDE] Persistent Login Cookies

Chris Shiflett shiflett at php.net
Sun Mar 7 16:26:45 EST 2004

--- Charles Miller <cmiller at pastiche.org> wrote:
> A month or so ago, I wrote the following about persistent "remember me" 
> login cookies:
> http://fishbowl.pastiche.org/2004/01/19/
> persistent_login_cookie_best_practice
> I'm interested if anyone here has any comments

You define "persistent login cookies" as:

    Persistent login cookies are the cookies that are stored with your
    browser when you click the “remember me” button on the login form.

It's risky to base a definition on something in the interface like this.
Implementations differ even though the "remember me" presentation is
pretty consistent.

I think this risk is clear a few statements later:

    Persistent login cookies are on their own sufficient authentication
    to access a website. They are the equivalent of both a valid username
    and password rolled into one

This is quite different than most implementation of this "remember me"
feature that I have observed. Yet, you suggest making the interface the
same. For this reason, I think a better definition is needed.

Most implementations use "remember me" to do simply that, remember the
user. It is not implied that this means "remember me and my password", and
I would be upset if a site I used made such a jump.

When a user selects "remember me" on a site such as Yahoo, the behavior of
an active session doesn't change at all (at least in my experience as a
user). The difference is when the session times out, such as whehn you
close the browser and visit again the next day. The persistent cookie that
Yahoo sets only identifies me. The idea is that, between my username and
password, my username is the most trivial piece of data and does not
represent a serious threat. So, they give me the option of having this
cookie, so that I only have to enter my password rather than both my
username and password.

Having a cookie that can actually be used to authenticate a user is
riskier, although some implementations (such as yours) are better than
others. The potential improvement to usability is outweighed by the major
security risk, in my opinion, but at the very least, this type of
implementation should not be presented to the user in the same way. This
type of implementation should be labeled something like "log me in
automatically each time I visit".

That aside, I think the implementation you mention sounds good:

    The cookie should consist of the user’s username, followed by a
    separator character, followed by some large random number (128 bits
    seems mind-bogglingly large enough to be acceptable). The server
    keeps a table of number->username associations, which is looked up
    to verify the validity of the cookie. If the cookie supplies a
    random number and username that are mapped to each other in the
    table, the login is accepted.

At first, this seems like you're describing a session continuation, not a
login. You clear this up later:

    A persistent cookie is good for a single login. When authentication
    is confirmed, the random number used to log in is invalidated and a
    brand new cookie assigned. Standard session-management handles the
    credentials for the life of the session, so the newly assigned
    cookie will not be checked until the next session (at which point
    it, too, will be invalidated after use).

You might want to make this clear earlier and elaborate, possibly with an
example. You really are talking about a login, but that's not clear when
you introduce the method.

So, I basically have two suggestions:

1. Don't refer to this as "remember me".
2. Clarify that the persistent cookie is used for a single login when
there is no active session (such as the next day).

Please don't interpret my criticism to mean that I don't like your
article. I think your implementation is a fine one for this purpose.
Having this cookie capable of only a single login minimizes the risk while
still offering the user a pretty nice convenience: never having to login
again. When playing the role of a technical editor, I tend to only point
out potential problems (always yielding to the author to decide if they
really are problems).

Hope that helps.


Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly
     Coming mid-2004
HTTP Developer's Handbook - Sams
PHP Community Site

More information about the Owasp-guide mailing list