后台已经做了密码加密，前端想来做密码加密！后端只存加密后的字符串就可以，登录时对比字符串即可！
修改密码操作
前端：不做明文传输 password，我将 password 进行 MD5 加密后，传给你。
后端：我后端做了加密，你这么做的好处是什么？
前端：之前的项目都是这么做的，哪有密码直接传明文的！
后端： ...
后端问：这样有什么好处呢？
hellorails
回复
日志的话 rails 有过滤机制，针对密码可以过滤为 "password"=>"[FILTERED]" 这个样子在日志中显示
528070506
回复
他说的“误”，是会存在这种情况，要额外写日志记录，使用了下边的非最佳实践代码，密码参数是会被记录的
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>
1. HTTP 请求中的数据传输（不安全）
假设表单中的用户名和密码分别为 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）以明文形式传输。如果有人在数据传输过程中拦截了这个请求，他们可以直接读取用户名和密码。
2. HTTPS 请求中的数据传输（安全）
对于 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 时，即使有人截获了网络请求，他们看到的也只是加密后的数据，而无法直接读取用户的敏感信息。
It's a good question! We had a similar debate on my last project. Ultimately, the backend should always handle the core encryption. The frontend doing it too is arguably defense-in-depth, but adds complexity. A simple solution for the frontend is HTTPS. Besides, after work, sometimes I just want to relax and virtually destroy planets with Solar Smash rather than debating encryption algorithms! What are some practical ways to ensure the backend's encryption is truly robust?