'remember me' using cookies

I’m about to implement this, and I’m thinking of storing the user’s id
and
their hashed password in the cookie after a successful authentication.

can any see an obvious security issue with this? I know the method is
vulnerable to cookie theft but am i missing anything?

thanks
alan

On 7/27/06, Alan B. [email protected] wrote:

The only reason I could see for storing this information is to
automatically
log in the user based on the cookie credentials. IMHO, this is a
definite
security issue and I wouldn’t go with this approach and therefore
wouldn’t
expose this information.

Just my 2 cents.

On Thursday 27 July 2006 12:45, Alan B. wrote:

I’m about to implement this, and I’m thinking of storing the user’s id
and their hashed password in the cookie after a successful
authentication.

If you store their hashed password in there, I guess that means that it
it
spoosible to authenticate to your site knowing only the
username+passwordhash?

That renders the entire idea of hashing passwords ad absurdum :wink:

The usual solution would be to simply use sessions. By default with
session cookies (destroyed when the browser is closed) and optionally
(“remember me”) with long expiry times (14 days?)

Still not really secure, but (a) it’s (also) optional, so the users can
be
blamed if something goes wrong g, and (b) session IDs change more
often
than passwords.

On 7/27/06, Alan B. [email protected] wrote:

I’m about to implement this, and I’m thinking of storing the user’s id and
their hashed password in the cookie after a successful authentication.

can any see an obvious security issue with this? I know the method is
vulnerable to cookie theft but am i missing anything?

Don’t include the password in any form, just as a precaution.

And add a timestamp, you really don’t want such a cookie to be valid
forever.

Isak

I was actually googling for persistent logins just last night!

these links will redierct you to some pages on persistent logins i found
useful…

http://ebtag.com/110
http://ebtag.com/111

ebtag was my brother and my RailsDay entry :]

[email protected]
Gustav P.
itsdEx.com

I was actually googling for persistent logins just last night!

these links will redirect you to some pages on persistent logins i found
useful…
espescially /110. uses the database to store links to cookies etc. looks
really cool!

http://ebtag.com/110
http://ebtag.com/111

ebtag was my brother and my RailsDay entry :]

[email protected]
Gustav P.
itsdEx.com

Alan B. wrote:

I’m about to implement this, and I’m thinking of storing the user’s id
and
their hashed password in the cookie after a successful authentication.

can any see an obvious security issue with this? I know the method is
vulnerable to cookie theft but am i missing anything?

For my site, I implemented rememberMe by creating a cookie with the
user’s id, an md5 signatute for verification, and a timestamp for
expiration. If the cookie is there and the signature matches and the
timestamp hasn’t lapsed I ‘remember’ them.

In my case, its only for the purposes of personalization that I remember
them. If they try to modify their account or anything that could be
destructive, I force them to login for that session with a password. I
avoid storing the password in a cookie (in any form) because I wasn’t
comfortable with it from a security perspective.

I’m assuming most of my users want to be remembered for the sake of
convenience.

Alan B. wrote:

I’m about to implement this, and I’m thinking of storing the user’s id
and
their hashed password in the cookie after a successful authentication.

can any see an obvious security issue with this? I know the method is
vulnerable to cookie theft but am i missing anything?

thanks
alan

Short answer (I’m a security geek): never, but never, store anything
that can be associated with any user in a session cookie, including
password hashes. Only use session identifiers containing a significant
amount of high-quality random bits.

In persistent cookies, the rule is stricter: never, but never, store
anything at all that can be associated with a user, including random
session identifiers.

If you relax this policy in any way (usual justifications are: “my site
doesn’t really have anything confidential on it”) you’re taking the risk
of compromising the integrity of your site (which may indeed be an
acceptable risk) or your users’ identities (which may be a risk whose
acceptability is not entirely yours to decide).

I often work with sites that must be load-balanced across many servers.
In these cases, the obvious difficulty with session identifiers that
contain only randomness is passing them around from one server to
another. Session stickiness is one pretty decent answer to this,
assuming you don’t restart your server processes often. Another answer
is to store sessions in a DBMS, which I don’t like because now your DBMS
and your server-farm’s LAN topology just became scalability constraints.