UserID – Is It Too Menial to Secure

Meaning and Scale of Security

An userid (also commonly referred to as a username) is simply an identification used by a person to access a computer system or network. Alternatively referred to as an account name, login ID, username or user name

The userid identifies the user and is the key to accountability which requires that it should be unique to each individual user.

Does simply used as above, means and leads us to believe that there need be no policy about user names. In a range, the security consideration can vary from the extreme of generating random user names to no policy about user names.

Similarly on one extreme it is often said that once an attacker knows the username they have half of the information necessary to break into a site. Many security researchers and experts consider it to be a security weakness for a system to disclose the usernames available on a site. In the other extreme is a view that the username is treated as common knowledge since it’s not difficult to determine

No wonder it is easy to conclude both extremes may not be practical.

The Extremes Resolution

"The triad of CIA will determine whether or not to bother about user name."

Integrity of UserID

Since userID is directly related to accountability of  the actions of the users, it can be readily said that Integrity of the UserID need to be emphasized and maintained at all times. In this context it can be said that the addition of rogue userIDs, unauthorized alteration of UserIDs, and duplication of userIDs are some examples of compromise of integrity of userID

Availability Triad

The availability triad assumes importance when looked at from DOS attack perspective. Say for example the entire user list data base or the user list table or column in the data base for an application or utility or operating system is deleted then no user can claim to be who he is (that is the identification step) and as such the second step of authentication fails leading to lock out , in theory, of all users trying to log in. In such a scenario even the admins would be locked out and one can imagine the consequences.

Confidentiality of User ID

The comments in the availability triad paragraph above, could readily lead, one to right away conclude that confidentiality of userID could be one of the best solutions to ward off  DOS attacks. Imagine that PF number of the employees of the company is the userid or email address of the employees is the userID for logging in to most critical applications in use in the organization. Any employee disgruntled or otherwise or outsider can lock out all or most employees considering the userID information is fairly easily available.

We are of the view that the above would be too harsh a conclusion and confidentiality or otherwise should depend on where it is used or who is using it.

Simply putting it we can say user IDs of admins would require a greater degree of confidentiality as compared to normal users.

User IDs of users interacting in a public forum can be far from confidential. This is also clear from the fact which many of the readers would have observed where user names are disclosed consciously as the slug in the URL

To put this differently strong UserIDs  over the internet would tend and lean more towards privacy ( retaining anonymity) rather than security gains. Also there is an element of privacy in the HIPPAA title II privacy act but there is more of keeping secret the identity of the individual by the pharmacist in the sales record rather than userID logins

This brings us to the relevance of maintaining a clear distinction between non-secret identification information and secret authentication information That is why, it is often said go for strong and complex passwords  rather than driving hackers to guess user names.To many security focused professional this may look bland and na?ve driving them to ask how strong and complex the password should be, given the known user ID

User ID  Known – Password strength/Complexity – A mathematical proposition

Let us see with an example how to make up mathematically with a strong password to cover the publicly known userID

if username and password both have minimum  of 8 characters, then assuming 52 possible characters we have 52^16 combinations. However, if username is a known fact then that becomes just 52^8 combinations; you have to increase the password to 16 characters minimum to get the same level of protection – failure to do this would increase account takeover risk.

PCI DSS and User ID

PCI DSS emphasizes on the uniqueness of the user ID rather than its strength and secrecy. It provides of use of unique IDs at the time of account creation and its useful life. Also it prohibits the use of shared user IDs,Group User IDs and generic user IDs. It is very candid on strong authentication mechanism. In fact in guidance on requirement 8.4 it says that as one of the don’ts for strong password as to ensure that it does not contain any part of the user ID.This itself leads us to believe that secrecy element is not perceived by the PCI DSS standard for user ID as a requirement. Of course, based on the risks in the PCI environment of the organization, the organization may choose to use strong user IDs and even secure them  

The standard also includes requirements for removal of user IDs used for applications in the test environment. It also covers review of inactive user IDs every 90 days. These are more towards defence in depth rather than UserID being kept in the same plane and level as authentication in terms of security and secrecy.

 ISO 27001 and User ID

In ISO 27001 under the Operating System Access Control ( A.11.5.1 and A.11.5.2) it is provided for use of unique User ID. It is no different in ISO27001:13.

 Bio Metric and User ID

In a facility or location entry probably when only Bio Metric like finger print, retina scan is used then it is direct authentication cum identification a sort of two in one. But elsewhere even if Bio Metric authentication is used ,the identification is through User ID only.

Applications and User ID

From an applications perspective despite the fact that User ID is only for identification purposes, it must be mentioned that the application should not be vulnerable to user enumeration. This can be overcome by ensuring that the application displays proper error messages, set  user cookies properly and so on

 Brute force attacks

With user ID known or enumerated the brute force attacks will need only to work out and attack the password or the authentication mechanism rendering at least a great mathematical reduction in the possible number of brute force attempts to be made

UserID and Unified Payment interface

Here again the focus is and will be on uniqueness rather secrecy as accounts like #1223456@abcbank are meant for circulation

Conclusions

1. User ID is all about identification of the user
2. The use of strong User ID and keeping it secret leans more towards privacy than security
3. Focus need to be strong and complex authentification mechanisms like Password rather than on identification mechanism ( User ID)
4. Risk based approach in deciding the security or otherwise of User ID can be followed depending on the environment and type of user
5. Authentication mechanism say Password should not contain any part of user ID
6. Accountability is the main function of User ID and hence it should be unique to the user Security standards like PCI also emphasize on the uniqueness of User IDs

Way Forward

With so many hacks every now and then, the geometric progression of computational feasibility, the sophisticated hacking tools and software leads us to ponder whether the conclusions drawn above would hold good or we need to be driven to securing userID also and go to an era of masking userID ,using a different languages for user IDs and passwords and so on!