Passwords, which are so widely used by applications to authenticate users, are just so easy to be guessed, cracked, stolen or compromised. However, teamed with a second factor, they can reduce the chances of an attacker significantly
Authentication is the method by which a user confirms his identity to an application, computer or to another user. Typically, the user proves his identity using a password. By supplying the correct password for a particular username, a user proves that he is in fact the true user represented by the username. However, the use of passwords as the only factor for authentication is not a very secure mechanism. Passwords may be stolen, guessed, cracked, or compromised in other ways by unsolicited users or computer programs and can then be used to impersonate the true user. The computer has no way to differentiate an impersonator from the true user if both supply the same correct password for that particular username.
Having a single factor, like a password, for authentication is not good enough. This brings us to look at some additional factors that can be used either as an addition to the existing factor—password, or as a substitution to it for authenticating a user by a computer program.
When we use two factors instead of one for authentication, it can be called two-factor authentication. With two factors involved, a successful authentication can only happen if both factors provided are correct. This increases the complexity for an adversary to carry out an attack, as he now requires knowledge of two things rather than one to impersonate the true user. To further reduce the chance of compromise, the second factor should be a more robust authentication factor than static, reusable passwords. The different second factors for authentication which are in use today are discussed below:
A one-time password, as the name suggests, is a password that can be used only once. What this means is that the password is only valid for one particular login or transaction, or for a time period, say, a day, week, month, hour or so. The advantage is that once the password has been used, it is of no use to an attacker even if he gets to know it. And if the attacker gets to know a one-time password before it is used, he can use it only for one time period, login or transaction, but no more that that. We will illustrate two ways that an application can incorporate one-time passwords.
The application login page prompts the user to enter his username, password and a one-time password. Somebody knowing, guessing or cracking the password cannot login in place of the true user without a valid one-time password. And, a valid one-time password alone, is of no use without the password; an invalid or expired one-time password, with or without the password is of no use anyways.
The other way could be to let the user login using his username and password only, and, say, in case of an online banking application, prompt him for a one-time password whenever he initiates a transaction, such as fund transfer or bill payment. This way, somebody knowing only the password cannot make transactions, and the one-time password alone without the password is of no use.
Asymmetric Key Cryptography, or Public Key Cryptography
Asymmetric key cryptography associates two different cryptographic keys with a user, called public and private keys. Data encrypted by either of the keys can only be decrypted by the other key.
In this method the application stores a public key, along with the password, for each username. The corresponding private keys for all users are made available to them. For login, the user encrypts his password with his private key and sends it along with the username to the application. The application then decrypts the password using the user’s public key and verifies it with the stored password.
In this case, knowing the password alone is of no significance to an attacker, he will need to know a user’s private key also to encrypt the password, in order to send the password to the application. Similarly, knowing the private key alone will not be enough for an attacker; he will need to know the password also to login to the application..
The user’s private key can be made available by storing it on a hardware device, such as a USB token, smart card, floppy, flash disk, etc, or by printing it on paper.
Biometric authentication can use a person’s physical characteristics, such as finger prints, retina, facial features, etc, for authentication. Scans of these physical features can be converted into numbers using different algorithms. This number becomes the digital equivalent of a user’s physical characteristic which will be unique for each user.
In case of an application, digital representations of users’ biometric scans are stored with the application. For a user to authenticate using his biometric feature he will require a biometric reader, such as a finger print scanner, eye retina scanner, which can connect to his computer. While login, along with the password, the digital equivalent of a user’s biometric feature is also provided to the application for authentication.
Anybody with access to the password alone cannot login into the application, and the biometric features are unique to each individual and cannot be guessed or stolen. On the client side, digital scans of a user’s biometric feature can also be stored on a hardware token, such as USB device or smart card. This way the user may not require a biometric reader, the hardware token is all that may be required along with the password.