最近，按照以下两个网站上的说明，我能够在 Swift IOS 中对 XMPP 流进行 MD5 身份验证（我使用 Apple 的 CommonCrypto C 库的 CC-MD5 函数进行实际散列）：
http://wiki.xmpp.org/web/SASLandDIGEST-MD5
http://www.deusty.com/2007/09/example-please.html
我正在寻找有关如何使其他散列 SASL 身份验证方案正常工作的类似解释，尤其是 SCRAM-SHA1。我找到了官方的RFC5802文档，但我在理解它时遇到了很多麻烦（它也不特定于 XMPP）。我将不胜感激一个更简单的解释或一些特定于 XMPP 身份验证的简单可读代码（C、PHP、C++、Javascript、Java），除了实际散列之外不使用任何库。
我有兴趣了解该过程，并且不打算使用 ios XMPP-Framework。任何帮助，将不胜感激。
该机制如何工作的基本概述是：
您需要的加密算法是 SHA-1、带有 SHA-1 的 HMAC 和带有 SHA-1 的PBKDF2。您应该查看如何在您的语言/框架中使用它们，因为我不建议从头开始实施它们。
首先规范化密码（使用SASLprep），这将是normalizedPassword. 这是为了确保 UTF8 编码不能包含相同密码的变体。
选择一个随机字符串（例如 32 个十六进制编码字节）。这将是clientNonce。
是initialMessage（"n=" .. username .. ",r=" .. clientNonce我..用于字符串连接）。
客户端将 GS2 标头 ( "n,,") 添加到 initialMessage 并对结果进行 base64 编码。它将其作为第一条消息发送：
<auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" mechanism="SCRAM-SHA-1">
biwsbj1yb21lbyxyPTZkNDQyYjVkOWU1MWE3NDBmMzY5ZTNkY2VjZjMxNzhl
</auth>
服务器以质询响应。挑战的数据是base64编码的：
<challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
cj02ZDQ0MmI1ZDllNTFhNzQwZjM2OWUzZGNlY2YzMTc4ZWMxMmIzOTg1YmJkNGE4ZTZmODE0YjQyMmFiNzY2NTczLHM9UVNYQ1IrUTZzZWs4YmY5MixpPTQwOTY=
</challenge>
客户端 base64 对其进行解码：
r=6d442b5d9e51a740f369e3dcecf3178ec12b3985bbd4a8e6f814b422ab766573,s=QSXCR+Q6sek8bf92,i=4096
客户端解析：
r=这是serverNonce. 客户端必须确保它以clientNonce它在其初始消息中发送的内容开始。s=这是salt, base64 编码的（是的，这是 base64 编码的两次！）i=这是迭代次数，i。客户端计算：
clientFinalMessageBare = "c=biws,r=" .. serverNonce
saltedPassword = PBKDF2-SHA-1(normalizedPassword, salt, i)
clientKey = HMAC-SHA-1(saltedPassword, "Client Key")
storedKey = SHA-1(clientKey)
authMessage = initialMessage .. "," .. serverFirstMessage .. "," .. clientFinalMessageBare
clientSignature = HMAC-SHA-1(storedKey, authMessage)
clientProof = clientKey XOR clientSignature
serverKey = HMAC-SHA-1(saltedPassword, "Server Key")
serverSignature = HMAC-SHA-1(serverKey, authMessage)
clientFinalMessage = clientFinalMessageBare .. ",p=" .. base64(clientProof)
客户端 base64 编码clientFinalMessage并将其作为响应发送：
<response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9NmQ0NDJiNWQ5ZTUxYTc0MGYzNjllM2RjZWNmMzE3OGVjMTJiMzk4NWJiZDRhOGU2ZjgxNGI0MjJhYjc2NjU3MyxwPXlxbTcyWWxmc2hFTmpQUjFYeGFucG5IUVA4bz0=
</response>
如果一切顺利，您将收到<success>来自服务器的响应：
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success>
Base64 解码包含：
v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=
客户端必须确保 的值v是serverSignature.
这是算法的基本版本。您可以将其扩展为：
通道绑定。这混合了从 TLS 连接到过程的一些信息，以防止中间人攻击。
哈希存储。如果服务器总是发送相同的salt和i值，那么客户端只能存储saltedPassword用户的密码而不是用户的密码。这更安全（因为客户端不需要存储密码，只是一个难以反转的加盐哈希）并且更快，因为客户端不需要每次都进行所有密钥拉伸。
服务器也可以使用散列存储：服务器只能存储salt、i和。更多信息在这里。storedKeyserverKey
可能，还添加 SCRAM-SHA-256（尽管似乎不存在服务器支持）。
一些常见的陷阱：
salt（尽管如果您生成它们，请确保它们足够长并且加密随机）。salt是 base64 编码的，可以包含任何数据（嵌入NUL的）。initialMessage部分authMessage不包括 GS2 标头（在大多数情况下，这是"n,,"）。如果您想测试您的实现，以下是 RFC 示例的所有中间结果：
用户名：user
密码：pencil
客户端生成随机数fyko+d2lbbFgONRv9qkxdawL
初始消息：n,,n=user,r=fyko+d2lbbFgONRv9qkxdawL
服务器生成随机数3rfcNHYJY1ZVvWVs7j
服务器回复：r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096
盐（十六进制）：4125c247e43ab1e93c6dff76
客户端最终消息裸露：c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
加盐密码（十六进制）：1d96ee3a529b5a5f9e47c01f229a2cb8a6e15f7d
客户端密钥（十六进制）：e234c47bf6c36696dd6d852b99aaa2ba26555728
存储的密钥（十六进制）：e9d94660c39d65c38fbad91c358f14da0eef2bd6
验证消息：n=user,r=fyko+d2lbbFgONRv9qkxdawL,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,s=QSXCR+Q6sek8bf92,i=4096,c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j
客户签名（十六进制）：5d7138c486b0bfabdf49e3e2da8bd6e5c79db613
客户证明（十六进制）：bf45fcbf7073d93d022466c94321745fe1c8e13b
服务器密钥（十六进制）：0fe09258b3ac852ba502cc62ba903eaacdbf7d31
服务器签名（十六进制）：ae617da6a57c4bbb2e0286568dae1d251905b0a4
客户最终消息：c=biws,r=fyko+d2lbbFgONRv9qkxdawL3rfcNHYJY1ZVvWVs7j,p=v0X8v3Bz2T0CJGbJQyF0X+HI4Ts=
服务器最终消息：v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
服务器的服务器签名（十六进制）：ae617da6a57c4bbb2e0286568dae1d251905b0a4