In the previous blog article (Basic and Digest Authentication Types) we have started reviewing authentication types . This time we will focus on SCRAM which is a family of HTTP authentication mechanisms.
XMPP supports plaintext, digest password exchanges and also SCRAM (Salted Challenge Response Authentication Mechanism). SCRAM introduces advantages over Digest, since it allows the server to store password hashes in an irreversible format.
This feature protects against offline attacks on the password and user database. The client can also save a hash-only version of the password, making it more difficult for attackers (who may have access to the PC where the password is stored) to understand the password in plaintext format.
Furthermore, SCRAM protects from man-in-the-middle attacks when certificates are used. This is done by allowing the server to prove to the client that, not only is the certificate signed by a CA (Certification Authority), but that it also knows the password.
This feature is called channel binding, as the lower encryption channel is “bound” to the higher application channel. It also adds further security over TLS, which is lacking in plaintext and digest authentication.
SCRAM
In cryptography, the Salted Challenge Response Authentication Mechanism (SCRAM) is a family of modern, password-based, challenge–response authentication mechanisms, providing user authentication to a server. As it is defined for Simple Authentication and Security Layer (SASL), it can be used for password-based logins to services like SMTP and IMAP (e-mail) or XMPP (chat). For XMPP, supporting SCRAM is mandatory.
Messages
RFC 5802 (https://tools.ietf.org/html/rfc5802) names four consecutive messages between server and client:
client-first
The client-first message consists of a desired gs2-cbind-flag and a randomly generated client nonce.
server-first
The server appends its own nonce to this client nonce, and adds it to the server-first message. This message also contains a password used by the server for salting the user’s password hash, as well as an iteration count indicator.
client-final
After that, the client sends the client-final message, which contains c-bind-input, which is the concatenation of the client and the server nonce, proof of all the messages sent, and the contents of client-final up to the proof.
server-final
The communication closes with the server-final message, which contains the server proof.
Salted password
The salted password is calculated as follows:
Where Hi (p,s,i) is defined as PBKDF2 (https://en.wikipedia.org/wiki/PBKDF2) (HMAC (https://en.wikipedia.org/wiki/Hash-based_message_authentication_code), p, s, i, output length of H).
Proofs
The client and the server prove to each other they have the same variable, consisting of:
The proofs are calculated as follows:
Where ⊕ defines the XOR operation. and are verbatim strings.
Strengths
- Strong password storage: When implemented in a right way, the server can store the passwords in a salted, iterated hash format, making offline attacks harder, and decreasing the impact of database breaches
- Simplicity: Implementing SCRAM is easier than DIGEST-MD5
- International interoperability: the RFC requires UTF-8 (https://en.wikipedia.org/wiki/UTF-8) to be used for user names and passwords, unlike CRAM-MD5
- Because only the salted and hashed version of a password is used in the whole login process, and the salt on the server doesn’t change, a client-stored passwords can use the hashed versions and not expose the plain text password to attackers. Such hashed versions are bound to one server, which makes this ideal for password reuse
Conclusions
HTTP, XMPP, and SIP using Digest authentication offer basic protection and are only susceptible to:
- Offline attacks: meaning that a backup or copy of the database storing the logins and passwords is obtained by an attacker.
- Man-in-the-middle attacks: limited to a session, as digest usage protects from hash reuse.
Offline attacks are mitigated by using strong hash functions such as those in the SHA2 family.
In order to make the communication secure, not only during authentication but also to protect the data exchanged, a secured signaling protocol (TLS) must be used. We will discuss it in the next blog article. Unfortunately, many available UC systems do not enforce this feature by default.
XMPP offers an improved authentication mechanism via SCRAM. This offers significantly improved protection from offline attacks, man-in-the-middle attacks, and TLS certificate forging. SCRAM relies on a secure transport layer.
There are proposals (RFC 7804) to also support SCRAM over HTTP. In the meantime, the same improvement introduced by SCRAM can be implemented separately by web developers implementing the UC platform.
