Page 2 of 2
Posted: Sun Oct 08, 2006 8:40 am
by onion2k
Have I missed something? A "remember me" option is trivial. It has nothing to do with anyone's password, and it's as secure as any cookie.
1. User logs in with their credentials (username and password). They tick the 'remember me' option.
2. Your login script generates a hash of something. Doesn't actually matter what it is so long as it's unique and non-guessable.
3. You save that hash string in the users table in the record of the user logging in.
4. You set the same hash string in a cookie on the user's computer and set it to expire in a year.
5. Next time the user comes to your website you get that cookie passed, which you use to search the users table (eg select * from users where autologincookie = '$_COOKIE['autologincookie']'). If a user is found then you log him in as if he'd used his username and password.
There's a security implication because someone with physical access to the computer can login with the password, but the convienience to the user is massive. I've no idea at all why people are on about things like encryption in JavaScript. That's totally unnecessary.
Posted: Sun Oct 08, 2006 9:55 am
by Maugrim_The_Reaper
The javascript hashing (not encryption) was a side issue to prevent network sniffing from sidelining a user's plain text credentials for reuse.
Theoraetically, if I sniffed the network and grabbed the user's COOKIE autologin hash - I could use this to access their account bypassing any login attempt until the next time the user logged out and the has was reset. Following from there, one might add a challenge/response system based on your hash as a permanent credential, mixed with a one time random hash as a salt in a secondary hash. It could be implemented once per session say, to boost security. This assumes a lack of SSL which is typical of most open source apps...
Far more secure is periodical logins regardless of any convenience if a remember me feature.
It has nothing to do with anyone's password, and it's as secure as any cookie.
Cookie data is not secure outside of SSL. Unlike a session id, a autologin hash is never reset every session by your process (expiry of one year). It can be reused constantly once its known. Even a session id is subject to the same security as any plain text data transmitted over the wire.
Posted: Sun Oct 08, 2006 10:02 am
by s.dot
Maugrim_The_Reaper wrote:Theoraetically, if I sniffed the network and grabbed the user's COOKIE autologin hash - I could use this to access their account bypassing any login attempt until the next time the user logged out and the has was reset.
Exactly, this was the reason I asked this question. Thanks for clearing that up Maugrim, I don't know if I got my point across well enough in my OP.
One could do JS encryption or C/R all they want.. but doesn't it come down to if the actual cookie set on the users machine gets exposed... one could gain access just by using this cookie?
Posted: Sun Oct 08, 2006 10:13 am
by onion2k
Maugrim_The_Reaper wrote:Unlike a session id, a autologin hash is never reset every session by your process (expiry of one year).
You could always make reset it whenever the user logs in using it. Maybe randomly ask the user their password every few sessions. It depends how you want to balance security and convenience.
Posted: Sun Oct 08, 2006 10:13 am
by Maugrim_The_Reaper
I sort of like to view an autologin hash as something very similar to the PHP session id. Both maintain state, session_id across HTTP requests, autologin hashes across sessions. On that basis, many of the security practices for securing a session_id, preventing session hijacking, etc are also applicable to cookie stored autologin hashes. Not a perfect fit, but close.
but doesn't it come down to if the actual cookie set on the users machine gets exposed
Exactly.

The hash, like the session_id, is only as secure as the storage medium and it transfer method. Preventing access to the storage medium is handled by restricting physical access to the computer, or access to the user's account on that computer. Preventing access to the data while in transfer requires encryption (SSL) or a fallback system (C/R) or some server side restrictions (periodical logins, hash renewal, client browser ID checks, IP Address restriction, etc.).
As an aside, these aren't all off the wall. PHP implements the session_regenerate_id() function, for example. Yahoo! enforces periodical logins. An autologin feature may appear trivial, but it still needs a little consideration on how best to secure it. Sure, one can shrug and note how unlikely or improbable it is that such circumstances occur - but reality is that they do.