What's wrong with this authentication system?

Question

I'm a software developer with an interest in and basic level of knowledge about security. I've come across an authentication system that "smells bad" to me however I lack the expertise to know what if anything is wrong.

The software system involves web services for downloading and uploading data from/to a database over the public internet. All communication occurs over HTTPS and a random 32 bit integer identifies the user. Requests from unknown user ids are dropped.

Something about this seems weak but I'm not sure how weak and whether it's worth advocating change. I suppose this is equivalent to a 5 character alpha (upper/lower case) numeric password with no associated username (log62(4 billion) ~ 5) and if I look at it in those terms it seems completely anemic.

My gut instinct about what to do for authentication would have been to expose a web service operation for "logging in" that takes a username/password and passes back an authentication token (for example a cryptographic hash based on the credentials and the current time) which is then good for a certain amount of time or until the user requests a log out.

I believe my approach is more secure mainly because the credential space is dramatically larger and because the authentication token changes over time, whereas in the current system the credential space is small and the authentication token never changes. But I have no reference point... what kind of adversary would the current system fail against? What kind of adversary would my idea fail against?

The argument in support of the current system is that we are a small player with small customers in a large world so we're not expecting to be attacked, and if we are attacked we do have some level of security. My thought is that security threats are becoming more numerous and more sophisticated pretty quickly, and we do happen to be in an industry where security is a concern. I don't want to give specifics here just because I may be pointing out the existence of a poorly secured live system, but perhaps someone knowledgeable could speak to current trends in security threats?

I would appreciate any input on this topic, and if for some reason my question is inadequate please let me know so I can update it accordingly rather than marking it to be closed!

Answer 1

I assume that the user ID are attributed randomly and uniformly among the 2³² possible 32-bit values. In that case, the best an attacker can do is to try potential user IDs (32-bit values) in any order until a proper one is found. If there are N valid user ID, then the average number of tries that the attacker will need to perform will be close 2³²/(N+1): if there are one thousand of users, then the attacker will need to connect about 4 million times to your server before being granted access. Once the attacker gains access, he can reuse the ID at will.

Your only defence in that case is to try to detect such brute forcing, e.g. by banning IP addresses from which come too many failed attempts. This has limitations; in particular, when many people are behind some kind of Web proxy or NAT, they may, from your point of view, share the same IP address, so you risk disabling a lost of users with a lockout strategy. Conversely, attackers can rent botnets in order to perform their one-time brute force from a lot of distinct IP addresses.

One way to look at it is indeed to consider the user ID to be some kind of password; in that view, the attacker can attack the passwords for all users simultaneously. The security level is thereby lowered when there are more users, as can be seen in the mathematical expression above: more users means more targets for the attacker, without increasing the search cost.

A login+password strategy is what most people do. This is much better: when trying to brute force a password, the attacker must select a specific user name, and will be able to break only that specific password. The "user name" is a non-secret piece of information that is specific to each user. With user names, the attacker's task is no longer a thousand times easier when there are a thousand of users. As for a "session token", well, there are several methods which are more or less equivalent (token in the URL, token as a POST parameter, token as a HTTP header -- also known as a "cookie" --, and so on); SSL itself has its own notion of session and you could reuse that.

Summary: the "secret user ID" with no user name strategy can be secure, but only if the space of possible user ID is large enough to defeat brute force, even if there are many valid user ID. This requires large user ID which must be selected randomly and uniformly. 128 bits would be enough. 64 bits would make me quite nervous. 32 bits are way too small.

Answer 2

The easy argument is that 32 bits is well within brute forcing limits, depending on how many attacks per second is possible it will probably take something in the range a week to a year to search the entire space. Divide that time by the number of users and you have an approximate time frame for the attacker to find one account.

I don't know the details of the implementation, a per IP login request throttling makes an attack harder, but probably not enough harder. Is it possible to deduce the ID space from just looking at the public code? Right now your strongest defence may be that not a lot of people know that all user IDs are integers. It is not something I'd rely on, but a dictionary brute force attack without the integer knowledge would be a lot harder.

Also, whoever wrote this code in the first place obviously isn't very security minded, it seems likely that there may be other issues. Cross site request forgery, SQL injections, or perhaps even some "fast" C code with old-school buffer underrun.