SCRAM: A New Protocol for Password Authentication

Purpose

This whitepaper looks at the security benefits of SCRAM, and how it should be used to complement PKI based strong authentication. It describes Isode’s current support and future plans for SCRAM.

Where SCRAM Fits

SCRAM is a SASL (Simple Authentication and Security Layer) mechanism, which means that it can be used with any standardized protocol that uses SASL, including XMPP client/server protocol, LDAP, SMTP, POP and IMAP. It can also be used with proprietary protocols that use SASL, such as Isode’s SOM management protocol.

SCRAM is specified in RFC 5802: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms. There is an associated specification that defines how the data format used by SCRAM is stored in an LDAP Directory (RFC 5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted Challenge Response Authentication Mechanism (SCRAM) Secrets).

Passwords vs PKI

Isode has argued that Strong Authentication based on X.509 PKI is a desirable approach. It is useful to consider where PKI is appropriate, and where passwords are preferable.

Where PKI is Preferred

Password based authentication relies on a shared secret between two parties. This gives real management difficulties in setting up secure communication between many parties. It also gives security difficulties in managing the password (or information derived from the password) in two places. For PKI, the single private key can be managed very securely, for example by storing it on a smart card, which gives an extra authentication factor as well as providing protection. PKI based strong authentication is the best choice for:

• Server to server authentication. This deals cleanly with n-way communication and provides security and administrative benefits.
• For user to user security such as S/MIME, where PKI is a practical approach for managing n-way secure communication.
• For high security client/server authentication, such as directory administration in a high security environment.
• For user authentication to a server where users are issued with PKI private keys for other reasons (e.g., S/MIME).

Where Passwords are Preferred

For a server, it is straightforward to configure a PKI private key. For a user, the private key is too long to remember, so needs to be stored in some way. Approaches to do this have drawbacks:

• Hardware approaches such as smart cards have high cost, and can only be used where machines are provisioned with appropriate readers.
• Software approaches are cheaper, but require configuration of the private key on the machine to be used. This is impractical for mobile users.

This leads to many situations for user access to services where PKI based authentication is not a good choice, and that it is preferable to use passwords for client/server authentication.

Why SCRAM was Needed

All previously available protocols for password based authentication had one or more serious deficiencies. A replacement was needed that addresses these issues and is straightforward to deploy.

Threats against Password based deployment

Security threats against password based deployments include:

• Password interception, for example reading it on the network.
• Database attacks. Where the password database on the server is obtained by some means.
• Password guessing. Where an attacker tries multiple passwords to guess the user password. This is particularly dangerous if it can be done offline (e.g., against a list of hashes).
• Password duplication. Using the password determined for one service against another (relying on the fact that many users use the same password for many things).
• Cryptography ageing. Cryptographic algorithms have become easier to break due to a combination of cryptanalysis and improved processing power. Password based deployments need to be able to evolve to use newer cryptography.
• Server spoofing and phishing style attacks. For example the user connects to a server other than the one intended and discloses the password.
• Man in the middle attacks.

Older Protocols

All existing standardized password protocols suffer from one or more of these threats. For those interested in a detailed analysis of the better alternatives, there is detailed information in the SCRAM specification and documents that it references.

Plain over TLS

A popular approach for Web Applications and protocols such as LDAP is to use TLS (Transport Layer Security) to encrypt the connection and then exchange a plain text password. This has a number of advantages:

• It protects against password interception.
• It can protect against server spoofing and man in the middle, provided that the client checks the server certificate and identity. Most clients rely on the end user to do this, and this is not very secure.
• Password hashes can be stored on the server, so there is no need for the server to hold the plain passwords.

The reliance on client side checking of server certificate is a key weakness, as in practice this will often not be done, and so there is risk of server spoofing and man in the middle attacks.

Protection against database attack is dependent on the implementation, and so a compliant implementation could be vulnerable to attack.

Hashed Protocols

An alternate approach to using plain passwords is to use a challenge response protocol that communicates hashes, such as CRAM-MD5 or DIGEST-MD5. These are often used without TLS protection, although this is generally a bad idea, as an intercepted hash could be subjected to brute force attack. Using TLS gives some of the advantages described above for plain over TLS. There is no protection (or in some cases weak protection) against man in the middle attack, and the same poor level of protection against server spoofing that plain over TLS has.

A key problem with hashed protocols is that they require the server either to store the plain password or to store a mechanism specific plain text equivalent (that restricts use of other mechanisms). Database attack is a higher risk if hashed protocols are used.

