The Salted Challenge Response Authentication Mechanism (SCRAM) specified in RFC 5802 can use arbitrary hash functions to operate. The base version from RFC 5802 uses SHA-1.
From my understanding, SCRAM solely relies on the one-way-ness of the function. It does not need collision resistance. It uses extensive salting and possibly many iterations, as well as a clever nonce-based mechanism to thwart replays.
In a discussion about which SCRAM version to recommend, somebody asked why SCRAM-SHA-256 (RFC 7677) should be used at all (even why it was even specified); aren’t the improved security properties of SHA-256 over SHA-1 irrelevant for the SCRAM use-case? Is this simply future-proofing?
RFC 7677 states in the Security Considerations:
See [RFC4270] and [RFC6194] for reasons to move from SHA-1 to a strong security mechanism like SHA-256.
RFC 6194 has the following:
3. SHA-1 Security Considerations
[collision resistance and pre-image considerations for SHA-1]
3.3. HMAC-SHA-1
As of today, there is no indication that attacks on SHA-1 can be extended to HMAC-SHA-1.
Note that SCRAM uses the hash function mostly in an HMAC construct; the only exception is StoredKey := H(ClientKey), but StoredKey is never transmitted over the wire and only used as key in an HMAC round. However, StoredKey is stored on the server. I don’t think that a pre-image to StoredKey would be useful, because in the protocol one needs both StoredKey and ClientKey to form the ClientProof.
RFC 4270 is less specific about the hash functions and talks in more generality about how they are used in the IETF protocols and how the attacks affect those uses.
From what I can tell, we can consider two uses of the hash function in SCRAM-SHA-1: 1. The obfuscation of the password through PBKDF2 with HMAC-SHA-1 as pseudo-random function, 2. challenge/response mechanism using HMAC-SHA-1.
Both uses are not mentioned as problematic in RFC 4270, AFAICT.
So to summarize, from what I have gathered:
- SCRAM-SHA-256 uses a more expensive algorithm, without apparent security benefits
- migration from SCRAM-SHA-1 to SCRAM-SHA-256 is difficult (requires a password change -> user interaction)
So... From that, the only use for SCRAM-SHA-256 seems to be new deployments and future-proofing, is that right? Is there a conceivable weakness of SCRAM-SHA-1 which outweighs the loss of interoperability when moving to or deploying SCRAM-SHA-256?
