Ruby 前后端分离,哪一端处理用户密码加密问题?

528070506 · 2024年07月22日 · 最后由 mfb777 回复于 2024年08月06日 · 1360 次阅读

后台已经做了密码加密,前端想来做密码加密!后端只存加密后的字符串就可以,登录时对比字符串即可!

修改密码操作

前端:不做明文传输 password,我将 password 进行 MD5 加密后,传给你。

后端:我后端做了加密,你这么做的好处是什么?

前端:之前的项目都是这么做的,哪有密码直接传明文的!

后端: ...

后端问:这样有什么好处呢?

加个字段把他的 md5 寸上,你后端加密的你自己都解不出来是啥密码。 以后业务场景需要你看看所有用户密码,你咋办?

前端加密能想到的唯一好处是防止后端日志系统将密码记录到日志中

daimeng 回复

怎么可能有这种业务呢,用户密码本来就要求保密的,而且后端使用数据库层的加密,就算数据丢失也不会泄漏明文密码

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]}")

业务层面只能说一切皆有可能

daimeng 回复

也许吧。不纠结业务的事 我是觉得前端明文传,后端加密,没什么大问题

系统层级增多之后,每个环节的人就会想多做一些事情增加存在感。

前端哈希要看防的是什么,我想了下防的是后端记录明文密码。但是 MD5 太快了,彩虹表一堆,没什么意义。

两个人争不出结果,让上级决定。

这个话题在 V2EX 讨论过很多遍 https://www.v2ex.com/t/1025454

“前端加密密码”, 几乎就是自欺欺人。
如果前端将密码”123456“加密成”zxdfasdf"这样的字符串,那么该字符串才是真正的密码明文。绕过 UI 层,通过 curl 之类的工具用该“加密后的字符串”就可登陆。

前端要这样搞,那么所有的密码相关接口,包括注册,登陆,重置密码等接口操作,必须保持统一。然而这样会导致很大的开发心智负担。假如现在需要另一个团队开发配套的管理后台,这个团队并不了解之前的前端加密操作,那么在涉及到“密码”的功能时,可能会出现非常诡异的 bug. 我们曾经遇到过一个需求,后台管理员生成一段随机字符串重置指定用户的密码,并自动通过邮件发送该密码给用户。而管理后台并不是前端团队开发的,试想如果前端有这个加密操作,而这个信息并没有同步到管理后台的团队,那么会发生什么。

528070506 回复

日志系统不局限于 Rails,内部网络各种复杂链路均有可能记录请求日志

其实还是要问前端:他们这样做到底是想实现什么样的效果,解决什么样的问题。也许他们担心的问题早就有成熟稳健的解决方式了。

hellorails 回复

好的 受教了

Rei 回复

好的👌

前端作为接口使用者,在接口设计上没有话语权,就这样。

前端为了提防后端掐脖子 立志自主研发一套加密系统

应该是安全部门的要求,前几年开始就都要求增加前端加密了。

处理也简单,后端提供 pubkey ,前端使用 JSEncrypt 加密一下就好了。

(前端无秘密)

hjleochen 回复

这种的可以接受,主要是前端想控制,不让后端去解密后存储

528070506 回复

后端不解密再加密还不如传没加密的后端直接加密的

用户密码只是安全的一部分,其他信息就不重要了吗?例如,手机号,年龄,性别,订单,支付信息等等... 为什么这些信息不需要加密呢?如果要加密,那就是把 HTTPS 重新实现了一遍。不要搞“局部优化”。

首先 MD5 是摘要算法,不叫加密

有 https 的话 这种加密就是脱裤子放屁,没 https 的话,https 都没有说什么安全呢

daimeng 回复

正常不应该存用户的明文密码啊

在 Ruby 的前后端分离架构中,用户密码的加密问题通常由后端处理。前端负责收集用户输入的信息,但为了确保安全性,密码加密应在后端进行。后端处理包括使用安全的加密算法对密码进行哈希处理,确保数据在存储和传输过程中保持安全。这个问题已成为开发者的 top search,因为正确处理密码加密对保护用户隐私至关重要。

支持前端不加密。

通常都是前端做个 rsa 加密,后端解出来

前后端没有分离的时候,HTML Form 中的 password 栏位就是明文传输的。用上 HTTPS 以后,数据传输层就加密了。服务端无论如何是要使用密码明文来做验证的,发送请求前再 Hash 一下纯属多余。

<input type="password" id="password" name="password" required>

1. HTTP 请求中的数据传输(不安全)

假设表单中的用户名和密码分别为 user1password123,提交表单后的 HTTP 请求可能如下所示:

请求头

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29

请求体

username=user1&password=password123

在这个请求中,表单数据(usernamepassword)以明文形式传输。如果有人在数据传输过程中拦截了这个请求,他们可以直接读取用户名和密码。

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 时,即使有人截获了网络请求,他们看到的也只是加密后的数据,而无法直接读取用户的敏感信息。

29 楼 已删除
需要 登录 后方可回复, 如果你还没有账号请 注册新账号