时间：2021-07-01 10:21:17 帮助过：22人阅读
用SESSION和COOKIE，是不是很容易被重置？
……别听他们用Session，Sesion到头来还是用Cookie存的，什么，你说你用URL参数，那更不靠谱了……
user_login_log存类似这样的内容
userid username ip count expired
然后用户输入用户名之后，一个ajax请求过去，看看需要不要验证码（count > 2） 登录的时候，先检查一下是不是需要验证码。 登录成功就清除他的count记录。 实际做的时候用redis这类的数据库性能会比较好。毕竟登录看起来是在短时间内连续发生的 不过实际上无所谓地说。
你说的应该是 安全性的问题，你怕在客户端被 用户 强制 修改cookies是吧
那就用session来做，失败了一直累加数值，直到成功 才把这个 session级别的变量 赋值为0，或者你也可以 利用 间距时间来做，一段时间内 输错多少次，禁止登陆。
这种问题就不要考虑和客户端进行配合来检测了。
就是说不用考虑什么 session 啊，cookies 这些需要和浏览器端配合的。
以用户 ID 为 key，在后端存储（MySQL, Memcache, Redis, ...）里面记录下这个用户登录失败的次数。
我管你用啥浏览器用什么电脑，你的用户 ID 不变，我就能判断你是否在尝试穷举密码了。
PS. 一些大公司的帐号系统甚至把你的访问 IP 啊，登录时间啊，浏览器信息啊等都保存下来了。那些异地登录提醒就是靠这些数据实现的。
如果你的问题表述忠实地反映了你的需求的话——
给每个用户一个域，记录自上次成功登录以来登陆失败的次数。一旦登录成功就置此域为 0，遇登陆错误就自增一。
其实实际使用的话，这个域应该有个有效期的，比如说每天清零。
按照IP或者账户ID来限制吧。。。
Session一般是需要有个随机字符做为SessionID放在Cookie或URL或隐藏表单中提交到服务器的，所以可以很轻松的伪造或者重置。
先获取用户ID，然后再Memcache里记录一个用户登录的velocity即可
我认为该问题的关键在于用户的唯一标识，区分注册用户和非注册用户，跟session和cookie无直接关系
针对注册用户：
注册用户肯定有自己的uid（也就是用户唯一标识），在后端nosql数据库（例如Redis，Memcache）采用string数据结构，存储key为fault_[$uid]，value为失败次数的键值对，同时设置过期时间（这里过期时间系统允许多长时间内输错的时间），每次用户点击提交，查询Nosql数据库的key-value键值对，超过规定次数，则显示图片验证码。
针对非注册用户：
可以用cookie和session保持会话的完整性，例如用md5(用户ip+用户ua)作为session['credit']认证信息，同时cookie保存sessionid，每次开启同一会话，session['num']存储失败次数，当同一会话失败次数超过限制时，则显示图片验证码即可
Session 的话对于暴力破解 不遵守http协议的程序是无效的.建议楼主 如果用redis这些key-value来存储 设置过期时间3600.存储用户名为key 尝试数为value (计数器模式)。来限制锁定账户。不根据IP和cookie 这样最大限制来防止暴力破解。其他限制都可以绕过。
ASP MVC 4中simplemembership生成的Membership表：
Session如何重置
