Web site security is a very important issue to me. I find it frustrating sometimes dealing with the “security experts” in IT who operate based more on superstition and urban legends than on solid principles.  Part 2 is in response to my meeting with such a “security expert”.

In my meeting with the “security expert”,  I explained how users will authenticate (log-in) to a system using an email address, and a password.  Please see Part 1 for a description of why this is secure.

His response was “using an email address as your log-in ID was not secure enough.”  I asked him why?  He responded: “many people know your email address.  They could simply enter your email address, and then try to guess your password.  It is better to use the corporate user ID”

Our security expert is getting mixed up between the role of a username and the role of a password.  He knows that you want a cryptic password, and it thinking that a cryptic username would make it “doubly secure”.  More secure, is better, right?

As I point out in part one, the system is kept safe when the password is sufficiently hard to guess.  But there is a tradeoff: if you make a password very long and complicated, it becomes difficult for people to use, leading the user to write the password down to reliably remember it.  Adding extra complexity has the possibility of backfiring, leaving a system that is easier to break into using human factors.

The real irony here is that this organization forces us to use “first initial last name” as our login ID so a hacker can easily guess nearly everyone’s login ID anyway.  Adding an extra component that is easy to guess does not make the system more secure.

If the password is sufficiently strong, it is not necessary to augment that with making the username secret, and there are many reasons this is undesirable.

There is a commonly held belief that if a login attempt fails, the software should not give a hint as to whether you have entered the wrong username or simply the wrong password.  As a user, I have more than one email address, so when I go log into a site, and I am never 100% sure which email address I used to make the account there.  If login fails, then it would help me a lot to know whether it was because I entered the wrong email address, or whether I just used typed the password incorrectly.  This does, however, allow a hacker to discover whether a particular login-id is being used that that site.  The harm stated is the same that the “security expert” used above:  once you know that a user account exists, you can try to guess the password.  However, if the password is strong enough, then it will not be guessed anyway.  Hiding whether it was an invalid login-id, or whether it was the incorrect password, hurts the legitimate user, but add nothing to protecting the system.   Any time the system is made harder to use, you run the risk that people will write down that information, opening yet another potential hole.

This is the crux of the post today: no system is perfectly secure, but the thinking is that you should do anything you can do to make it more secure.   Implement all security measures, and if anyone questions any measure, dismiss that question because they are obviously trying to make the system less secure.  This leads IT people to certain kinds of superstition, driven by fear, in a modern day equivalent witch hunts in old Salem.  Questioning a security measure is a unspeakable taboo, making it effectively impossible to have a conversation about security measures.

I use an email address as a login-ID for two very good reasons:

1. everyone already knows their email address, and
2. the system requires an email address to communicate to the user in any case — at least to allow password reset.

From an ease of use perspective an email address is the right choice for the public identifier.  Facebook allows login using email address, and so to many (dare I say ‘most’) public sites as well.  The email address is globally unique, which allows it to be used effectively.  More important, however, is that the login-id should be easy to remember.

It takes a lot of confidence to say “the site does not need that to be secure”.  Many IT folks and site administrators will fear that anything done to weaken the security has the potential to allow a hacker in, and then they are to blame.  I am very sympathetic to IT people because the situation is that users will not follow rules, but it is IT that gets blamed when something goes wrong.  There is a huge temptation to enforce things through software without consideration to the usability aspects.

The right solution is a system that is secure enough but not one bit harder to use than necessary to enforce that security.  The right balance will  be the most secure system.  At the same time, it will be the most liked by the users.

Part 3 will talk about a different aspect of this problem: confusing login-id with display name.  Part 4 covers other insanity in the security domain.