Forget Your Password
I recently visited a large U.S. government agency that has been rolling out a number of security initiatives over the last few years. The organization has been an AppSec customer for quite sometime and is currently fully deployed with DbProtect, scanning and monitoring hundreds of databases. They take security seriously and continue reducing their risks with various enterprise-wide activities, one small step at a time. This is my favorite kind of progress, where patience and grit always pays off in the long run.
In 2011, thousands of agency’s employees will lose their passwords. The post-it notes will be gone forever along with the risk that a hacked personal account compromises corporate access. Each employee already has a smart card as the only means to enter Washington D.C. buildings. Next year it will be extended with a PIN to logon to computers. Unlike a password, a stolen card will get noticed quickly, will be disabled immediately and a new card will be issued in minutes so that the employee can resume work. Numerous additional benefits from the technology and cost perspectives have been outlined in many industry white papers, including this publication from DataMonitor and Siemens.
The implementation of global smart cards is enabled by an investment in physical security and enterprise-level single sign-on, well supported by various vendors in their own proprietary ways. Unfortunately I rarely encounter an organization that uses a single technology stack from one vendor. In addition, a number of legacy client applications or browsers prevail, creating unexpected barriers. Often, mission-critical software refuses to work and displays its contempt for your security initiative with a password prompt. DbProtect was one of those applications, a good example in an entire segment of enterprise software that leverages mixed technologies, built on Java, and running a free Tomcat application server on Microsoft Windows.
We wanted to bridge this gap in the technology stack and have committed ourselves to an open-source single sign-on implementation for Java web applications called WAFFLE as well as a substantial contribution to the Java Native Access project.
User Logon in SSPI
A typical Windows logon can be performed by the Win32 LogonUser API, entering the username, password and the type of login (interactive, network, etc.). Windows invokes one of the available security providers via a programming model called Security Support Provider Interface (SSPI) and typically authenticates the user against Active Directory using the Kerberos protocol. This method is usually implemented to validate one’s identity in web applications, but obviously requires to send the username and password “in clear” to the web server (hence the prevailing use of SSL). This isn’t a bad practice, but I have seen several unfortunate implementations that log this information or even store it unencrypted or encrypted with an easily accessible key on the server.
After a successful logon Windows creates a security context and hands over a token to access it. The security context includes the user’s identity (SID) and a list of groups that enable role-based access. Some groups have well-known identities, such as Everyone or Authenticated Users. The account can then be impersonated, if needed. Interestingly, I couldn’t find a single proper implementation in Java that does this and a growing collection of struggling developers attempting to connect to Active Directory to retrieve user groups. This is a tedious process that fails to properly acknowledge nested groups, Active Directory trusts or third-party security providers, all elements present and critical in most large enterprises.
LogonUser does not work with a smart card for the obvious reasons – the API requires a username and password. A smartcard does not contain this information.
Microsoft SSPI offers an alternate way to logon a user by exchanging opaque messages between a client and the server. The mechanism underneath may be Kerberos, NTLMv2 or any other present or future implementation, such as the recently introduced protocols for securing user-to-user communications (PKU2U). The web-based protocol of choice is “Negotiate” where the client and the server attempt to choose the strongest protocol available: Kerberos for Active Directory and NTLMv2 or NTLMv1 as fallback.
The programming model remains the same regardless of the protocol chosen with both the client and the server calling the InitializeSecurityContext and AcceptSecurityContext pair of functions, then sending newly obtained opaque messages over the network until both parties are satisfied with the exchange. This process is illustrated below. I invite you to read about the implementation in Java in my earlier post.
The advantages of this method are clear. There aren’t any usernames or passwords exchanged and the modern versions of the security protocols are not vulnerable to brute-force or man-in-the-middle attacks. In addition, the Microsoft implementation is forward compatible and enables the enterprise to roll out stronger authentication without changing the business applications. For example, you can choose to disable the weaker NTLMv1 by rolling out a new group policy.
Smart Card Authentication
I’ve recorded a quick video of smartcard authentication with DbProtect. This is implemented with our open-source WAFFLE package. Please feel free to share.
What are your thoughts on single sign-on usage? Are you rolling smart cards out in your enterprise as the only means for authentication? Do you think it’s a safer approach to securing sensitive information and avoiding weak passwords?