后台已经做了密码加密,前端想来做密码加密!后端只存加密后的字符串就可以,登录时对比字符串即可!
修改密码操作
前端:不做明文传输 password,我将 password 进行 MD5 加密后,传给你。
后端:我后端做了加密,你这么做的好处是什么?
前端:之前的项目都是这么做的,哪有密码直接传明文的!
后端: ...
后端问:这样有什么好处呢?
日志的话 rails 有过滤机制,针对密码可以过滤为 "password"=>"[FILTERED]" 这个样子在日志中显示
他说的“误”,是会存在这种情况,要额外写日志记录,使用了下边的非最佳实践代码,密码参数是会被记录的
error_logger = Logger.new("log/fatal_errors_#{Time.now.strftime('%Y%m%d')}.log")
error_logger.level = Logger::ERROR
error_logger.error("VARIABLES:#{params[:variables]}")
系统层级增多之后,每个环节的人就会想多做一些事情增加存在感。
前端哈希要看防的是什么,我想了下防的是后端记录明文密码。但是 MD5 太快了,彩虹表一堆,没什么意义。
两个人争不出结果,让上级决定。
“前端加密密码”, 几乎就是自欺欺人。
如果前端将密码”123456“加密成”zxdfasdf"这样的字符串,那么该字符串才是真正的密码明文。绕过 UI 层,通过 curl 之类的工具用该“加密后的字符串”就可登陆。
前端要这样搞,那么所有的密码相关接口,包括注册,登陆,重置密码等接口操作,必须保持统一。然而这样会导致很大的开发心智负担。假如现在需要另一个团队开发配套的管理后台,这个团队并不了解之前的前端加密操作,那么在涉及到“密码”的功能时,可能会出现非常诡异的 bug. 我们曾经遇到过一个需求,后台管理员生成一段随机字符串重置指定用户的密码,并自动通过邮件发送该密码给用户。而管理后台并不是前端团队开发的,试想如果前端有这个加密操作,而这个信息并没有同步到管理后台的团队,那么会发生什么。
用户密码只是安全的一部分,其他信息就不重要了吗?例如,手机号,年龄,性别,订单,支付信息等等... 为什么这些信息不需要加密呢?如果要加密,那就是把 HTTPS 重新实现了一遍。不要搞“局部优化”。
在 Ruby 的前后端分离架构中,用户密码的加密问题通常由后端处理。前端负责收集用户输入的信息,但为了确保安全性,密码加密应在后端进行。后端处理包括使用安全的加密算法对密码进行哈希处理,确保数据在存储和传输过程中保持安全。这个问题已成为开发者的 top search,因为正确处理密码加密对保护用户隐私至关重要。
前后端没有分离的时候,HTML Form 中的 password 栏位就是明文传输的。用上 HTTPS 以后,数据传输层就加密了。服务端无论如何是要使用密码明文来做验证的,发送请求前再 Hash 一下纯属多余。
<input type="password" id="password" name="password" required>
假设表单中的用户名和密码分别为 user1
和 password123
,提交表单后的 HTTP 请求可能如下所示:
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
username=user1&password=password123
在这个请求中,表单数据(username
和 password
)以明文形式传输。如果有人在数据传输过程中拦截了这个请求,他们可以直接读取用户名和密码。
对于 HTTPS,虽然表单数据内容是相同的,但它们在传输过程中是加密的,因此无法直接查看明文数据。以下是数据传输的基本结构,但内容是加密的:
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
<encrypted data>
在 HTTPS 中,浏览器和服务器之间建立了安全的 TLS/SSL 通道,所有传输的数据都会被加密。拦截者无法解密这些数据,因为解密需要 SSL/TLS 会话密钥,这些密钥只能由浏览器和服务器生成和共享。
总结:在使用 HTTPS 时,即使有人截获了网络请求,他们看到的也只是加密后的数据,而无法直接读取用户的敏感信息。