In a recent newsletter W2Knews announced the results of a poll on passwords. The question was: "In your company,
have you implemented for your users:
- Strong password policy, enforced by AD and Group Policy: 24.39%
- Strong password policy, implemented via the Resource Kit: 17.19%
- Written policy about password strength: 19.14%
- No written policy, no additional tools, rely on NT/W2K's password functionality: 37.31%
This means really that for more than half of you, your users are very likely leaving your domains open to attack. After all the security measures taken to make your network impenetrable, that one liability could undermine your entire operation."
If you can't depend on your user's passwords, then one solution is to increase authentication standards. Mandy Andress addresses this issue in an article from InformIT on strong authentication procedures.
Authentication, the process of proving that someone is who he claims to be, is one of the most important components of your security infrastructure. Users need information, but you want to make sure that you know who is accessing that information. Only specific individuals should see your company's payroll data or product source code, for example.
Although authentication is important, it does not exist in a vacuum. To be effective, authentication works together with identification and authorization. Identification, such as a username, determines whether a user is known to the system; authorization determines whether the user is allowed to access the requested resource or data. Authorization can take many forms, but Windows NT file permissions are the best example of authorization.
Identification, authentication and authorization are often collectively referred to as access controls.
Identification, authentication and authorization work in tandem to answer four very important questions:
- Who are you?
- Do you belong here?
- What rights do you have?
- How do I know that you are who you say you are?
These questions must be answered before a user can access any protected resource, whether it be a Web server, a workstation or a router.
Authentication can function at all levels of your security infrastructure. You are probably most familiar with authentication to a Network Operating System (NOS), such as a Windows NT domain. Every time you fire up your computer at work, you have to log on to the NT domain before you can access any resources.
You can require users to authenticate to almost anything, including your firewall to gain access to the Internet, your mail server to check e-mail, your intranet Web server to gain access to the corporate intranet, the database to access customer data and numerous other applications that enable you to go about day-to-day activities.
Although authentication provides you with valuable information about who is accessing the application and when, users get very tired of dealing with so many accounts. Single sign-on is one technology that aims to relieve users of this problem.
Before getting to specific technologies, I want to discuss the three major types of authentication commonly used today (listed from weakest to strongest). These are authentication based on:
- Something you know -- Personal identification number (PIN), password.
- Something you have -- SecurID, smart card, iButton.
- Something you are -- That is, some measurable physical characteristic of you, such as fingerprints or speech. This authentication technique is called biometrics.
Smart cards, SecurID and iButtons are great for authentication, but what happens if someone steals your device? If all that is required for authentication is the presence of a token device, your authentication is not that much stronger than a regular old password.
Individually, any one of these approaches has its limitations. "Something you have" can be stolen, whereas "something you know" can be guessed, shared or forgotten. "Something you are" is generally the strongest approach, but it can be costly to implement.
To make authentication stronger, you can combine methods, often referred to as multifactor or strong authentication. The most common type is two-factor authentication, such as using a PIN code as well as a SecurID token to log on to your network. The example of two-factor authentication with which you are probably most familiar is your ATM card -- you insert your card (something you have) into the ATM machine and enter your PIN (something you know) to access your account number and perform transactions.
You also can use three-factor authentication. For example, if you use biometrics to authenticate users to the network, you can store the fingerprint information on an iButton that is accessible only with the user's PIN.
When Is Strong Authentication Required?
The most critical factor to consider in deciding whether strong authentication is required is the cost (calculated in dollars, potential public embarrassment, or other suitable measures) associated with unauthorized access to the data or resource in question. It might not pay to have a strong user authentication tool to control access to low-risk data, but high-risk data will likely warrant the user accountability that strong authentication provides. Another factor to consider is corporate liability. Downstream liability is a new concept with major implications. The most common example is that of a computer connected to the Internet, accessed without the owner's permission and used as a jumping-off point for an attack that subsequently causes large losses for a third party. Current law holds that the third party can sue not only the perpetrator of the act, but also any other parties involved in the act, including the company that owned the network used as the jumping-off point. The average hacker might not have "deep pockets," but the intermediary company might and could be judged guilty of not controlling its systems. In this example, strong user authentication can demonstrate that the company has not been completely negligent in implementing preventative controls.
Although multifactor authentication provides an increased level of security, users like the convenience of reusable passwords and hate the inconvenience of carrying an object around just to log in to a computer system. Even if you overcome the resistance of users, the added expense of cards/tokens and readers plus the trouble of distributing everything makes it extremely difficult to justify a token-based solution.
I am a proponent of strong authentication, especially the use of digital certificates, but only when required and economically feasible. Most companies today can survive just fine using password authentication as long as users select strong passwords and as long as passwords do not travel the network unencrypted or are stored anywhere in plain text.
Read more from Mandy Andress at InformIT. Registration is required, but it is free.