Also, a number of security attacks have been identified on popular hashing algorithms, which have led to concerns about their use.

Password Policy

Users will often choose poor passwords if they are allowed to. Having good user passwords is important for all password deployments. For this reason, it is important to control password policy. A good way to achieve this is to use a directory server to hold passwords and enforce password policy.

How SCRAM Improves Things

Those interested in a detailed understanding as to how SCRAM works should read the specification. This paper attempts to give a high level description of the key features.

SCRAM specifies a format for the “secret” to be held on the server that comprises of three parts:

• A hashed data value (holding the stored key and a server key)
• A salt value
• An iteration count.

This should be stored securely on the server, and is intended as information that is private. A key benefit of SCRAM is that damage is relatively limited if this information is exposed.

This stored data on its own does not give sufficient information to fake authentication to the server.

SCRAM exchanges a number of hashed items between client and server. These are not susceptible to playback attack. The exchanges authenticate the client to the server, and authenticate the server (as the holder of the secret) to the client.

It is intended that SCRAM be used with TLS (or another data confidentiality mechanism) to achieve best security. SCRAM supports a feature “channel binding” that enables the client and server to be confident that the SCRAM and TLS endpoints are the same. This provides additional protection against man in the middle attack, and does not require TLS authentication to achieve this. A key benefit of the channel binding is that the server can be confident that there is no man-in-the-middle, independent of any authentication of the server by the client, and without any end-user action.

The salt value should be a random value specific either to the server or to the user account on the server.

The ‘iteration’ value defines the number of times that a hash algorithm is applied to perform password verification. This number can be set to a high value, which will substantially slow down verification. The benefit of this is that it can be used to make brute force password guessing attacks against a compromised database prohibitively expensive.

SCRAM is designed to be used with any hash algorithm, and so can evolve with improving cryptography. The first generation of SCRAM deployment is being used in conjunction with SHA-1, and migration to SHA-256 is anticipated.

SCRAM can co-exist with plain password login based mechanisms, while using the SCRAM secret format. If plain text passwords are stored, SCRAM can co-exist with hash mechanisms too.

SCRAM is not perfect, but addresses known issues and is expected to be effective for large scale heterogeneous deployment because:

• SCRAM is straightforward to implement, which is important as complex protocols hinder widespread adoption.
• SCRAM can co-exist well with other authentications which is important as experience suggests that most common deployments will rely on plain passwords and other existing approaches for some time to come.

Security Threats Against SCRAM

Where SCRAM is used with TLS and channel binding and good passwords are enforced by password policy, it provides good protection against all of the threats described above.

In the event of database compromise, password policy controls are particularly important, as these (in conjunction with an appropriately chosen iteration count) will provide protection against brute force attack.

For a specific secret compromised, if an exchange is obtained from the wire by some mechanism, this gives sufficient information for an imposter to pose as the client for that server (but not another one using the same password). Note that this interception is only useful if the database has been compromised – SCRAM is safe against replay attack. This is the primary SCRAM weakness, and why it is important to protect the secret database carefully and to use TLS.

In practice, SCRAM gives very good security for password based authentication.

Current SCRAM Implementations

There are a number of SCRAM implementations. Several of the implementations are in toolkits, and so mainly of interest to developers.

SCRAM is mandated for use in XMPP (RFC 6120) and so many SCRAM implementations are associated with XMPP client and server products. SCRAM adoption outside of XMPP has been slower.

Isode & SCRAM

Isode supports SCRAM across its product set, with several implementations, including channel binding. SCRAM is supported in the major Isode servers (M-Switch, M-Link, M-Box and MVault) the associated management tools and in the Swift and Harrier clients.

One Isode SCRAM implementation is being made freely available in source code as part of the CMU SASL package.

A key benefit of SCRAM is the ability to store the “secret” data in a secure format, which is an option for M-Vault configuration. A consequence of using the secure storage format is that non-SCRAM password authentication other than plain (e.g., DIGEST-MD5) will not work. So while storing passwords in this format is good security, it does have operational implications, as the secure format constrains the authentication mechanisms that can be used.

M-Vault acts as the password repository for other Isode applications supporting password based authentication (M-Switch for SMTP Submission, M-Box and M-Link). These applications can use the new SCRAM secure format, thus avoiding the need to read plain text passwords from M-Vault. All of these applications can use this to support either SCRAM authentication or plain.

Conclusions

SCRAM is an important technology for password based authentication which Isode is providing in its products.