About October 2010

This page contains all entries posted to AuthenticationWorld Blog in October 2010. They are listed from oldest to newest.

July 2009 is the previous archive.

Many more can be found on the main index page or by looking through the archives.

« July 2009 | Main

October 2010 Archives

October 5, 2010

12 Character passwords

I recently replied to a post on a Linkedin discussion group asking if 12 character passwords are required? All the talk about password lengths really makes me chuckle. Obtaining passwords short or long, is so very easy using social engineering that it negates the use of a password with special characters and X length. When I go onto client sites one of the first things I do is look under keyboards, behind the screens etc, where I usually find the password written down.

About 60 years ago, the military realized that sounds from keyboards could be diagnosed to determine what was being typed as well as screen emissions. Today, in many non-military enterprises, the easiest way to obtain passwords is to pay a janitor to install a keyboard logger on key people's computers. It only takes 10 seconds or so to install.

My bottom line is authentication should be based on risk. The use of uids and passwords is the weakest form of authentication for all the reasons mentioned above. Therefore, uids and passwords should only be used for systems and applications where the risk is low. Stronger forms of authentication should be used for higher risks.

However, before we leap to discussing stronger forms of authentication, perform an enterprise risk analysis for all physical and logical assets. This is the starting point for any discussion about authentication and not on the individual authentication method. Most enterprises I have been in don't have all this done. They also usually don't have an authentication risk chart assigning values to the weakest form of authentication to the strongest forms.

Once you have the risk assessment and the authentication risk chart, it's time to meet with the business owners and discuss ease of use versus security. For example, a trading desk application that can make trades of hundreds of millions of dollars is a critical risk. However, the business owner will not want to have excessive security to authenticate since time is of the essence and will opt for what appears to be a low form of authentication security. However, in these situations other physical security, business processes and applications that monitor to whom the trades are made, values, etc,. are then put in place to compensate.

I pity the poor user who has 12 character passwords to remember (with upper, lower case and special characters) that are changing every 60-90 days. They will end up writing them down to remember them and thus eliminate whatever security the security administrator was thinking to prevent others who are going to "crack" the code.

Guy

October 20, 2010

Risk and Trust

I've just released a new white paper "Risk and Trust". I wanted to put in context the ongoing discussions about RBAC vs ABAC and authentication against the bigger picture of data clouds, push vs pull and programmable internet applications. All of which I propose requires an enterprise risk and trust assessment framework.The paper is available at http://www.authenticationworld.com/Risk%20and%20Trust.pdf.

Regards,
Guy