How do I verify with whom I’m dealing? Authentication
When we conduct business in person, we rely on certain practices to authenticate that a person is who he/she claims to be. We are accustomed to reviewing a person’s driver’s license or other photo identification. The degree of scrutiny increases as the perceived risk increases so, for example, a law applicant typically provides photo id and a fingerprint at the State bar exam but a photo id alone is sufficient to buy alcoholic beverages. We do not expect authentication to be perfect, but we apply procedural rigor and consistency so that we may be reasonably confident that the results of authentication will match our expectation.
The July 5, 1993 issue of The New Yorker magazine depicted a dog, sitting at a computer terminal, saying to another dog “On the Internet, nobody knows you’re a dog.” Physical distance and an essentially anonymous environment mean that it is more difficult to authenticate parties to a transaction. Therefore, online authentication often requires two steps. First, verify that the name and other personal details submitted in a given transaction correspond to a genuine identity. Second, verify that the person online is in fact the genuine person asserted. Jane Smith may be a real person, but is the person seeking access to the network in fact Jane Smith?
There is no single “best practice” regarding the proper authentication of individuals, but there are examples we can use to create a working model. Authentication models typically incorporate one or more factors: 1) something you know, such as a password; 2) something you have, such as an encryption token; or 3) something you are, which encompasses fingerprints and DNA. We refer to single factor authentication as the use of just one of these mechanisms in conjunction with a user id. Dual factor authentication involves two of the three and is generally considered more secure, although it is rarely cost effective for consumer transactions. If one selects carefully the information used to verify somebody, then single factor authentication can be reasonably strong. Single factor authentication is not perfect, but security professionals and regulators recognize that there should be a balance between security and convenience.
Single factor authentication in the form of a User ID and password/shared secret is the most common mechanism online to control access to protected web pages. There is little guidance on whether customer-generated passwords are consistently better or worse than provider-generated passwords. People will more likely recall their own secrets, which is good. However, the convenience of easy recall often undermines the complexity required for a reasonably strong password. Therefore, password generation focuses on required parameters of the shared secret rather than who generates the secret.
Good practice requires that a shared secret be at least six characters long, contain at least two numeric & two alpha characters, and be case sensitive. A six character password with three factors of complexity (upper case, lower case, numbers) gives a keyspace of (26 + 26 + 10)6 = 1012, which means that a random password attack would be successful 1 in 10,000,000,000,000 (ten trillion) attempts. An eight character password with the same three factors of complexity would give a keyspace of 628 or about 1015.
Most passwords remain vulnerable to brute force attacks, though, and good practice includes relatively simple, additional mechanisms that can provide greater security than simply longer keyspaces. These unintrusive mechanisms may include:
- number of sequential failed login attempts before an account locks up;
- how long the lockup lasts, and how it is reset; and
- how often the password must be changed.
For reference, within a certain multinational company that uses passwords, the company requires passwords to be at least 6 characters long with at least three factors of complexity, and that users change passwords no less frequently than every 90 days, that five sequential failed login attempts lock up an account, that the lockup has to persist for at least 15 minutes, and that any persistent failures to login in to an account must result in a system administrator being notified.
Single sign-on (“SSO”) is highly attractive for password-protected web pages with varying security requirements because it allows a visitor to authenticate once for the entire visit and gain access to multiple accounts, applications, or systems. This benefits customers because of the increasing number of passwords we must all remember. Standards organizations like the Liberty Alliance develop specifications so that SSO can work not only within different portions of a single web site but among entirely different web sites. Companies still must face the challenge of how to balance a reasonable degree of security against varying risk scenarios.
The Federal Financial Institutions Examination Council (“FFIEC”) published in August 2001 a memorandum entitled “Authentication in an Electronic Banking Environment” that guides banks and which the Federal Trade Commission would consider instructive. The FFIEC’s Authentication guidelines state that
Authentication processes should be designed to maximizeinteroperability and should be consistent with the financial institution’soverall strategy for electronic banking and e-commerce customer services. The agencies believe the level of authentication used by a financialinstitution in a particular [web-based] application should be appropriate tothe level of risk in that application. FFIEC at 2.
The essential challenge for SSO is that the level of authentication must meet the requirements of the most valuable web pages. In practical terms, web pages that provide information are valuable to an intruder, but web pages allowing an intruder to create new accounts or modify an account in another person’s name are considerably more valuable. Therefore, the convenience of single sign-on requires that all protected web pages be covered by the same authentication.
User ID/Password Re-issuance
Customers will often forget a password. The challenge for any online provider is to distinguish a genuine customer from a fraudulent one and to automate the process for efficiency and consistency. Knowledge based authentication (“KBA”) is a common method, which involves a customer successfully answer one or more questions. The challenge of KBA is also the balance between security and convenience.
There are three levels of KBA in practice. First, one could ask for the person’s date of birth, social security number, mother’s maiden name, or favorite color. These do not exemplify personal facts that are all that secret or difficult to obtain, but verification of these may be sufficient for a web site without any non-public personal information. A second level of questions might include whether there is a co-signer on a particular loan, the name of a colleague at work, or the name of the person’s freshman year dormitory at college. Correct responses to these questions are more difficult to verify by an imposter, while still reasonably memorable for the correct person. Finally there is communication from the provider to the customer through an out-of-hand mechanism to which an imposter is presumed not to have access. For example, the popular online payment site paypal.com deposits a small amount into a user’s bank account and asks the user for the amount deposited. The Internal Revenue Service verifies the identity of the taxpayer when the taxpayer provides the adjusted gross income (AGI) for the prior tax year.
As with the initial authentication, though, the selection of KBA questions will depend largely on the risks of falsely granting access.
Once the provider has authenticated the person, there are different means to convey the forgotten password or User ID. For example, some financial services providers display a web page containing a customer’s User ID after the person has correctly matched first and last name, social security number, and account number with the specific type of account. The provider may then require that a person reset a forgotten password after correctly answering two questions, such as “What is the middle name of your youngest sibling?” and “In what city was your first elementary school?”
Financial institutions often manage this sort of transaction through an encrypted session. When there is less need for security, one may email to the customer a message containing a temporary password or conveying the forgotten User ID. A middle ground is to email a message with a hyperlink that leads to a secure password reset page. Combining email and hyperlink provides an additional layer of security beyond transmitting even a temporary password via an unencrypted channel.