'Remember-me' authentication feature, does

问题:

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!!!

回答1:

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).

回答2:

It's generally called a replay attack. The attacker replays a request using the same credentials (e.g. cookie) that it stole from you, and is able to impersonate you. The XSS attack is just a variation of this, but is preventable (e.g. using HTTPOnly).

The only way to mitigate most replay attacks is https everywhere. That should keep away most of the prying eyes.

There are lots of prevention techniques too.

There are also hardware devices that do a better job than you can hack out in software, slowing down your server in the process, and you'll probably get it wrong. Specialized hardware can do a much better job of tracking requests in realtime and determining that the same token is being used by many different IP's all at the same time, and faster than a single human operator ought to be able to request.

In ASP.NET 2.0+, when using Forms Authentication, you can specify requireSSL='true' to indicate that browsers should only send the authentication cookie when an https connection is made. See this msdn article for more information on securing forms authentication.

---

The only reason not to allow remember me is if you're a banking or similar application. If you're not, just follow a few simple rules:

1. If you have remember me, put an expiry on the cookie at most 30 days in the future and don't slide the value. Forcing the user to login once a month isn't so bad.
2. Any sensitive operations require a password. When updating billing, credit cards, or account details always re-request the users password. The most likely form of abuse is typically via the same computer that the person is using, but it also ensures that even a stolen authentication cookie on it's own can't do too much harm. You can see my balance, but you can't transfer anything.

回答3:

Agree with most comments made above. If you are concerned about security, you should -

a) Use https throughout. Even gmail recently switched to using https by default - see http://gmailblog.blogspot.com/2010/01/default-https-access-for-gmail.html

b) Set the secure flag in your session cookie to prevent the browser from sending it over a http connection.

c) Fix XSS in your application. If you have xss issues, your implementation of 'remember me' is always going to be unsecure. See OWASP XSS Prevention cheat sheet.

Including IP address in the session identifier is NOT going to help. Doing this will make the 'remember me functionality' pretty much useless, and it does not add much security. I know for sure google doesn't put IP addresses in its session identifier.

回答4:

The only way to make totally secure site is to enable https everywhere. You are right, cookies can be sniffed and later used to impersonate.

回答5:

There are a couple ways of preventing session hijacking, such as storing the IP address of the client that opened the session. Additional data must be stored server-side to verify sessions, even without an automatic login feature. It's better to use a nonce for the token (or at least base it on non-secret data) rather than the hashed username & password, as an attacker could conceivably mount an attack to find the authentication information given the hashed value.

If you look at the source for the Facebook, Gmail and probably other sites' login forms, the login form action uses HTTPS, which then redirects to a non-secure page once login succeeds.

回答6:

1/ When the user check "remember me" : you store a hash of every informations about his computer : IP, browser, OS, language etc... and you write this hash in his cookies with his ID 2/ when the user is back, you compute his new hash. You compare this value with the value in the received cookie, and the value in the database (for the given id). if they are all equals, you can authenticate the user.

Is it clear ?

Https couldn't do anything if you have an XSS attack (best way to steal cookie)