Home / Blog / Password-based authentication

Password-based authentication

Posted on 01/22/2015, by Jesús Díaz (INCIBE)
Authentication

The use of passwords is still the most extended mechanism for online authentication. This is understandable, given that the only requirement is for everyone to remember their username and password, instead of the inconvenience of having to carry a digital certificate, USB token, intelligent card, specialized hardware or software, etc.

However, the endless cases of password thefts and compromises are, at the very least, an indication that much care needs to be taken when implementing one mechanism or another. Especially keeping in mind that users can’t be expected to follow adequate policies for managing their passwords. In our Cybersecurity Highlights, recent notable cases may be consulted, such as the publication of Dropbox users and passwords in October of 2014, the theft of 1200 million credentials by Russian hackers in August of 2014, or the Cerberus incident in March of 2014.

Within password-based authentications there are various possibilities, each one having different implications on the security of the service and the privacy provided to its users. In Wikipedia’s English entry there is a good initial categorization regarding this. Specifically, the alternatives are divided in:

  • Simple transmission of the password. The password is sent without being processed and through an unencrypted channel.
  • Transmission through encrypted channels: The password is transmitted through an encrypted channel, such as TLS.
  • Hash-based challenge-response methods. Where the challenge presented by the server is not simply to ask for the password, but a value that depends on it (for example, through a hash function).
  • Zero knowledge methods: Those where the values sent to the server for authentication do not reveal any information about the password.

In any case, these options are not mutually exclusive. For example, a hash-based challenge-response method could be transmitted either through encrypted or unencrypted channels.

In this post some of the most relevant mechanisms are described, either because they are the most used or because they provide interesting properties (and also have software support and/or international standards). Amongst the properties worth keeping in mind from the final user’s point of view, the following will be kept in mind:

  1. Forward secrecy. This property is important for authentication mechanisms based on passwords from which a symmetric password is derived, since the password cannot be expected to continue kept secure in the long term, and this could affect the security of the passwords that are generated from it.
  2. Protection against online attacks. Can an attacker that observes a satisfactory authentication use it to authenticate himself? In this aspect, it is frequent/conservative to assume that the attacker has access to the messages sent in clear (for example, as a result of partially compromising the server).
  3. Protection against database compromises. Specifically, mechanisms of this type that are included natively in the protocol.
  4. Does the server have access to the password at any stage? Including not only during the authentication but also during the registration.

Basic authentication

In the simplest mechanism, supposedly both client and server initially know the password (normally, the user sends it to the server during the initial registration). As shown in the following diagram, in this protocol the client sends the password in the clear and the server simply responds if the authentication has been successful or not.

Exchange of messages in basic authentication protocols

-Exchange of messages in basic authentication protocols –

A simple variation of this scheme is one where the password’s hash is sent, or an encrypted version of it, instead of the password itself. Although it is preferable from a privacy point of view (given that the server does not obtain access to the cleartext password), the final security is practically the same, since the same value is always transmitted, and thus can be directly used to impersonate the user.

As a result of its simplicity, this scheme has been used in a multitude of systems and protocols. For example, it is the basic authentication mechanism in PAM for Unix. It is also used in many web platforms (normally encapsulated through TLS, although sites can still be found that use it in HTTP). Historically, a well-known implementation is PAP, available in the link layer PPP protocol.

Challenge-response protocols

In these protocols, after establishing the connection, the server sends a challenge to the client which varies in every authentication, in such a manner that only a legitimate client (who knows the password) can respond in a satisfactory way. This option is also an improvement in terms of security, since the password is not transmitted during the authentication. In this case, supposedly both client and server initially know the password (shared during the registration). The following diagram shows a generic authentication sequence.

Exchange of messages in challenge-response authentication protocols

- Exchange of messages in challenge-response authentication protocols -

