Provisioning API 和 Directory API 之间在密码长度强制方面的差异？答案

【问题标题】：Difference in password length enforcement between the Provisioning API and the Directory API?Provisioning API 和 Directory API 之间在密码长度强制方面的差异？
【发布时间】：2015-04-21 14:11:32
【问题描述】：

在我的组织中，我们有一个将用户密码更改与 Google 同步的流程。我们最近将此过程从 Provisioning API 转换为 Admin SDK Directory API。然而，在这样做的过程中，我们开始收到少量密码更改的错误响应，经过调查，我们确定我们的内部支持人员通过设置不符合密码长度要求的临时密码来响应用户的密码重置请求在我们的 Google 域中定义。显然，我们需要在内部进行一些流程更改。

这些错误仅在切换到 Admin SDK Directory API 后出现，这让我想到了我的问题。 这两个 API 执行域中定义的密码长度要求的方式有什么不同吗？更具体地说，Provisioning API没有强制执行这些要求吗？

【问题讨论】：

我没有听说由于 API 更改而对密码长度要求有任何更改，它们已经同时工作了一段时间。这可能是由于您正在使用的 API（如果您是的话）。只是一个想法，如果你使用“试试看！” the Users Patch documentation page 上的功能，其中一个密码失败，它仍然失败吗？

标签： google-api google-admin-sdk

【解决方案1】：

我不知道 Provisioning API 和 Directory API 之间的密码长度要求/强制执行有任何变化。话虽如此，如果您的客户端发送使用 MD5、SHA-1 或 crypt 散列的密码，那么 Google 的服务器将无法确定实际密码，因此无法确认其是否符合长度要求。我建议将密码作为盐渍密码散列发送。这些很容易在 Linux 或 Mac OS 命令行上生成：

$ echo 1234 | mkpasswd -s -m SHA-512
$6$/LHr6nGP$sqS21G30MNh/NAaNHuVitvk/ld3b8u5Ky8N7Rbs.5eptnETaPlV9hUk8mAOJdQ2KHacdJ5OGMRKD2ZXBuINyN1

所以users.patch() 请求正文看起来像：

{
  "hashFunction": "crypt",
  "password": "$6$/LHr6nGP$sqS21G30MNh/NAaNHuVitvk/ld3b8u5Ky8N7Rbs.5eptnETaPlV9hUk8mAOJdQ2KHacdJ5OGMRKD2ZXBuINyN1"
}

会将用户的密码设置为 1234。该密码对用户有效，因为在您设置密码时 Google 无法确定长度或强度。

当然，正如您在上面指出的，您确实应该强制执行最小密码长度（更不用说强度了）。

要生成哈希，可以使用passlib library：

from passlib.handlers.sha2_crypt import sha512_crypt
hashed_password = sha512_crypt.encrypt(password)

【讨论】：