216
edits
Difference between revisions of "SASL Authentication and SCRAM"
Jump to navigation
Jump to search
m
SASL Authentication and SCRAM (view source)
Revision as of 15:40, 13 November 2019
, 15:40, 13 November 2019no edit summary
Neustradamus (talk | contribs) m |
Neustradamus (talk | contribs) m |
||
| Line 1: | Line 1: | ||
[https://tools.ietf.org/html/rfc5802 SCRAM-SHA-1] is a SASL mechanism improving on [[ | [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]). | ||
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. | |||
== 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. | ||
== 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] | |||