它在客户端是否值得哈希密码? [英] Is it worth hashing passwords on the client side

查看:100
本文介绍了它在客户端是否值得哈希密码?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我想放置一个登录系统时,我总是将给定密码的MD5与它在服务器端用户表中的值进行比较。



然而,我的一个朋友告诉我,一个清晰的密码可能会被网络软件嗅探到。



所以我的问题是:散列客户端的密码?是否比在服务器端散列它更好?

解决方案

基本上,你的朋友是对的。但是,简单地在客户端对密码进行哈希处理仅仅比将它作为纯文本提交给服务器更好。有人可以监听纯文本密码,当然也可以监听散列密码,并使用这些捕获的哈希来验证您的服务器。



这个问题,更安全的身份验证协议通常会跳过许多环节,以确保这样的重放攻击无法正常工作,通常情况下,允许客户端选择一串随密码一起散列的随机位,并且也清楚地向服务器提交。



在服务器上:




  • 随机生成几位
  • >
  • 将这些位(以明文形式)发送到客户端



在客户端:




  • 生成一些随机比特

  • 连接密码,服务器的随机比特和客户端随机比特

  • 生成上面的散列值

  • 将随机数据(以明文形式)和散列值提交给服务器


由于服务器知道它自己的随机信息以及客户端的随机位(它将它们作为明文),它可以执行基本相同的转换。这个协议可以确保,在这次会话中没有人听到后面的信息可以使用这些信息来错误地使用记录的信息进行验证(除非使用非常弱的算法......),只要双方每次都产生不同的噪声位手摇。



编辑所有这些都很容易出错,而且很难找到正确的东西(阅读:安全)。如果可能的话,考虑使用已经由知识渊博的人编写的认证协议实现(不像我!以上只是来自我前一段时间阅读的书​​的记忆。)你真的不想自己写这个通常。

When I want to put a login system in place, I always compare the MD5 of the given password with its value in the users table on the server side.

However, a friend of mine told me that a "clear" password could be sniffed by a network software.

So my question is: is it a good idea to hash the password on the client side? Is it better than hashing it on the server side?

解决方案

Basically, your friend is right. But simply hashing the password on the client side is only just better than submitting it as plain text to the server. Someone, who can listen for your plain text passwords is certainly also able to listen for hashed passwords, and use these captured hashes him/herself to authenticate against your server.

For this matter, more secure authentication protocols usually jump through a number of hoops in order to make sure, that such a replay attack cannot work, usually, by allowing the client to select a bunch of random bits, which are hashed along with the password, and also submitted in the clear to the server.

On the server:

  • generate a few bits of random
  • send these bits (in clear text) to the client

On the client:

  • generate a few random bits
  • concatenate password, the server's random bits and the client random bits
  • generate hash of the above
  • submit random data (in clear text) and hash to the server

As the server knows its own random information as well as the client's random bits (it got them as clear text), it can perform essentially the same transformation. This protocol makes sure, that nobody listening in this conversation can use the information later to authenticate falsely using the information recorded (unless a very weak algorithm was used...), as long as both parties generate different "noise bits" each time, the hand shake is performed.

Edit All of this is error prone and tedious and somewhat hard to get right (read: secure). If ever possible, consider using authentication protocol implementations already written by knowledgeable people (unlike me! The above is only from memory of a book I read some time ago.) You really don't want to write this yourself usually.

这篇关于它在客户端是否值得哈希密码?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