我看了一下,workerman 官网登录的时候,密码是明文直接向后台发送的,这不太让人放心,请大佬改下,客户端先不可逆加密处理一下再发送到后端,让使用者更放心,谢谢。
担心什么问题
担心会不会明文存储我的密码啊
不会明文存,我要你密码也没用。
开什么玩笑,站长要你的数据还需要密码?你也是开发不会这么天真吧~
你才天真,我不是怀疑站长的人品,我只是说这样理论上存在不安全的问题,我的账号是邮箱,我的密码直接明文通过http请求发送到服务器,这不是安全的做法吧,总让人感觉不专业。
用户名和密码都是ssl加密传输的,怎么就明文传输了?
如果连接的是别人的网络,别人通过代理的方式是能拿到https的数据,他应该是担心这一点把,别乱连别人的网络和别安装别人的证书就行了。
链接别人的网络,请求包被劫持拿到的也是ssl加密的数据,别安装别人的证书倒是关键
诱导用户安装伪造的证书成功率基本为零,浏览器会飘红警告的,根本用不了
题主说是明文传输,实际上是加密的,题主可能不太懂
浏览器飘红警告,但还是能用的,点击无视风险继续访问就可以了,这种就不用安装证书,也能正常访问的,也算是特殊情况下的风险吧。
https是加密传输的,所谓的"明文"其实也只有你自己能看到,别人截取你的请求看到的也是加密后的,不过各大平台在传输的时候确实是加密的,主要是防止你本地的木马之类的
我说的不是传输过程中的问题
这其实本质是个信任问题,关键在于后端怎么处理密码。 哪怕你登录时用不可逆算法加密后再提交,但你输入账号和密码那一刻,仍然是明文存在内存中的。如果站点真的要作恶,完全可以在混淆后的 JS 里提前截获明文,再加密后发送,外部是没法察觉的。 难不成你还要对每个站点都去逆向 JS 验证它有没有偷偷干这种事? 所以归根结底就是一句话:如果你不信任这个站,就别用这个站。
另外补充一点:现在的浏览器基本上有生成随机密码的功能,在注册的时候直接随机生成就行,每个网站的密码都不一样,这样子就不用担心密码泄露被人拿去撞库了。
我说的是一个专业的问题,专业的网站应该有最基本的安全常识。如果有面试官问你如何保证用户信息的安全性,你说如果用户不信任这个站,就别用这个站。你不感觉很无厘头吗?
另外你说的每个网站的密码都不一样,现在这么多系统,你每个网站都用一个密码,你记性这么好吗?
用KeePass, 1Password,BitWarden之流,只需记住一个密码
你看他的回复,他是担心服务器后端的密码是明文储存的。就是说担心的是数据表中存的是明文密码,而不是密码的哈希或其他处理后的字符串。 其实我感觉没必要纠结太多,直接自动保存的密码就得了。
纠正你下,用户名密码是ssl加密传输的,不是明文传输。
系统保证密码ssl加密传输和服务端加密存储就可以保证密码不会被泄露,作为一个问答系统这个安全性已经足够了。
至于你浏览器是否被黑客控制不是我考虑的事情。如果你浏览器被黑客控制,即使我把密码加密传输也没用,黑客只需要简单的读取表单内容或者监听键盘就可以了,这种情况下在ssl加密的基础上再加密一次基本上没有什么意义。
他根本就没搞清楚ssl传输和浏览器控制台看到的“明文”之间的区别,所谓的"明文"也仅仅是在浏览器层面,你中木马了怎么加密都没用,如果请求被劫持拦截,看到的也是ssl加密的
楼主纠结的好像不是明文传输的问题,可能他在输入密码时,因为能直观的看到未加密的密码,加上他在其它站点可能都是用的同一个密码,从安全角度,这会让他(或者一些不太懂的使用者)感觉到不安。密码加密,从感官上来说,'显得'更专业。
我感觉他的意思是不应该让后端拿到我输入的密码,而应该直接拿到md5或hash以后的字符串。(说白了是在信任链中的服务器能拿到明文秘钥的的不信任。
首先,浏览器中的使用随机建议的加强密码已经足够。 其次,出于信任问题,我相信站长不会在后端储存明文密码,业界普遍会对密码进行一次哈希或者md5或者sha1.而且甚至会给每个人的密码加一个字段,随机盐,来保证每个人即使密码相同也会导致生成的密码不同,给逆向穷举带来指数级难度增长。 我感觉你担心的不是明文传输,而是后端数据表的密码字段是设计吧。我理解你担心的事情,但是我感觉对这个事情敏感的就不会使用多站同密码;不敏感的也不会提出这个问题。我认为对于这么一个问答网站没有问题。
其实我觉得,有疑问不明白发帖没问题,但是因为自己不懂就直接盖棺定论那就不合适了。
你无非就是想加多一套前后端通用的加密而已,你自己实现就是了。本身ssl传输就没啥问题。
应该说得是前端传递参数进行加密, 后端进行解密对数据进行对比吧
哈哈,笑死我了。 请先了解一下https
抛开https再客户端加密再传输就能保证安全?这不是掩耳盗铃吗?
我不知道你有什么可笑的,我一直强调我说的不是传输过程中的问题,你怎么就看不懂呢?就一直往 https 上去扯?https 不是传输过程中的事儿?
就算你不是说https的事情 世界上国际大站明文传输密码的多如牛毛,其中不乏google facebook 你却在这里鸡蛋挑骨头 你还说不是怀疑站长的人品。那么我都不知道你发文的目的究竟是为何。
github登录也是明文传输的,这么没看见它出过事呢
这是职业病?谁正常使用的时候会打开调试台看请求的?还是看登陆请求,有你密码了不用看,没你密码看了也没用。一个论坛还要要求等保了?
三级等保要求
你可能对明文传输有一定的误解,实际上即使你使用 阿里云的登录输入的密码也是原内容发送的,有ssl的协议只要你不安装三方证书你传输过程的内容是足够安全的
阿里云
就像老板的一个妙想。 老板:小王我最近按了F12,看见表单提交的密码是明文啊,很不安全。 我:好的老板马上处理。然后我把密码再提交的时候用base64使用了5次。 老板:你看这不就好了,虽然我提交了密码你看谁能看懂。 我:是是。 老板:你的技术不行啊。再这样降你工资。 我:。。。。。(我心里)你提交密码只能你自己能看到。别人看到是什么鬼?别人有密码还需要注意不注意你是明文?你给工资你说的都对。
担心什么问题
担心会不会明文存储我的密码啊
不会明文存,我要你密码也没用。
开什么玩笑,站长要你的数据还需要密码?你也是开发不会这么天真吧~
你才天真,我不是怀疑站长的人品,我只是说这样理论上存在不安全的问题,我的账号是邮箱,我的密码直接明文通过http请求发送到服务器,这不是安全的做法吧,总让人感觉不专业。
用户名和密码都是ssl加密传输的,怎么就明文传输了?
如果连接的是别人的网络,别人通过代理的方式是能拿到https的数据,他应该是担心这一点把,别乱连别人的网络和别安装别人的证书就行了。
链接别人的网络,请求包被劫持拿到的也是ssl加密的数据,别安装别人的证书倒是关键
诱导用户安装伪造的证书成功率基本为零,浏览器会飘红警告的,根本用不了
题主说是明文传输,实际上是加密的,题主可能不太懂
浏览器飘红警告,但还是能用的,点击无视风险继续访问就可以了,这种就不用安装证书,也能正常访问的,也算是特殊情况下的风险吧。
https是加密传输的,所谓的"明文"其实也只有你自己能看到,别人截取你的请求看到的也是加密后的,不过各大平台在传输的时候确实是加密的,主要是防止你本地的木马之类的
我说的不是传输过程中的问题
这其实本质是个信任问题,关键在于后端怎么处理密码。
哪怕你登录时用不可逆算法加密后再提交,但你输入账号和密码那一刻,仍然是明文存在内存中的。如果站点真的要作恶,完全可以在混淆后的 JS 里提前截获明文,再加密后发送,外部是没法察觉的。
难不成你还要对每个站点都去逆向 JS 验证它有没有偷偷干这种事?
所以归根结底就是一句话:如果你不信任这个站,就别用这个站。
另外补充一点:现在的浏览器基本上有生成随机密码的功能,在注册的时候直接随机生成就行,每个网站的密码都不一样,这样子就不用担心密码泄露被人拿去撞库了。
我说的是一个专业的问题,专业的网站应该有最基本的安全常识。如果有面试官问你如何保证用户信息的安全性,你说如果用户不信任这个站,就别用这个站。你不感觉很无厘头吗?
另外你说的每个网站的密码都不一样,现在这么多系统,你每个网站都用一个密码,你记性这么好吗?
用KeePass, 1Password,BitWarden之流,只需记住一个密码
你看他的回复,他是担心服务器后端的密码是明文储存的。就是说担心的是数据表中存的是明文密码,而不是密码的哈希或其他处理后的字符串。
其实我感觉没必要纠结太多,直接自动保存的密码就得了。
纠正你下,用户名密码是ssl加密传输的,不是明文传输。
系统保证密码ssl加密传输和服务端加密存储就可以保证密码不会被泄露,作为一个问答系统这个安全性已经足够了。
至于你浏览器是否被黑客控制不是我考虑的事情。如果你浏览器被黑客控制,即使我把密码加密传输也没用,黑客只需要简单的读取表单内容或者监听键盘就可以了,这种情况下在ssl加密的基础上再加密一次基本上没有什么意义。
他根本就没搞清楚ssl传输和浏览器控制台看到的“明文”之间的区别,所谓的"明文"也仅仅是在浏览器层面,你中木马了怎么加密都没用,如果请求被劫持拦截,看到的也是ssl加密的
楼主纠结的好像不是明文传输的问题,可能他在输入密码时,因为能直观的看到未加密的密码,加上他在其它站点可能都是用的同一个密码,从安全角度,这会让他(或者一些不太懂的使用者)感觉到不安。密码加密,从感官上来说,'显得'更专业。
我感觉他的意思是不应该让后端拿到我输入的密码,而应该直接拿到md5或hash以后的字符串。(说白了是在信任链中的服务器能拿到明文秘钥的的不信任。
首先,浏览器中的使用随机建议的加强密码已经足够。
其次,出于信任问题,我相信站长不会在后端储存明文密码,业界普遍会对密码进行一次哈希或者md5或者sha1.而且甚至会给每个人的密码加一个字段,随机盐,来保证每个人即使密码相同也会导致生成的密码不同,给逆向穷举带来指数级难度增长。
我感觉你担心的不是明文传输,而是后端数据表的密码字段是设计吧。我理解你担心的事情,但是我感觉对这个事情敏感的就不会使用多站同密码;不敏感的也不会提出这个问题。我认为对于这么一个问答网站没有问题。
其实我觉得,有疑问不明白发帖没问题,但是因为自己不懂就直接盖棺定论那就不合适了。
你无非就是想加多一套前后端通用的加密而已,你自己实现就是了。本身ssl传输就没啥问题。
应该说得是前端传递参数进行加密, 后端进行解密对数据进行对比吧
哈哈,笑死我了。
请先了解一下https
抛开https再客户端加密再传输就能保证安全?这不是掩耳盗铃吗?
我不知道你有什么可笑的,我一直强调我说的不是传输过程中的问题,你怎么就看不懂呢?就一直往 https 上去扯?https 不是传输过程中的事儿?
就算你不是说https的事情
世界上国际大站明文传输密码的多如牛毛,其中不乏google facebook 你却在这里鸡蛋挑骨头
你还说不是怀疑站长的人品。那么我都不知道你发文的目的究竟是为何。
github登录也是明文传输的,这么没看见它出过事呢
这是职业病?谁正常使用的时候会打开调试台看请求的?还是看登陆请求,有你密码了不用看,没你密码看了也没用。一个论坛还要要求等保了?
三级等保要求
你可能对明文传输有一定的误解,实际上即使你使用
阿里云
的登录输入的密码也是原内容发送的,有ssl的协议只要你不安装三方证书你传输过程的内容是足够安全的就像老板的一个妙想。
老板:小王我最近按了F12,看见表单提交的密码是明文啊,很不安全。
我:好的老板马上处理。然后我把密码再提交的时候用base64使用了5次。
老板:你看这不就好了,虽然我提交了密码你看谁能看懂。
我:是是。
老板:你的技术不行啊。再这样降你工资。
我:。。。。。(我心里)你提交密码只能你自己能看到。别人看到是什么鬼?别人有密码还需要注意不注意你是明文?你给工资你说的都对。