在没有数据库的情况下阻止重复登录请求的最佳方法?

发布于 2024-07-24 06:25:57 字数 249 浏览 3 评论 0原文

我正在尝试为我们面向公众的网站之一编写一个改进的密码重置功能,除了更好的验证码之外,我还想标记一个在 y 分钟内尝试登录但未成功 x 次的用户名。 第一个想法是建立一个数据库来记录每次尝试,然后在达到最大尝试次数后,我们只需锁定帐户,直到接到员工经理的电话来重置帐户。

有什么更好的方法不需要通过 SQL 进行持久化? (Cookie/其他东西?)如果不存在,我怎样才能用一种更干净的方法来做到这一点? 由于某种原因,我今天的大脑很满

I'm trying to write an improved password reset function for one of our public facing websites and in addition to a better captcha I wanted to flag a username that attempts to login w/ no success x amount of times in under y minutes. The first thought was to have a database that logs each attempt and then after the max amount of attempts in the time - we simply lock the account until a phone call is recieved from the employee's manager to reset it.

What is a better approach that doesn't require persistence via SQL. (Cookie/something else?) If one does not exist, how can I do this with a cleaner approach? for some reason my brain is full today

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

帝王念 2024-07-31 06:25:57

检查有关限制它们的答案。
限制登录尝试

Jeff Atwood 有一篇关于该主题的有趣博客文章,以防您好奇。
http://www.codinghorror.com/blog/archives/001206.html

将它们存储在数据库中可能会变得乏味,并且您最终会担心失败的登录尝试会淹没您的表。 此外,在用户的计算机上存储控制此操作的内容也很棘手,因为他们可以控制计算机上的所有文件,并且他们可以轻松重置失败的登录计数器,或者更糟糕的是,向您发送错误/恶意数据。

Check this answer about Throttling them.
Throttling login attempts

Jeff Atwood has an interesting blog post about the subject in case you're curious.
http://www.codinghorror.com/blog/archives/001206.html

Storing them in a database can get tedious, and you will end up worrying about flooding your table with failed login attempts. Also, storing something on the user's machine that controls this is also tricky because they have control over all of the files on their machine, and they could easily reset your failed login counter, or worse, send you faulty/malicious data back.

遇到 2024-07-31 06:25:57

使用 cookie 或会话会很糟糕,因为用户只需清除 cookie 就可以清除他们的登录尝试。 也许使用临时目录中的文件来存储登录尝试是合适的?

Using cookies or sessions would be bad, since a user could clear their login attempts by just clearing out cookies. Maybe using a file in a temp directory to store the login attempts would be appropriate?

心意如水 2024-07-31 06:25:57

那么 cookie 对于攻击者来说没有什么用处(他们只会删除 cookie 或者只是不将其发送给您)。 如果您有内存中的应用程序状态,您也许可以使用它,但是您必须非常小心,因为这样做可能会导致您很快填满内存,此外还会遇到由于并发和并发而导致的可扩展性问题。锁定。 即使这可能不适用于在许多不同服务器上运行的应用程序,因为该应用程序状态可能不在这些服务器之间共享。 为什么您认为将数据存储在数据库中是一个坏主意?

Well a cookie is not useful against an attacker (they'll just remove the cookie or just not send it to you). If you have in-memory application state, you might be able to use that, but ou have to be really careful, as doing that might cause you to fill up your memory really quickly, in addition to running into scalability issues due to concurrency and locking. And even this might not work on an app that's running on many different servers, as that application state probably is not shared between those servers. Why do you think storing data in the database is a bad idea?

橪书 2024-07-31 06:25:57

您可以使用数据库、使用 memcache 并设置 cron 作业来定期转储表。 您还可以使用 cookie 或会话变量,但出于安全原因我不会依赖这些。

You could use a database, use memcache and setup a cron job to dump the table periodically. You also could use cookies or session variables but I wouldn't rely on these for security reasons.

染年凉城似染瑾 2024-07-31 06:25:57

请注意,破解者的目标可能不是访问您的系统,而是使其无法供所有人使用。 他也许可以通过自愿使用虚假凭据登录来阻止某些用户访问您的网站来实现此目的! 我认为如果没有数据库你就找不到任何合适的解决方案。

Be aware that the goal of a cracker might not be to gain access to your system, but to make it unusable for everyone. He could maybe achieve this by willingly logging in with false credentials to block certain users from your site! I think you won't find any adequate solution without a database.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文