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.