I'm considering to implement the classic 'remember-me' checkbox on my webapp to allow the authenticated user to be 'remembered' once he returns to visit my website.
Gmail, Facebook and others have this kind of feature but I'm not too sure how secure it can be.
A Java Framework like Spring Security uses an 'Hash-Based Token Approach'. The token that gets generated (using username,password,expirationTime and a privateKey) is stored in the Client's Cookies 'token=567whatever567'. The token is then reused to re-authenticate the user the next time he comes back.
I'm concerned of the fact that even if the login process happened under a https connection, on every subsequent http request the cookie will be sent unencrypted on the net.
Basically everybody can read the token and reuse it to authenticate.
I'm trying to have a look at how Gmail or Facebook are implementing this functionality. I can see some Cookie like 'presence=DJ267619445G09H0L15228675.....' in FB, others in Gmail.
I'm not too sure if they use some other trick to protect against someone that tries to impersonate some other user.
I'll try to impersonate myself using something like cURL to see if they're only using a specific token to remember the user.
If they are it looks to me like a big security issue. Maybe not facebook(I don't care of it) but with Gmail if you don't set 'Use always https' an http connection will be used and it will send your unencrypted tokens over internet.
What do you think?
I've also noticed that Facebook username/password fields are exposed under http (not https). In this regard I'm also wondering : Are all the websites exposing username/password field over http unsecure 'by nature'. Once the request is sent over http there's no 'redirect to https' that can fix the 'credentials visible to the world' problem.
Thanks
Edit:
My worries were well founded http://codebutler.com/
Thanks to the Firesheep creators for highlighting the problem!!!
It's not such a problem to implement a remember-me. What you need to do is to keep the session alive for long (and set the cookie to last long). Even Gmail will log you out after certain period (I think it's two weeks or a month). However, you need to realize that keeping the same session open longer increases the possibility to hijack into it. As a countermeasure, you need to increase the strength of your session identifier. Session identifier is the one that is in the cookie (or in the URI as commonly seen in some software as "file.php?PHPSESSID=1234...").
The key is to maintain a strong session identifier. For example, in Gmail, you have a cookie GX with a value similar to
DQAAAJoAAAA8mnjaAwgkS7y8Ws5MYCl-PAQLp9ZpMXpGKR47z4L9mlBH-4qEyApAtFbnLkzv1pPqxua1hOWMGiKYpBZr-h7Icyb-NUUg2ZW_nUFIymvw9KjmjSECYTowbCsDerkAxCzSDa83b5YC1mykPv1a9ji4znt6Fsna-AKgNTntvmUxeJ92ctsSlg9iGySEmXnisVyyJiQvI8jzbZqSpE_N2RKZ
The reason why Session Hijacking is pretty much impossible is, because the session identifier is so strong, and because the site utilizes HTTPS everywhere. No one can guess or otherwise get your session identifier (thus can't hijack into your session). On a quick look, the session identifier above seems to have somewhat ~1250-bits of strength, 1*10^376 different possibilities. No one can guess that.
Obviously there will be always potential ways to still hijack into the session. For example, XSS vulnerabilities open the door way to get your cookies and therefore your session identifier, but this isn't your sessions fault in any way, and has nothing to do with a "remember-me".
I'm concerned of the fact that even if the login process happened under a https connection, on every subsequent http request the cookie will be sent unencrypted on the net.
If you set the cookie secure flag to true while in HTTPS, the cookie will never be sent when accessing the site via HTTP. It is a must to do for HTTPS-only sites.
In general, people seem to only use HTTPS for the log-in page, which is wrong. If one really cares, he should use HTTPS all over the page. Otherwise, it's impossible to prevent all Session Hijacking attempts.
Why do many still use HTTPS just for the log-in part? Probably because they don't realize what's in the stakes, or because it's too CPU heavy to use HTTPS everywhere. However, it's still better to use HTTPS for the log-in than not to use it anywhere - because it encrypts the credentials (thus only the session identifier can be stolen later on, not the actual credentials during log-on).
Maybe not facebook(I don't care of it) but with Gmail if you don't set 'Use always https' an http connection will be used and it will send your unencrypted tokens over internet. What do you think?
I think the value should default to HTTPS in all cases if possible. The only real reason as to why not use HTTPS is money (=performance/hardware).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With