强烈建议 嘉立创 登录强制使用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]