By Sean ONeill on Dec 16, 2009
This blog could just be the title and thats it. Nuff said.
One recurring major mistake I see over and over again is the use of email as a way to track unique user accounts.
Seems like a good idea. When a new user is created, email is usually one of the first accounts they get provisioned. The email string is unique to the user, so why not use it as a way to identify user accounts across all systems? Its almost always a data element in the LDAP directory, so its available across the network for any user looking to authenticate a user. Next thing you know, the ERP system uses it to track user accounts, the healthcare web site uses it, etc.
So what's the big deal?
The problem is two fold. First, by using a user's email account name, you are compromising the overall security of your domain. Give me your business card and I already have one half of your login sequence. Email account names are easy to guess, leaving one only to work out the password to gain access to many corporate systems.
And secondly, email account names may not be permanent. Names change when one gets married. Users may want mail aliases to use nicknames or variations. Or even bigger (and this one hits close to home at this current time), the name of the mail domain may change. If and when Sun gets acquired, everyone employee of Sun will most likely get a mail account in the Oracle.com domain. Employeename@sun.com becomes email@example.com. All audit trails become much more complex because you have to track across muliple UserID's to recreate a user's access.
So what is recommended? An employee number, preferably greater than six digits. Most HR systems assign each employee a unique number. The number is usually not easily known. And its stays the same when the employee gets married or changes their name. And it stays with the employee forever, even if they leave and then return later. Add a few letters as well, say initials, would help insure uniqueness across all identity domains.