Aren't permanantly logged in accounts inherently insecure?

Question

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?

Answer 1

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 2³⁴ accounts. Use 160-bit cookies (20 bytes, nothing to sweat over for a cookie). That's 2¹⁶⁰ possible cookie values, so only one cookie value in every 2¹²⁶ 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 2³⁰, so the attacker will, on average, need to try for about 2⁹⁶ seconds before hitting a valid cookie value. "2⁹⁶ 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]).

Answer 2

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

Answer 3

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.

Answer 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

Answer 5

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.

Answer 6

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.

Answer 7

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.