XMPP SASL SCRAM-SHA1-Authentifizierung

SCRAM-SHA-1

Der grundlegende Überblick darüber, wie dieser Mechanismus funktioniert, ist:

• Der Client sendet den Benutzernamen, für den er sich authentifizieren möchte.
• Der Server sendet das Salt für diesen Benutzer und die Anzahl der Iterationen zurück (entweder durch Generieren oder durch Nachschlagen in der Datenbank nach dem angegebenen Benutzernamen).
• Der Client hasht das Passwort mit dem gegebenen Salz für die angegebene Anzahl von Iterationen.
• Der Client sendet das Ergebnis zurück.
• Der Server führt eine Variation des Hashings durch und sendet das Ergebnis zurück an den Client, so dass der Client auch überprüfen kann, ob der Server das Passwort / einen Hash des Passworts hat.

Die kryptografischen Algorithmen, die Sie benötigen, sind SHA-1, HMAC mit SHA-1 und PBKDF2 mit SHA-1 . Sie sollten nachschlagen, wie Sie sie in Ihrer Sprache / Ihrem Framework verwenden können, da ich nicht empfehle, sie von Grund auf neu zu implementieren.

Im Detail

1. Zuerst das Passwort normalisieren (mit SASLprep ), dies ist normalizedPassword . Dies stellt sicher, dass die UTF8-Kodierung keine Variationen desselben Passworts enthalten kann.
2. Wählen Sie eine zufällige Zeichenfolge (z. B. 32 hexadezimierte Bytes). Dies ist clientNonce .
3. Das initialMessage ist "n=" .. username .. ",r=" .. clientNonce (Ich verwende .. für die Verkettung von Strings).

4. Der Client setzt den GS2-Header ( "n,," ) auf initialMessage und base64-codiert das Ergebnis. Es sendet dies als seine erste Nachricht:

   %Vor%

5. Der Server antwortet mit einer Herausforderung. Die Daten der Challenge sind Base64-codiert:

   %Vor%

6. Der Client base64 dekodiert es:

   %Vor%

7. Der Client analysiert dies:

   • r= Dies ist die serverNonce . Der Client MUSS sicherstellen, dass er mit der clientNonce beginnt, die er in seiner ursprünglichen Nachricht gesendet hat.
   • s= Dies ist das salt , base64-codiert (ja, das ist zweimal base64-kodiert!)
   • i= Dies ist die Anzahl der Iterationen, i .

8. Der Client berechnet:

   %Vor%

9. Der Client base64 codiert clientFinalMessage und sendet es als Antwort:

   %Vor%

10. Wenn alles gut gegangen ist, erhalten Sie eine <success> Antwort vom Server:

    %Vor%

11. Base64 dekodiert dies enthält:

    %Vor%

12. Der Client MUSS sicherstellen, dass der Wert von v die base64-Codierung von serverSignature ist.

Extras

Dies ist die Grundversion des Algorithmus. Sie können es erweitern, um zu tun:

• Kanalbindung Dies mischt einige Informationen aus der TLS-Verbindung mit der Prozedur, um MitM-Angriffe zu verhindern.

• Hash-Speicher Wenn der Server immer dieselben salt - und i -Werte sendet, kann der Client nur saltedPassword anstelle des Benutzerkennworts speichern. Dies ist sicherer (da der Client das Passwort nicht speichern muss, sondern nur einen schwer zu reversierenden gesalzenen Hash) und schneller, da der Client nicht jedes Mal die gesamte Tastenspannung ausführen muss.

  Der Server kann auch Hash-Speicher verwenden: Der Server kann nur salt , i , storedKey und serverKey speichern. Weitere Informationen zu diesem hier .

• Möglicherweise auch SCRAM-SHA-256 hinzufügen (obwohl Server-Unterstützung nicht existent scheint).

Fallstricke

Einige häufige Fallstricke:

• Nehme nichts von der Länge der Nonces oder salt an (wenn du sie erzeugst, stelle sicher, dass sie lang genug und kryptographisch zufällig sind).
• Das salt ist base64-codiert und kann beliebige Daten enthalten (eingebettet in NUL s).
• Die Verwendung von SASLprep funktioniert möglicherweise nicht für Personen, die ASCII-Passwörter verwenden, aber es kann die Anmeldung für Personen, die andere Skripte verwenden, komplett unterbrechen.
• Der initialMessage -Teil von authMessage enthält nicht den GS2-Header (in den meisten Situationen ist dies "n,," ).

Testvektoren

Wenn Sie Ihre Implementierung testen möchten, hier sind alle Zwischenergebnisse für das Beispiel aus dem RFC:

• Benutzername: user

• Passwort: pencil

• Der Client generiert das zufällige nonce fyko+d2lbbFgONRv9qkxdawL

• Erste Nachricht: n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL

• Server generiert die zufällige Nonce 3rfcNHYJY1ZVvWVs7j

• Server antwortet: r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096

• Das Salz (hex): 4125c247e43ab1e93c6dff76

• Letzte Nachricht des Clients: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j

• Gesalzenes Passwort (hex): 1d96ee3a529b5a5f9e47c01f229a2cb8a6e15f7d

• Client-Schlüssel (hex): e234c47bf6c36696dd6d852b99aaa2ba26555728

• Gespeicherter Schlüssel (hexadezimal): e9d94660c39d65c38fbad91c358f14da0eef2bd6

• Auth-Nachricht: n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j

• Client-Signatur (hex): 5d7138c486b0bfabdf49e3e2da8bd6e5c79db613

• Clientproof (hex): bf45fcbf7073d93d022466c94321745fe1c8e13b

• Serverschlüssel (hex): 0fe09258b3ac852ba502cc62ba903eaacdbf7d31

• Serversignatur (hexadezimal): ae617da6a57c4bbb2e0286568dae1d251905b0a4

• Letzte Nachricht des Clients: c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=

• Letzte Nachricht des Servers: v=rmF9pqV8S7suAoZWja4dJRkFsKQ=

• Server-Server-Signatur (hex): ae617da6a57c4bbb2e0286568dae1d251905b0a4