Examples of this family of authentication mechanisms are CRAM-MD5, DIGEST-MD5 or SCRAM-SHA-1 (the latter incorporating salts), available for example on the SASL framework, used for authentication against SMTP, IMAP and other servers. Another example of the implementation of this mechanism is CHAP, also available through the link layer PPP protocol. Specifically, MS-CHAP, of Microsoft (MS-CHAPv2 being the latest version), in which weaknesses on an implementation level that decrease its security are known.

Password-based Authenticated Key Exchange (PAKE)

In 1992, Bellovin and Merritt put forward the idea of a protocol (Encrypted Key Exchange, or EKE) to derive a symmetric password with a high level of security parting from a password, the latter probably being of low entropy. The schemes that have appeared with the same aim as a result of this original proposal are known as Password-based Authenticated Key Exchange, or PAKE.

In the original scheme, both server and user employed the password to derive the final key. Subsequently, the same authors published a variant where instead of a password, its hash (which could also be salted) is used. Therefore, they would provide, amongst other advantages, a default mechanism to protect the user’s passwords from server compromises. This variant is known as Augmented-EKE, or A-EKE. However, in their article, they define the architecture of the protocol without giving specific constructions (in other words, concrete cryptosystems) to build the protocol. The IEEE P1363.2-2008 standard contains definitions of schemes based on EKE.

The following figure represents a simplified sequence diagram of the A-EKE protocol. Before the execution of the protocol, supposedly user and server already know the hash(salt, password) value. It is notable that this protocol also requires the server to demonstrate that it knows the initial shared secret, providing a mutual authentication. Besides, although for brevity it is not shown in the following figure, the protocol also includes a final additional message to avoid an attacker from impersonating the user using the hash(salt, password) value.

Exchange of messages in PAKE protocols

- Exchange of messages in PAKE protocols -

The problem with EKE and A-EKE is that they are patented mechanisms, which has probably complicated their deployment, although there are also definitions within EAP that implement EKE (RFC 6124).

Another protocol in the PAKE family that has been implemented in various software products is J-PAKE (or PAKE by Juggling). For example, J-PAKE is implemented by Java in the cryptographic library BouncyCastle, or in Openssl (although as an experimental mechanism).

Secure Remote Password (SRP)

We already looked on a previous post at a mechanism known as Secure Remote Password (SRP). However, to summarize, it is noteworthy that it uses the concept of verifiers. Specifically, the server never (not even during the registration) has access to the passwords. In other words, whereas in other schemes you need to use salts in an explicit way to store the hashed passwords, in SRP this is done natively. Besides, during its authentication no information is transmitted that could help an attacker to obtain the password, or use the captured traffic to carry out new authentications. As was also seen in the mentioned post, SRP has an important support in terms of software implementations.

Additional security mechanisms: use of salts

As explained in "Password Security: A Case History", the use of salts adds important advantages, especially against compromises to the server. Specifically, salts make dictionary attacks impossible by preventing (an attacker) from determining if two hashes where a different salt has been used have been derived from the same password. Therefore, although eventually an attacker could recover some cleartext passwords from a database with salted passwords, the time needed to do so would be notably greater than in the opposite case (probably making the attack impractical).

In the case of A-EKE its compatibility with salts has already been specified, since the creators of the protocol carry out an analysis regarding it in the original article. Likewise, SRP also incorporates them natively. As for the rest of the mechanisms, it is also possible to adapt them so that, instead of the hashes directly, they use salted hashes.

Summary

Following is a summary of the properties of the protocols that have been introduced previously. In the case of PAKE, as it is a family of protocols, the two protocols we’ve mentioned (A-EKE and J-PAKE) are used as a reference although, depending on the specific variant, there could be changes to the provided properties.

Protocol Forward Secrecy Protection against online attacks Protection against DB compromises Password accessible by server
Basic Not applicable ✘*
Challenge-Response Not applicable ✘*
PAKE
SRP

*Yes, if password are stored as salted hashes, although it is not natively specified in the definition of the protocols/mechanisms.