我应该在 AWS Cognito 和 Dynamodb 中存储失败的登录尝试吗？

Posted 2023-03-27

【中文标题】我应该在 AWS Cognito 和 Dynamodb 中存储失败的登录尝试吗？

【英文标题】：Should I store failed login attempts in AWS Cognito or Dynamo DB?

【发布时间】：2019-11-26 11:16:27

【问题描述】：

我需要构建一个基本的“3 次登录尝试失败并且您的帐户被锁定”功能。该项目使用 AWS Cognito 进行身份验证，并且 Cognito PreAuth 和 PostAuth 触发器运行 Lambda 函数看起来在这里会有所帮助。

所以基本流程是在 PreAuth lambda 中增加一个计数器，检查它并在那里阻止登录，或者在 PostAuth lambda 中重置计数器（因此成功的登录最终不会锁定用户）。基本上可以归结为：

PreAuth Lambda

if failed-login-count > LIMIT:
    block login
else:
    increment failed-login-count

PostAuth Lambda

reset failed-login-count to zero

现在，我正在使用专用的 DynamoDB 表来存储给定用户的登录失败计数。目前这似乎工作正常。 然后我认为在 Cognito 中使用自定义属性会更整洁（使用 CognitoIdentityServiceProvider.adminUpdateUserAttributes），这样我就可以丢弃 DynamoDB 表了。

但是阅读 https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-dg.pdf 标题为“配置用户池属性”的部分指出：

属性是帮助您识别个人用户的信息，例如姓名、电子邮件和电话号码。并非所有有关用户的信息都应存储在属性中。例如，频繁更改的用户数据（例如使用情况统计信息或游戏分数）应保存在单独的数据存储中，例如 Amazon Cognito Sync 或 Amazon DynamoDB。

鉴于每次登录尝试时计数器都会发生变化，文档似乎表明我不应该这样做...

但是谁能告诉我为什么？或者如果这样做会产生一些负面影响？ 据我所知，Cognito 计费纯粹基于存储（即用户数量），而不是操作，而 Dynamo 对读/写/存储收费。 难道仅仅是 AWS 不希望人们滥用 Cognito 作为一种存储机制吗？还是我傻？

【参考方案1】：

我们正在处理类似的问题，我们决定在数据库中存储额外属性的主要原因是 Cognito 对所有操作都有配额，并且“AdminUpdateUserAttributes”限制为每秒 25 个。

更多信息在这里： https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html

因此，如果您有一个 100k 或更多的池，如果想在每次登录时更新 Cognito 用户记录等，它可能会造成瓶颈。

【参考方案2】：

Cognito UserAttributes 旨在存储有关用户的信息。然后可以使用 AWS Cognito 开发工具包从客户端读取此信息，或者只需在客户端解码 idToken。您添加的每个自定义属性都将在客户端可见。

自定义属性的另一个缺点是：

您只需设置 25 个值 一旦添加到用户池中，就无法删除或更改它们。

我个人使用过自定义属性，操作它们的界面不是很好。但这只是个人想法。

如果您想存储此信息而不依赖于 DynamoDB，您可以使用 Amazon Cognito Sync。除了服务之外，它还为客户提供了可以整合到应用中的强大功能。

【讨论】：

并非每个自定义属性都会在客户端可见。 cognito 配置中有一个读/写权限，您可以打开/关闭属性。如果 'read' 关闭，客户端将永远无法看到该特定属性。我考虑过 Cognito Sync，但这似乎适用于在设备上同步数据，这不适合这个用例。最多 25 个属性并且无法删除它们是一个有效的点，谢谢。

对于您的用例，DynamoDB 似乎是最好的选择。

【参考方案3】：

AWS DynamoDb 似乎是您的最佳选择，它通常用于此类用例。使用它的一些好处：

您可以为每次登录尝试存储单独的记录，其中包含您想要的尽可能多的信息，例如 IP 地址、位置、用户代理等。您还可以添加可供预授权 Lambda 使用的日期时间以按时间范围查询例如在过去 30 分钟内尝试失败 您不需要管理表，因为您可以设置TTL for DynamoDb record，以便在指定时间后自动删除记录。 你也可以archive items in S3