现在网站一般对账号密码怎样处理后,传往服务器验证是否正确服务器一般又是怎样验证的b?

据我个人的经验,一般用户名和密码直接明文传,不加密,因为前端加密并没有什么软用,如果真怕被获取就上https,传到后台以后,如果有验证码,先验证验证码,没有的话数据库取用户名和盐,密码加盐hash以后对比。我反正不喜欢在数据库里存明文密码和加密过的密码(hash只是特征………没法解密
■网友
一般是拿到后,先判断验证码(如果有的话)是否ok,ok的话继续。根据用户名查询数据库用户信息。如果存在该用户则拿出salt,用md5加密传过来的密码和salt,然后比较下该用户的密码和加密的结果是否一致,是的话就是登陆成功(如果有salt加密的话)。其他情况返回用户名或密码错误(一般不具体告诉用户是哪个错误)。
■网友
问题是对帐号如何处理后传往服务器验证。不同的请求量和业务情况要采取的方案不一样,以满足业务为标准。我说一下我在用的处理方式。不一定是最好的方案,校验过程需要发三个请求。生成基本校验的数据前端:检测填写用户名及密码完成,发送索要验证码的请求到后端(第一个请求)后端:生成验证码,保存到内存的session中,校验状态设置为false,并发给对应cookie标识的前端前端:显示验证码,等待用户输入检测用户是否通过验证码前端:将验证码发给后端(第二个请求)后端:检测验证码,确认通过则更新session的校验状态为true。返回校验状态前端:如果拿到的是失败的校验状态,则重新申请验证码,若成功则继续下一步检测用户输入用户名密码是否正确前端:将密码计算md5,然后把用户名与计算完毕的密码一起发到后端(第三个请求)后端:检测session中的校验标识位是否为true,否:返回验证码错误,回到步骤1重新校验验证码。是:则重置校验状态为false,然后到数据库根据用户名将用户名、密码、salt一并拿出来不存在用户数据:如果拿不到数据则返回用户名不存在存在用户数据:拿到数据则将从前端拿到的加密密码再与salt做一次md5,检测与数据库是否一致。不一致:则返回校验密码失败,返回通知前端回到步骤1重新处理一致:更新session登录标识,将详细的用户信息等数据写入内存的session,并返回用户信息给前端最后我解释一下因为什么实际场景我采用了这种方案。99%加载登录页面的用户并不是真的要登录,因为登录窗口嵌入在整站顶部通栏,任何页面的打开都会加载这个登录页面的代码,所以不是所有登录页面都需要立即加载验证码,同时打开登录页面的用户只有少部分才是真的要登录,所以使用了步骤1,只有检测用户名和密码都输入之后才去后端申请验证码。以减少生成验证码对后端的负载。不修改请求header,标识为curl的扫描帐号的请求占总登录请求的数据有10%上下,所以用步骤2的验证码检测,使用cookie把这部分的请求过滤一下,不让这些检测帐号的请求穿透到数据库层面。后端并不需要知道真实的用户密码,密码只是一个标识,所以采用步骤3前端根据密码直接生成一个碰撞概率较低的混淆字符串即可,用md5只是这方面的库比较顺手,其实任何混淆算法都可以,最好是不可逆的运算。同时后端也做一个加salt的处理,防止被拖库之后用户密码又被拿去做彩虹表的碰撞测试。毕竟md5也不是绝对安全的算法,只是考虑到服务器的运算负载而采用的简单混淆方案。为什么要返回用户名不存在的提示?因为用户需要一个明确的纠错提示,同时用户名是否存在完全可以通过注册入口去扫描,这个完全没办法避免,所以干脆给一个明确的提示给用户。这个方案其实有不少缺陷,只是因为目前的需求恰好满足所以采用了,至少我知道的还有几个需求可以往登录上面加功能。算验证码并生成图片其实还挺耗cpu的,容易变成DDOS的攻击入口,这类的攻击如果有几次,就需要在步骤1申请验证码的处理上面做一些预处理,提前生成验证码图片资源池放服务器上面,申请验证码次数过于频繁则锁定客户端之类的方案减少这类请求对服务器资源的消耗明确知道用户名并进行密码扫描的请求如果太多,就需要在步骤3中再增加密码校验错误次数的检测,对错误次数太多的客户端和用户名做锁定处理。这种通常在涉及金钱的帐号系统上面使用。如果存在构造session标识的请求攻击扫描用户数据,这个方案的session存储方案是不能避免信息泄漏的。那么在步骤3校验用户登录成功之后,存储的用户登录信息就需要增加新的标识位给用户是否登录的请求检测做更详细的判断处理,比如登录ip,header以及前端生成的session标识做联合判断等等。


推荐阅读