10

The basic premise behind a "keep me logged in until I log out" feature is a cookie is stored with some identifier that is used to log the user in again when returning to the site. While these identifiers are generally quite long, isn't it conceivable that an attacker could - forging a cookie - randomly guess identifiers until he got lucky?

On a site with a very large quantity of logged in accounts one would hit eventually

My thoughts on protecting against this are a token with a very large # of possible values, combined with logging each attempt a IP address attempts to autologin with a cookie; any attempt with an invalid token would be considered an attack and that IP address locked out.

Is this overkill? Am I worrying about nothing?

AviD
  • 72,138
  • 22
  • 136
  • 218
  • 12
    Do you realize how many candidate 64-bit cookie values there are? Do the math. I think you'll find that heat death of the universe occurs before any kind of "eventually" test that probes random hash codes looking for a winner. – S.Lott Jul 27 '11 at 19:48
  • S.Lott is right. If you're using real crypto, then the odds of someone randomly guessing (or even brute forcing) a token are very low. – Satanicpuppy Jul 27 '11 at 19:57
  • 4
    @S.Lott: Agreed. Especially when you can just install [Fire Sheep](http://en.wikipedia.org/wiki/Firesheep), go down to Starbucks and grab all the valid tokens you need. –  Jul 27 '11 at 20:04
  • 2
    @KeithB: Correct. Indeed, you might be able to buy a few cups of coffee for sysadmins at Starbucks and get passwords without using any technical means. Social engineering works wonders. – S.Lott Jul 27 '11 at 20:13
  • Just look over their shoulder. Was that an 'n'? –  Jul 28 '11 at 01:38
  • @chad, as a pro tem moderator at security.se I came here to say exactly that. We'd welcome having the question migrated, and I think will would get some good answers from the community there. –  Jul 28 '11 at 08:22

7 Answers7

9

The trick is too make the "eventually" go beyond the predicted lifetime of the Universe. That's pretty easy because of exponentials: just use a long-enough cookie. Each added bit doubles the number of possible cookie values.

For instance, assume that you have 16 billion users (i.e. each human being, including babies, creates two or three accounts). That's about 234 accounts. Use 160-bit cookies (20 bytes, nothing to sweat over for a cookie). That's 2160 possible cookie values, so only one cookie value in every 2126 is linked to an existing account. Now, our attacker is really motivated and will try one billion values per second (that's really big because "trying a cookie value" means connecting to your server, so we assume that your server is sufficiently kick-ass to handle one billion connections per second -- presumably you could afford that, if the whole of Mankind is your customer). One billion is about 230, so the attacker will, on average, need to try for about 296 seconds before hitting a valid cookie value. "296 seconds" is an amount of time also known as "about 2500 billion billion years": that attacker is surely patient and dedicated.

So this is not a problem in practice: a few more bytes and attackers are thwarted by sheer numbers. There is no need to implement lockout features (especially since lockout features can sometimes backfire by hitting honest customers afflicted with any kind of browser bug that you were not aware of, or something bad like that). Of course this assumes that the cookie values are generated with a strong enough Random Number Generator; think CryptGenRandom() on Windows, /dev/urandom on Linux/*BSD/Solaris, java.security.SecureRandom with Java.

(The bit about the lifetime of the Universe is true only if the Big Crunch hypothesis holds true and there is no God [because eternity is kind of long, too]).

mic
  • 163
  • 4
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
7

A good (long, strong random) identifier cookie is much harder to guess than a typical password. That's safe enough.

  • Safe enough for what? – this.josh Jul 29 '11 at 06:38
  • 2
    for brute forcing the session cookie on lolcats.org. If you have any real data on the site you *need* to use SSL. Hitting one of a million valid points in a 160bit cookie is something you really don't need to worry. – Hubert Kario Jul 29 '11 at 11:11
  • "Safe enough" means that blind guessing of the session cookie is just about guaranteed not to be the weakest link of your system. – D.W. Aug 05 '11 at 05:53
6

The trick here is to use "multi-factor" authentication.

The cookie, plus the IP address, plus any other information in the HTTP header provides some "continuity" of the user. The accept language and user agent, for example, don't change much if you use the same computer from the same location all the time.

A little JavaScript can return the window.screen information, which, similarly, shouldn't change very often.

Yes, it can be spoofed. But most of the time, a stolen cookie also winds up on an unexpected IP address with an unexpected HTTP header value in the request.

Any doubt about the other headers means the cookie is doubtful and a challenge should be provided.

S.Lott
  • 169
  • 3
  • 1
    Encoding the IP address into your session/authentication information can cause headaches. Many large corporations which use network load balancers (or proxies) can cause users to switch IP addresses between requests. Other examples of this is Satellite internet users, who also hop IP addresses frequently. As a result, a user may need to authenticate every request (if they get horribly unlucky). This is a small percentage, but it is something to consider. –  Jul 27 '11 at 20:29
  • 1
    @Jack M.: "Satellite internet users, who also hop IP addresses frequently" Absolutely. Using JavaScript `window.screen` is pretty popular. – S.Lott Jul 27 '11 at 21:04
  • I've also seen using subnets, instead of IP. It is just something to be aware of, because the first time someone calls and tells you they keep having to log in, it takes a long time to figure out and get a fix for it. –  Jul 27 '11 at 21:07
  • 6
    "Multi-factor" is a term used to describe authentication, but this question is about secure session management. HTTP headers can be forged, and as others have noted depending on IP addresses is problematic. See also [How is "something you have" typically defined for "two-factor" authentication? - IT Security - Stack Exchange](http://security.stackexchange.com/questions/3796/how-is-something-you-have-typically-defined-for-two-factor-authentication) – nealmcb Jul 28 '11 at 16:54
  • @nealmcb: Are you saying I can't use it as a generic term? If so, what's the generic term for using more than one factor? – S.Lott Jul 28 '11 at 18:31
  • I guess you could call it "multi-factor *authorization*". But as I said the options you suggest are problematic and aren't about authentication. That would have happened at the beginning of the session. As I noted in my answer, SSL is the main thing that is needed. It obviates any desire for IP addrs or http header checks. – nealmcb Jul 28 '11 at 18:56
  • This answer is totally bogus. You don't need multi-factor authentication to deal with the issue that the question-asker raised. A random 64-bit session ID is more than enough to prevent an attacker from guessing the session ID by brute force. Cookies are all you need, against that threat. – D.W. Aug 02 '11 at 19:58
  • I do not know that i would qualify this answer as bogus as it could add security. But it does not really answer the question about if permanently logged in accounts are inherently insecure. It just addresses how they can be made more secure. – Chad Aug 08 '11 at 13:33
4

The most important thing is to secure the connection with TLS/SSL. Without it, you're vulnerable to attacks like FireSheep, as documented at Can you secure a web app from FireSheep without using SSL?.

At that point other big risks come into play, like someone compromising the machine that is logged in, or gaining physical access to it.

Back to the question about the amount of entropy in the cookie, as others have noted it isn't hard to get a long-enough and random-enough cookie. See also How long should a random nonce be? - IT Security - Stack Exchange

Community
  • 1
nealmcb
  • 20,544
  • 6
  • 69
  • 116
3

One other issue that was not raised yet, and this has more to do with the titled question (permanently logged-in accounts), and less to do with the session cookie:

Permanently logged-in accounts provides the potential attacker with a much larger window of attack.
If the attacker manages in some way to steal your cookie (e.g. FireSheep, access to your machine, etc), then it will be valid indefinitely, and thus makes it more likely that a stolen cookie will be misused.
Moreover, if someone gets access to your client machine sometime in the future - e.g. shared desktops, borrowed laptop (or stolen), Internet cafe - you're still logged in.

That said, this is a tradeoff, that will often make sense for users, depending on the context of the application. For example, I want to stay logged in to my gmail (and SE sites), but not my bank.
On the other hand, protecting your cookie from being stolen in the first place (SSL, dont login on a public machine, log out when you're done, etc) is always a good idea.

AviD
  • 72,138
  • 22
  • 136
  • 218
  • 1
    +1 Yes users want convience... They are also the first ones to blame you when their account gets hacked because of stupidity on their part. – Chad Aug 08 '11 at 13:36
2

There are a few reasons of why you shouldn't worry too much about this type of attack as outlined below:

  • Size - With a large enough nonce, assumed to be part of the cookie value, it will become prohibitively expensive (time- and hardware wise) to generate a matching value to a currently valid cookie. I'm also making the assumption that all additional variables included in the cookie-generation process is known by the attacker, just to be nice.
  • End-point limitations - The server managing network connections on your end is likely going to be an incredible bottleneck when considering the amount of network connections required to yield a reasonable throughput of guesses per second (Consider the range of potential cookie values!).
  • Network bandwidth - Even assuming you have access to one monstrous hell machine of a server the attacker will instead be limited by available network bandwidth to carry out the attack.

Assuming the goal of the attacker is to impersonate a user I would argue that it is much more likely that he will attempt to simply steal cookies from unsuspecting users.

Christoffer
  • 1,030
  • 1
  • 6
  • 14
-1

Yes, you are worrying about nothing.

First of all, you should be using a large enough key so that it can't simply be guessed by trying all combinations. For example, if you SHA1 encrypt their login name, password, and some other information, it will take longer the the age of the universe to guess a correct combination -- even if it were possible to attempt a billion combinations per second.

It is, of course, riskier, but security is about weighing risk vs. reward (in the case, usability).

You are far more likely to make some other basic mistake, such as not forcing the use of HTTPS everywhere, than have a problem with the cookie.

Robert David Graham
  • 3,883
  • 1
  • 15
  • 14