强烈建议 嘉立创 登录强制使用https
今天无聊看了下发现登录使用的是http这有很大的风险 建议强制使用https加密http不都这样。 styleno1 发表于 2015-4-21 11:07
http不都这样。
所以才建议，或者采用在本地对用户名和密码加密后上传 Vmao 发表于 2015-4-21 11:09
所以才建议，或者采用在本地对用户名和密码加密后上传
谢谢建议,非常有必要 不知道https会不会对服务器造成压力，淘宝京东都没有用https，百度也是不久前才用https 至少也要搞个MD5拿回去比较吧，直接明文传回去了{:sweat:} 看来数据库也是文明的呀，md5下多好 {:lol:} 必须用https， 不给坏人留任何机会 从截图看，似乎不是用不用HTTPS的问题，而是明文传密码的问题。。。 bbglx 发表于 2015-4-21 11:12
不知道https会不会对服务器造成压力，淘宝京东都没有用https，百度也是不久前才用https ...
淘宝的登录页面是加密的. 简单点，把密码用MD5处理一下就行了
网页通过JS做MD5 楼主你这是啥软件 这个的确需要改进 楼主你这是啥软件 bbglx 发表于 2015-4-21 11:12
不知道https会不会对服务器造成压力，淘宝京东都没有用https，百度也是不久前才用https ...
淘宝，京东都是HTTPS登陆。 bccdn 发表于 2015-4-22 09:05
淘宝，京东都是HTTPS登陆。
用普通电话说中文 vs 用保密电话说中文 vs 用普通电话说鸟语 vs 用保密电话说鸟语，考虑不懂鸟语只会中文的人来窃听。类比HTTP/HTTPS，明文/密文的组合。
用HTTPS，最大的意义应该在于基本确保用户始终是在和受信任的，已知的对方进行通信；链路加密是一个优秀的附加值。
HTTPS传明文依然是不足够安全的举动，因为服务器端可能明文保存密码不是？ https有不少额外开销，而且还要证书，12306到今天都还是自己签名的山寨证书。
11楼有道理
客户端javascript对密码和服务器发来的的随机数一起做MD5后提交，可防中间人偷看密码。 redroof 发表于 2015-4-21 12:17
简单点，把密码用MD5处理一下就行了
网页通过JS做MD5
别人抓包之后直接提交md5不是一样登录吗？ 使用https已经是大势所趋的了 第一步要把用户名及密码用非对称加密，不能明文传输。 dawanpi 发表于 2015-7-12 11:13
别人抓包之后直接提交md5不是一样登录吗？
每次生成登录页面带一个随机数就行了，
这样你就不能重放之前抓的包了 albert_w 发表于 2015-4-22 09:50
https有不少额外开销，而且还要证书，12306到今天都还是自己签名的山寨证书。
11楼有道理
12306完全有钱买个商业证书啊，明显应该是他们故意不这么干。
我是铁老大，我就要自己签发根证书！你都得相信我！凭什么要我花钱找老外的认证公司来给我发证书？ limeng 发表于 2015-4-21 11:10
谢谢建议,非常有必要
银行的网银一般会选择使用更加可靠的，国际通行的，口碑良好的大型证书机构。
个人网站、博客也有见过买证书用HTTPS的，一般选择性价比较高，价格低的。
我觉得嘉立创可以根据自己的需求选择一下。
以下说几个我见到过的价格应该比较合理的证书机构吧：
境外：
个人不建议选择VeriSign，VeriSign的OCSP认证服务器貌似在国内被屏蔽了，可能会导致网站加载时间很长。
COMODO: https://www.comodo.com/
GeoTrust旗下RapidSSL: https://www.rapidssl.com/
境内：
不要选择CNNIC (中国互联网信息中心)(因假证书事件，已被Firefox/Chrome撤销信任)、SRCA(铁道部自己搞的)、SFCA(中国金融认证，这个貌似只给银行和税务)。
沃通(国内小银行在用，例如上海银行)：https://www.wosign.com/ 02015678 发表于 2015-7-12 15:50
银行的网银一般会选择使用更加可靠的，国际通行的，口碑良好的大型证书机构。
个人网站、博客也有见过买 ...
不是证书的价格问题，而是服务器成本 以及IT开发的成本
比如 https://easyeda.com/ 整个站都是https， 这样服务器的性能得提高很多，成本高， 技术上有些历时原因只能用http的要改成https， 还有一些缓存问题。
但是，jlc至少要在关键部位部署https
JLC的IT部门的战斗力是不错的。 楼上建议不错 redroof 发表于 2015-7-12 14:54
每次生成登录页面带一个随机数就行了，
这样你就不能重放之前抓的包了
那这个随机数是客户端还是服务器生成？如何传输这个随机数？ 那些提议用md5验证的。
这么搞，明文传输的就是md5，那么服务器也得用md5比较。到头来md5其实还是认证凭据，和密码明文并没有两样。只要有md5，不需要明文也可以登陆，让网页不计算md5直接发我输入的md5值就好了。因此并不能解决被抓包然后冒名登陆的问题。最多就是解决了在嘉立创泄露了不会扩散到其他网站的账号。
因此用https是最保险的方案。 diyjack 发表于 2015-7-12 16:00
不是证书的价格问题，而是服务器成本 以及IT开发的成本
比如 https://easyeda.com/ 整个站都是https，...
是得承认，对一个网站来说，买证书的钱并不算什么。
PS. 你的那个EasyEDA的网站看起来很不错。 lllaaa 发表于 2015-7-12 20:31
那些提议用md5验证的。
这么搞，明文传输的就是md5，那么服务器也得用md5比较。到头来md5其实还是认证凭据 ...
当然要加盐，例如用户打开登录页面时服务器在脚本里放一个随机串，提交之前先将密码做一次MD5，然后加上这个随机串再做一次MD5，同时服务器也用保存在数据库的MD5加上这个随机串做一次MD5来比较，这样就可以保证每次传输的密码都是不同的，杜绝了回放攻击。 dawanpi 发表于 2015-7-12 18:01
那这个随机数是客户端还是服务器生成？如何传输这个随机数？
服务器生成，就是gzhuli说的那个流程。这是很常用的做法 gzhuli 发表于 2015-7-12 23:08
当然要加盐，例如用户打开登录页面时服务器在脚本里放一个随机串，提交之前先将密码做一次MD5，然后加上 ...
咕大师，在加了随机串的情况下，如果要做记住密码的功能怎么办？ 好建议！安全第一！ redroof 发表于 2015-7-13 09:31
服务器生成，就是gzhuli说的那个流程。这是很常用的做法
那只是存储到数据库的时候防止DBA反查md5获取用户密码的，传输的问题还没解决呢？ gzhuli 发表于 2015-7-12 23:08
当然要加盐，例如用户打开登录页面时服务器在脚本里放一个随机串，提交之前先将密码做一次MD5，然后加上 ...
脚本用http传输吗？有人截获脚本里面的随机数怎么办？ redroof 发表于 2015-7-12 15:07
12306完全有钱买个商业证书啊，明显应该是他们故意不这么干。
我是铁老大，我就要自己签发根证书！你都得 ...
绝对没那么简单。 本帖最后由 redroof 于 2015-7-13 12:11 编辑
dawanpi 发表于 2015-7-13 10:06
脚本用http传输吗？有人截获脚本里面的随机数怎么办？
截获就截获了算了，没任何关系
这个随机数只有本次有效，例如跟你的源IP和端口有关，或者跟当前时间有关，用过了很快就作废了。
等下次登录的时候，见到的登录页里面的随机数已经变了。
所以你之前截获的MD5就没意义了。
嘉立创-高先生 发表于 2015-7-13 09:41
咕大师，在加了随机串的情况下，如果要做记住密码的功能怎么办？
没区别，
你之前正确登录得到的随机数SessionID，可以放在cookie里面，服务器自己也保留一份存在服务器的数据库。
在记住密码的有效期内，见到含有之前成功登录的cookie，从服务器数据库里面查出对应的用户名，直接放过。
也就是说记住密码的时候直接绕过了登录过程。阿莫这里就是这样做的。
嘉立创-高先生 发表于 2015-7-13 09:41
咕大师，在加了随机串的情况下，如果要做记住密码的功能怎么办？
要安全就是得牺牲点东西，反正银行、支付宝这些网站我没见过可以记住密码的。
一定要做的话一般是做成自动登录，也就是用cookie的方式保存，而不是靠浏览器的记住密码功能，这个论坛的登录也是这样处理的。 dawanpi 发表于 2015-7-13 10:06
脚本用http传输吗？有人截获脚本里面的随机数怎么办？
每次的随机数都不一样，每次发送的MD5都不一样，你任何时候截下来的MD5都无法用于下一次登录。
当然MD5只是举个栗子，现在已经不够安全了，至少应该用SHA1。 redroof 发表于 2015-7-13 12:09
截获就截获了算了，没任何关系
这个随机数只有本次有效，例如跟你的源IP和端口有关，或者跟当前时间有关 ...
那要是可以改脚本的内容呢？浏览器里面算md5的脚本也要从服务器获取的。攻击者完全可以截获随机数后，把脚本功能改成发送明文密码，然后自己再用原来的脚本和随机数算出“加密”后的密码发给服务器，这样就不知不觉地获得用户密码。 gzhuli 发表于 2015-7-13 12:26
每次的随机数都不一样，每次发送的MD5都不一样，你任何时候截下来的MD5都无法用于下一次登录。
当然MD5只 ...
请参考我40楼的回复。虽然这种攻击方式较单纯地监听要来的复杂，但考虑到jlc这个系统的特点（用户有预存款），这样的攻击还是可能发生的。所以考虑到被保护系统的安全等级，别说SHA1了，SHA512都不能保证安全。
算法本身是安全的，它们很多都在数学上被证明是安全的，然而实际中还是有这样那样的漏洞，不得不说对算法的不当使用产生了很多漏洞。 dawanpi 发表于 2015-7-13 12:28
那要是可以改脚本的内容呢？浏览器里面算md5的脚本也要从服务器获取的。攻击者完全可以截获随机数后，把 ...
你这不是简单的中途抓包分析了，而是完整的中间人攻击。普通的加密保护都不防这个。
想彻底的防住中间人攻击，只能老老实实用HTTPS，
而且要特别注意检查服务器的证书是不是可信的（中间人仍然可以替换证书！）。
dawanpi 发表于 2015-7-13 12:32
请参考我40楼的回复。虽然这种攻击方式较单纯地监听要来的复杂，但考虑到jlc这个系统的特点（用户有预存 ...
我们上面说的MD5验证多数是给论坛什么的用的。{:lol:} 只要不牵扯钱的问题，一般这种安全性已经够了。
有存钱的场合，还是直接上HTTPS吧。
多花服务器资源就是了。 dawanpi 发表于 2015-7-13 12:32
请参考我40楼的回复。虽然这种攻击方式较单纯地监听要来的复杂，但考虑到jlc这个系统的特点（用户有预存 ...
你的脑洞是越来越大了，前面只是说截取，后面又变成修改，这已经是MITM攻击了，HTTPS又可以增加点难度，但还是无法完全避免，例如你的浏览器装了12306和CNNIC的流氓证书，他们完全可以签发一个www.sz-jlc.com的证书来欺骗用户，这样用户被截取通信都是神不知鬼不觉的。
再往下说的话，世界上也没有什么系统是绝对安全的了。 redroof 发表于 2015-7-13 12:42
你这不是简单的中途抓包分析了，而是完整的中间人攻击。普通的加密保护都不防这个。
想彻底的防住中间人 ...
要考虑所需要的防护等级的，对于jlc这种应用场景，普通的https足够了，你说的那种证书级别的中间人攻击，不是一般人或者团体能做得到的，呃{:shutup:} {:shutup:} {:shutup:} {:shutup:} {:shutup:} redroof 发表于 2015-7-13 12:44
我们上面说的MD5验证多数是给论坛什么的用的。 只要不牵扯钱的问题，一般这种安全性已经够了。
有 ...
根本就是两回事，MD5是保证密码不会明文离开你的电脑，银行和支付宝的加密控件也干同样的事，即使他们已经有HTTPS。 gzhuli 发表于 2015-7-13 12:46
你的脑洞是越来越大了，前面只是说截取，后面又变成修改，这已经是MITM攻击了，HTTPS又可以增加点难度， ...
45楼已经更正。
看来我的意思没说明白，我一直想说明采取什么防护措施要看被防护的系统本身需求，而不是绝对的安全。
而https对mitm带来的难度绝不是你说的那个方式带来的难度能比的。 不用HTTPS也可以.把控件改一下就行了.HTTPS效率有点低了. sibtck 发表于 2015-7-13 13:13
不用HTTPS也可以.把控件改一下就行了.HTTPS效率有点低了.
对于现在的CPU来说，HTTPS开销已经不算大，所以越来越多网站全站启用HTTPS。 dawanpi 发表于 2015-7-13 12:47
要考虑所需要的防护等级的，对于jlc这种应用场景，普通的https足够了，你说的那种证书级别的中间人攻击， ...
是你说要防别人替换你的js加密库，
能替换js的人也就是能做中间人攻击了，同样也能替换https的证书。
还好没注册立创商城的账户。 gzhuli 发表于 2015-7-13 12:49
根本就是两回事，MD5是保证密码不会明文离开你的电脑，银行和支付宝的加密控件也干同样的事，即使他们已 ...
没错，有https还是要做js加密。
但如果不是要防上面的人说的中间人攻击，用js在本地加密已经足够了。普通的论坛什么的，大部分都只做到这一步。 redroof 发表于 2015-7-13 13:40
是你说要防别人替换你的js加密库，
能替换js的人也就是能做中间人攻击了，同样也能替换https的证书。
...
能替换http下的js只要拿下路由器就可以了，替换https证书？拿下路由器是可以替换，但替换成什么证书？自签？浏览器不会信任的。要是有被浏览器默认信任的根证书，谁还会去干那种事？ 确实，http倒不要紧吧，主要是明文传输太不安全了 gzhuli 发表于 2015-7-12 23:08
当然要加盐，例如用户打开登录页面时服务器在脚本里放一个随机串，提交之前先将密码做一次MD5，然后加上 ...
刚刚又想到一个问题，对于这种流程，如何处理新用户注册时第一次设置密码？想了很久也没想明白，但感觉用一些很复杂的方式可以实现，“储存盐”之类的。 dawanpi 发表于 2015-7-13 18:09
刚刚又想到一个问题，对于这种流程，如何处理新用户注册时第一次设置密码？想了很久也没想明白，但感觉用 ...
非对称加密。 dawanpi 发表于 2015-7-13 14:06
能替换http下的js只要拿下路由器就可以了，替换https证书？拿下路由器是可以替换，但替换成什么证书？自 ...
根证书，跟铁老大一样，让人装一个你自己签的根证书就行了^_^ redroof 发表于 2015-7-13 18:52
根证书，跟铁老大一样，让人装一个你自己签的根证书就行了^_^
这就有难度了，拿下路由器后还要做“别的工作”才能装下证书。不过这已经要歪楼了。。。 gzhuli 发表于 2015-7-13 18:31
非对称加密。
好吧。。。不过散列函数的这种用法还是第一次见，也学到东西了{:handshake:} dawanpi 发表于 2015-7-13 20:23
好吧。。。不过散列函数的这种用法还是第一次见，也学到东西了...
这种叫做Challenge-Response验证，应用很广泛的，例如Windows的网络认证协议NTLMv2和邮件系统的CRAM-MD5。 收获颇丰啊
从一个建议贴演变为学习贴，这真是神一样的剧情走向…… rsa bbglx 发表于 2015-4-21 11:12
不知道https会不会对服务器造成压力，淘宝京东都没有用https，百度也是不久前才用https ...
事情跟进, 淘宝现在已经支持全站 https 加密浏览. gzhuli 发表于 2015-7-13 12:19
要安全就是得牺牲点东西，反正银行、支付宝这些网站我没见过可以记住密码的。
一定要做的话一般是做成自 ...
用cookie记录的话，如果cookie被获取了，是不是就可以回放攻击了？ 本帖最后由 gzhuli 于 2015-7-21 13:12 编辑
嘉立创-高先生 发表于 2015-7-21 11:58
用cookie记录的话，如果cookie被获取了，是不是就可以回放攻击了？
其实无论是否保存密码，只要截取到登录后的session cookie也就相当于拿到登录身份了，不过不知道原密码还是无法做修改密码等操作的。 gzhuli 发表于 2015-7-21 13:10
其实无论是否保存密码，只要截取到登录后的session cookie也就相当于拿到登录身份了，不过不知道原密码还 ...
获取session cookie，要在路由器上操作，这个要拿下路由器。
但是，如果是存储在浏览器上，这个很容易被获取 嘉立创-高先生 发表于 2015-7-21 13:31
获取session cookie，要在路由器上操作，这个要拿下路由器。
但是，如果是存储在浏览器上，这个很容易被 ...
要获取浏览器储存的cookie要先获得电脑的控制权，获得了电脑的控制权还愁密码拿不到么……
页:
[1]