What’s in a name?

Here is something quite interesting. Nobody ever considers the user names. They are just sort of “given”. Well, are they? Most of the time, they are not. They are assumed and designed into the system one way or another. And they can have an impact on security.

An old saying goes that a secure Windows computer is the one that is switched off, locked in a safe and dumped into the ocean. That goes for any other system and still leaves a tiny chance of a deep water diver break-in. We cannot make a computer system impenetrable. What we can do is make it harder for an attacker. One of the ways to make it just that bit harder is to choose good user names.

What’s a good user name? What is a user name? What is a user id? What is user identification? What on Earth is the difference? Hold it there, it’ll be all right in a minute.

I promise I will try to be as unscientific about it as possible.

Let’s start by making a distinction between what you think of as your user name and what the system thinks of as your user identification. In a normal traditional system design those are different things. And in security conservatism is a good trait.

Historically, the users were identified with numbers, account numbers. Still, in most systems internally the users are identified with account references, usually numbers. We will call these “user id”. Originally, users used the account numbers, the user ids, to log in to the system. Nowadays they usually don’t. Typically users use some kind of aliases to log in, those being user names, e-mail addresses and so on. We will call these “user names”.

Functionally, only one property is important for both the user id and the user name. They must be unique within the boundaries of the system. This is quite normal, no? The system must be able to distinguish between users, so the ids must be unique. The log in procedure must refer the user name to a single user id, so the user name must also be unique. Simple.

What are the security requirements to the user ids and user names?

The user names have to be unpredictable to help fighting the brute force attacks. We know very well that the most popular password is “password”. If an attacker knows the user names on the system, he can try all of them with the password “password” and he may get lucky. Another important issue is the lockout of users, also known as a denial-of-service attack. If the system locks users out after three unsuccessful attempts and the user names are known, an attacker can go through all user names and perform those three attempts, locking everyone out of the system. So unpredictable user names make an attacker’s life difficult. Mind you, unpredictable user names, not necessarily random user names.

We must distinguish between two very different cases now.

In one case the user base is automatically versatile and the user names selected for some semi-obscure reason are sufficiently diverse. For example, you have a website where people register with their email addresses from all over the world. Those are hard to predict. They are not random but making an exhaustive search for user names is technically hard. So you are lucky and you can leave things as they are.

On the other side, if your user base is fairly uniform, selecting something else as an identifier would work better. Suppose you run a company and all registered users belong to your company. If you select email address as an identifier, the attacker’s life suddenly becomes much easier. Get the list of people and there you go, you know all user identifiers. In this case letting users select their own identifiers, for example, would work much better. Do not be tempted into assigning the employee numbers, that are usually sequential, as user names. Letting people come up with aliases, nicknames is a really good idea then.

Let’s come back to the user ids now. For the user ids, unpredictability also matters. Suppose that there are methods in your application that take user id as a parameter to perform some operations, perhaps, viewing the user record. Then knowing the user id makes it easy to view user records and finding information about users and the system. And don’t count too much on your access control, it may fail some time and the only thing that will stand between your users and the attacker will be the unpredictability of those numbers. Remember, that’s what went wrong at Citibank. And, really, you have nothing to lose – the computer does not particularly care what kind of numbers it is crunching.

So, what’s a good strategy for the user ids? There is only one: the user ids must be random. They do not really need to be generated from cryptographically strong random numbers but they must be sufficiently random as to be unpredictable for an external observer a.k.a. the attacker. Oh, and UUIDs are not unpredictable, just in case you were wondering.

What’s a good strategy for user names? They must be unpredictable. Either they are already because you have a diverse user base and all you have to do is to force no additional scheme on them. Or your user base is uniform and then you must come up with a scheme to introduce unpredictability, the easiest being to use nicknames.

And that’s it for names, I think. Wasn’t that easy? ;)

For an extra bit of fun: Default Admin Username and Password list. May be useful, you know.

Why bother?

Hmm… Good question… Well, let’s get this straightened out before we jump into other interesting subjects. Every single website and application, every single computer system gets broken into. For fun, money, fame, accidentally. This is just the way it is and I have to accept this as the current reality. I may not like it but who cares about that?

Whether you are a large corporation or a student writing the first website, your system will get broken into. If your system has been around for a while, it was already broken into. My not-so-extremely-popular website was broken into already three times (that I know of) and I am not ashamed to admit it. Denial is futile. Take it as inevitable.

There is even a line of thought nowadays with some of the security people that we should not bother to concentrate so much on trying to protect things for we can’t prevent break-ins anyway. They say we should concentrate on detecting and containing the damage from break-ins. Ah, bollocks. We have to do both. Do not give up your defenses just because you know they will be eventually breached. But be prepared.

What I really want to say is that when you make a computer system, be it a website, corporate network, smart card or anything else, you have no choice. Thinking that security is somebody else’s problem is extremely common, second only to not thinking about security at all, and usually disastrous in a not-so-distant future. Don’t be like that. Come to the good side, protect your system, think of security long and hard, apply the Hash and the Crypto the Right Way™ and your system will run happily ever after (well, at least to the next major breakthrough in cryptography or something).

Welcome to “Holy Hash!”

This is a lighter software security blog. I start it now mainly because of two reasons.

First, something has to be done. The recent break-ins at the likes of LinkedIn and Yahoo show that even at the large companies people do not understand the basics of security. By looking at what is proposed and advised under the guise of security to people starting out to write their own web applications I understand that those are not far behind. Should their applications become famous, they will be broken as easily. There needs to be a place to discuss even the most basic things, so people do not keep making the same mistakes over and over again… like if it’s bloody Groundhog Day.

Second, why do we have to talk about software security always with a grave face? Yes, it is a serious subject but that does not warrant the long faces. Lighten up, people! Relax, let the Force flow. Have a break and make a joke. Security can be an entertaining subject. Let’s not make it appear harder than it is.

So here we are, something has to be done and it better be done with a smile. Or a grin… a smirk, a beam, a crack. Not with a frown. I will write my thoughts on software security, you are welcome to comment, make fun of, ask questions and generally have a good time.

Posts navigation

1 2 3 6 7 8 9