没有明文用户密码的情况下，邮件服务器如何实现POP3 / APOP？

如何解决没有明文用户密码的情况下，邮件服务器如何实现POP3 / APOP？

Quoth RFC 1939，定义不带扩展名的基本POP3的标准。

         Examples:
             S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
             C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
             S: +OK maildrop has 1 message (369 octets)

             In this example,the shared  secret  is  the  string  `tan-
             staaf'.  Hence,the MD5 algorithm is applied to the string

                <1896.697170952@dbc.mtview.ca.us>tanstaaf

             which produces a digest value of

                c4c9334bac560ecc979e58001b3e22fb

如果我以为自己是APOP命令到达时的邮件服务器，那么我有以下内容：

我刚才随机生成的挑战字符串。
要求的用户名和来自客户端的MD5哈希值可能有效或无效。
受bcrypt，scrypt，PBKDF2或类似的哈希方法保护的用户密码。

您会注意到，明文形式的用户密码不在列表中，因为我们不打算在当今时代这样做。

当我连接到POP3服务时，仍然偶尔会在问候语中看到APOP挑战。这些服务是否以明文方式存储其用户密码？如果没有，他们如何在没有它们的情况下实施APOP？

解决方法

在此示例中，没有明文交换用户密码。密码在客户端经过哈希处理（未加密），然后将哈希发送到服务器。服务器执行与先前存储在指定用户帐户中的密码相同的哈希，如果两个哈希匹配，则授予访问权限。客户端根本不会意识到服务器计算的哈希值。

哈希不能逆转，因此MITM攻击者无法通过拦截提交的哈希来恢复原始密码（攻击者可以蛮力破解自己的密码，直到提交匹配的哈希为止，但这需要很长时间时间，服务器倾向于针对这种情况实施对策。

用户密码是否以明文形式存储在服务器端与APOP无关。这是服务器帐户存储的实现细节。人们会希望服务器正在加密存储中的密码。但是，仍然要求服务器可以访问实际密码。