Changes

Jump to navigation Jump to search
m
no edit summary
Line 1: Line 1: −
[https://tools.ietf.org/html/rfc5802 SCRAM-SHA-1] is a SASL mechanism improving on [[SASLandDIGEST-MD5|DIGEST-MD5]]. Its main benefits are in offering both a method to salt and hash the password in storage and in transit. This page aims to give a short introduction on how to implement it in a client.
+
[https://tools.ietf.org/html/rfc5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms (SCRAM-SHA-1(-PLUS)] is a SASL mechanism improving on [[SASL and DIGEST-MD5|DIGEST-MD5]] ([https://tools.ietf.org/html/rfc6331 RFC6331: Moving DIGEST-MD5 to Historic]).
   −
Note: There is an update of SCRAM-SHA-1/SCRAM-SHA-1-PLUS: "[https://tools.ietf.org/html/rfc5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms]"
+
Its main benefits are in offering both a method to salt and hash the password in storage and in transit. This page aims to give a short introduction on how to implement it in a client.
  [https://tools.ietf.org/html/rfc7677 RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms]
     −
== Overview ==
+
In [https://tools.ietf.org/html/rfc8600 RFC8600: Using Extensible Messaging and Presence Protocol (XMPP) for Security Information Exchange]:
 +
 
 +
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
 +
 
 +
<span style="color:#FF0000">Please note that there is now [https://tools.ietf.org/html/rfc7677 RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms], already integrated by several XMPP software servers (Isode M-Link, Jackal, Metronome, Prosody 0.12.x, Tigase 8.0) and several XMPP sotware clients (Conversations, Gajim 1.2.0-dev, KDE Kaidan, Psi/Psi+, Tigase Beagle IM, Tigase Siskin IM, Tigase Stork IM, UWPX).</span>
 +
 
 +
== SCRAM-SHA-1(-PLUS) ==
 +
=== Overview ===
    
The basic overview of how this mechanism works is:
 
The basic overview of how this mechanism works is:
Line 16: Line 22:  
The cryptographic algorithms needed are [https://tools.ietf.org/html/rfc3174 SHA-1], [https://tools.ietf.org/html/rfc2104 HMAC] with SHA-1 and [https://tools.ietf.org/html/rfc2898 PBKDF2] with SHA-1. It is advised to find libraries to use these algorithms instead of implementing them from scratch.
 
The cryptographic algorithms needed are [https://tools.ietf.org/html/rfc3174 SHA-1], [https://tools.ietf.org/html/rfc2104 HMAC] with SHA-1 and [https://tools.ietf.org/html/rfc2898 PBKDF2] with SHA-1. It is advised to find libraries to use these algorithms instead of implementing them from scratch.
   −
== In detail ==
+
=== In detail ===
    
<ol>
 
<ol>
Line 104: Line 110:  
</ol>
 
</ol>
   −
== Extras ==
+
=== Extras ===
    
This is the basic version of the algorithm. You can extend it to do:
 
This is the basic version of the algorithm. You can extend it to do:
Line 110: Line 116:  
* Channel binding. This mixes in some information from the TLS connection to the procedure to prevent MitM attacks.
 
* Channel binding. This mixes in some information from the TLS connection to the procedure to prevent MitM attacks.
 
* Hashed storage. If the server always sends the same salt and i values, then the client can store only <code>clientKey</code>, instead of the user's password. This is more secure (as the client doesn't need to store the password, just a hard to reverse salt) and faster, as the client doesn't need to do all the hashing every time.
 
* Hashed storage. If the server always sends the same salt and i values, then the client can store only <code>clientKey</code>, instead of the user's password. This is more secure (as the client doesn't need to store the password, just a hard to reverse salt) and faster, as the client doesn't need to do all the hashing every time.
* Possibly, also adding SCRAM-SHA-256 ([https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/ currently in draft]) (though server support seems non-existent).
     −
== Common pitfalls ==
+
=== Common pitfalls ===
    
* Don't assume anything about the length of the nonces or salt (though if you generate them, make sure they are long enough and cryptographically random).
 
* Don't assume anything about the length of the nonces or salt (though if you generate them, make sure they are long enough and cryptographically random).
Line 119: Line 124:  
* The <code>initialMessage</code> part of the <code>authMessage</code> does not include the GS2 header (in most situations, this is <code>"n,,"</code>).
 
* The <code>initialMessage</code> part of the <code>authMessage</code> does not include the GS2 header (in most situations, this is <code>"n,,"</code>).
   −
== Test vectors ==
+
=== Test vectors ===
    
Here is a complete example:
 
Here is a complete example:
Line 160: Line 165:     
Server's server signature (hex): <code>ae617da6a57c4bbb2e0286568dae1d251905b0a4</code>
 
Server's server signature (hex): <code>ae617da6a57c4bbb2e0286568dae1d251905b0a4</code>
 +
 +
== SCRAM-SHA-256(-PLUS) ==
 +
 +
Possibly, also adding [https://tools.ietf.org/html/rfc7677 RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms].
 +
 +
It is supported by several XMPP software servers (Isode M-Link, Jackal, Metronome, Prosody 0.12.x, Tigase 8.0) and several XMPP sotware clients (Conversations, Gajim 1.2.0-dev, KDE Kaidan, Psi/Psi+, Tigase Beagle IM, Tigase Siskin IM, Tigase Stork IM, UWPX).
 +
 +
 +
== Channel Bindings ==
 +
 +
- [https://tools.ietf.org/html/rfc5056 RFC5056: On the Use of Channel Bindings to Secure Channels]
 +
 +
- [https://tools.ietf.org/html/rfc5929 RFC5929: Channel Bindings for TLS]
 +
 +
- [https://www.iana.org/assignments/channel-binding-types/channel-binding-types.xhtml Channel-Binding Types]
 +
 +
== IANA ==
 +
 +
- [https://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml Simple Authentication and Security Layer (SASL) Mechanisms]
 +
 +
== LDAP ==
 +
 +
- [https://tools.ietf.org/html/rfc5803 RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets]
 +
 +
== HTTP ==
 +
 +
- [https://tools.ietf.org/html/rfc7804 RFC7804: Salted Challenge Response HTTP Authentication Mechanism]
189

edits

Navigation menu