V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
gebishushu
V2EX  ›  问与答

用户密码是在前端加密后传输给后端保存 还是?

  •  
  •   gebishushu · 290 天前 · 1640 次点击
    这是一个创建于 290 天前的主题,其中的信息可能已经有所发展或是发生改变。

    还是先传输再到后端加密存数据库呢?

    2 个方式有啥优缺点没?

    15 条回复    2023-08-04 16:57:00 +08:00
    xmumiffy
        1
    xmumiffy  
       290 天前 via Android
    前段后端都做 hash
    chotow
        2
    chotow  
       290 天前 via iPhone   ❤️ 1
    贴一下前两天在另一个帖子下回复的内容……

    前端做校验,并在 UI 层限制弱密码。
    以哈希值的形式提交密码密到后端,可以避免后端环节中的明文泄漏(比如日志),并增强用户对服务的信赖度。
    除非有不可抗拒因素,否则必须使用 HTTPS 。

    用户端哈希,优点是可以避免明文密码在服务端出现,缺点是服务端无法判断是否是弱密码。
    如果我是用户,我更信赖用户端哈希的产品。
    tool2d
        3
    tool2d  
       290 天前   ❤️ 2
    这是 10 几年前 mysql 的上古协议,那时候很多协议都是明文传输,SSL 加密还没有开始大面积普及,客户端密码加密就成了关键。

    我觉得至少在密码传输上,mysql 做的挺好的。

    chotow
        4
    chotow  
       290 天前 via iPhone   ❤️ 1
    补充一下,用户端哈希过,不代表服务端就不需要再次哈希。
    服务端哈希是必须的,用户端哈希是推荐的。
    ysc3839
        5
    ysc3839  
       290 天前 via Android
    服务端 hash 是必须的,而且建议使用 argon2 等强 hash 算法。
    客户端也推荐算一次 hash ,用于避免用户隐私泄漏,可以使用 md5 sha1 等弱 hash 。
    gebishushu
        6
    gebishushu  
    OP
       290 天前
    @chotow
    @ysc3839
    @xmumiffy 感谢各位答疑解惑
    明白了,我两边都做加密
    cat
        7
    cat  
       290 天前
    虽然楼上说的确实都有道理,可是,比如 GitHub 之类的网站为啥都是将密码明文传给后端呢 🤔
    tool2d
        8
    tool2d  
       290 天前
    @cat 可能 github 老板的癖好,就是收集用户各种明文密码。
    kabob
        9
    kabob  
       290 天前
    我去年也有开贴问。里面的回答还挺多种角度的,可以参考一下: https://www.v2ex.com/t/854741
    lisxour
        10
    lisxour  
       290 天前
    @cat 可能是对于 https 来说,明不明文没啥大区别吧,一般都是登陆时向服务器请求临时公钥,rsa 加密传给后台,后台私钥解密得到密码,然后进行 hash 比对。
    yinmin
        11
    yinmin  
       290 天前 via Android
    @cat @gebishushu 商用系统一般都是启用 https 后传输明文密码(由 https 保护),服务器获得明文密码后加盐 hash ,然后保存到数据库的。
    DivineRapierH
        12
    DivineRapierH  
       290 天前
    以下节选自 https://crackstation.net/hashing-security.htm

    In a Web Application, always hash on the server

    If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user's browser with JavaScript, or should it be sent to the server "in the clear" and hashed there?

    Even if you are hashing the user's passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users' passwords in the user's browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users' passwords are never sent to the server, but it's not.

    The problem is that the client-side hash logically becomes the user's password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user's hash they could use it to authenticate to the server, without knowing the user's password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, they'll have immediate access to everyone's accounts without having to guess any passwords.

    This isn't to say that you shouldn't hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:

    - Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user's password.

    - Some web browsers don't support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn't.

    - You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user's salt. Don't do that, because it lets the bad guys check if a username is valid without knowing the password. Since you're hashing and salting (with a good salt) on the server too, it's OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.
    xdeng
        13
    xdeng  
       289 天前
    前端 hash(p,s) ---h,u,s---> 后端存 h,u,s
    wu67
        14
    wu67  
       289 天前
    有 https 其实问题不大, 直接明文传就行.

    另外上面说限制弱密码的, 我劝你不要多管闲事, 就是这种事干多了, 才会整出那种需要同时包含数字大小写字母和特殊符号的变态强制强度密码
    whileFalse
        15
    whileFalse  
       289 天前 via Android
    @chotow 信人不如信己,直接上密码生成器比较好
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5010 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 07:21 · PVG 15:21 · LAX 00:21 · JFK 03:21
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.