《2022年用户密码的加密存储与传输定义 .pdf》由会员分享，可在线阅读，更多相关《2022年用户密码的加密存储与传输定义 .pdf（7页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、用户密码的加密存储与Python 示例在各种线上应用中，用户名密码是用户身份认证的关键，它的安全重要性不言而喻。一方面，作为保护用户敏感数据的“钥匙”，一旦被破解，系统将敞开大门完全不设防。另一方面，密码这把“钥匙”本身就是非常重要的数据：用户经常会在多个应用中使用相同或相似的密码。一旦某一个应用的密码被破解，很可能，坏人就因此而掌握了用户的“万能钥匙”，这个用户的其它应用也相当危险了。这篇博文就重点讨论对于密码原文本身的存储的安全性考虑，而系统自身的安全性不在此文的范围之内。那么，对于如此重要的用户密码，究竟该怎样在系统中存储呢？“君子不立危墙”，对于用户密码这个烫手的山芋，一个极端的选择是
2、系统完全不接触密码，用户的身份认证转而交由受信任的第三方来完成，比如OpenID 这样的解决方案。系统向受信任的第三方求证用户身份的合法性，用户通过密码向第三方证明自己的身份。这样，密码完全不经过系统，系统也就不用绞尽脑汁保证密码的安全了。这个作法对用户来说还有个额外的好处：再也不用为每个应用注册帐号了，同一个OpenID 就可以登录所有支持 OpenID 的系统了。好虽好，可在今天这样一个各自为战，划分地盘的网络战国时代，作为一个自主的系统，自己的用户资源居然不能掌握在自己的手上，而要与别人分享，甚至“受制于人”，这多少有点让人难以接受。（据称，现在全球有27000 个 Web Site 支
3、持OpenID 登录，虽然还在持续增长中，但在茫茫“网海“中无疑还是属于小众）好吧，既然网络大同时代还没来临，系统还是要自己负责用户的认证，那密码该如何存储呢？按照安全性由低到高，有这样几种选择：密码名文直接存储在系统中这种方法下密码本身的安全性比系统本身还低，系统管理员可以直接看到所有用户的密码名文。除非你是做恶意网站故意套取用户密码，否则不要用这种方式。密码名文经过对称转换后再存储的这跟上面的直接明文的方式没有多少本质改进，任何知道或破解出转换方法的人都可以通过相应的逆转换得到密码原文。密码经过对称加密后再存储用户密码明文的安全性等同于加密密钥本身的安全性。对称加密的密钥会同时用于加密和解
4、密，所以它会直接出现在加密代码中，破解的可能性也相当大。而且，知道密钥的人很可能就是系统管理员，所有人的密码原文他都能算出来。密码经过非对称加密后再存储密码的安全性等同于私钥的安全性。密码明文经过公钥加密，而要还原名文，则必须要私钥才行。因此只要保证私钥的安全，密码名文就会安全。私钥可以由某个受信任的人或机构来掌管，普通的身份验证只需要用公钥加密就可以了。实际上，这也是HTTPS/SSL 的理论基础。这里的关键是私钥的安全，如果私钥泄露，那名师资料总结-精品资料欢迎下载-名师精心整理-第 1 页，共 7 页 -密码名文就危险了。以上 4 种方法的一个共同特点是可以从存储的密码形式还原到密码的明
5、文。如果你注册了一个网站，当你忘了密码后，网站可以很贴心地通过你注册的email 告诉你原来的密码是什么，那么，它肯定就是用了上面的4种方法中的一种了。这时候你就得小心了：既然网站能知道你的密码明文，那网站的工作人员就可能知道你的密码明文，任何攻入了这个网站的人也有了还原你密码明文的可能，甚至于，网站本身就是恶意的钓鱼网站。所以，最好的保存密码的方式是以连系统自己都不可能还原明文的方式来保存，也就是常用的利用哈希算法的单向性来保证明文的信息以不可还原的有损方式进行存储。这大类的各个方式按安全性由低到高为：使用自己独创的哈希算法对密码进行哈希，存储哈希过的值。哈希算法的要求很高，一般来说，自己独
6、创的哈希算法肯定没有公开的经过时间检验的算法质量高，除非你是天才。使用 MD5 或 SHA-1 进行哈希然很存储。MD5 和 SHA-1 已经被破解。这意味着虽然不能还原密码原文，但很容易找到一个能同样生成相同哈希值的密码原文的碰撞。还有一点，这两个算法相对速度较快，这就意味着对暴力破解来说消耗的资源少。所以建议不要使用它们。直接使用更安全的SHA-256 等成熟算法。这个只是在一定程度上增加了暴力破解的时间。如果遇到简单密码，通过常用密码字典的暴力破解法，很快就可以还原密码原文。加入了随机Salt 的哈希算法。密码原文（或进过hash 后的值）和随机生成的salt 字符串混淆，然后再进行ha
7、sh，最后把 hash 值和salt 值一起存储。验证密码的时候，只要用存储的salt 值再做一次相同的hash 再与存储的hash 值比较就可以了。这样一来，就算用户使用简单的密码，但进过Salt 混淆过的字符串就是一个很不常见的串，一般不会出现在密码常用字典中。Salt 的程度越长，暴力破解的难度就越大。具体的hash 过程也可以进行若干次叠代，虽然hash 叠代会增加碰撞率，但也增加暴力破解的资源消耗。最后，就算真被暴力破解了，被破解的也只是这个随机salt 混淆过的密码，破解者不能用它来登录该用户的其它应用（如果其它应用也用了自己的随机salt）上面这几种方法都不可能还原密码的明文，这
8、意谓着，就算是系统管理员也不知道密码原文。这也意谓着，这个世界上只有你知道你自己的密码。网站再也没有办法提醒你原来的密码是什么了。对于那些真的忘了自己密码的用户，网站可以提供一个重置密码的功能，帮用户随机生成一个临时密码，让用户通过这个临时密码来登录到系统中重新设置新的密码。下面的python 程序就是使用了salt hash 来加密密码明文import os名师资料总结-精品资料欢迎下载-名师精心整理-第 2 页，共 7 页 -from hashlib import sha256 from hmac import HMAC def encrypt_password(password,salt
9、=None):Hash password on the fly.if salt is None:salt=os.urandom(8)#64 bits.assert 8=len(salt)assert isinstance(salt,str)if isinstance(password,unicode):password=password.encode(UTF-8)assert isinstance(password,str)result=password for i in xrange(10):result=HMAC(result,salt,sha256).digest()return sal
10、t+result这里先通过标准随机库生成64 bits 的随机salt，使用了标准的SHA-256 做为基本的hash 算法，使用标准HMAC 算法作为salt 混淆。并且进行了10 次混淆hash。最后将salt 和名师资料总结-精品资料欢迎下载-名师精心整理-第 3 页，共 7 页 -hash 结果一起返回。使用的方法很简单：hashed=encrypt_password(secret password)下面是验证函数def validate_password(hashed,input_password):return hashed=encrypt_password(input_passw
11、ord,salt=hashed:8)它直接使用encrypt_password 来对待检验的密码进行相同的salt 混淆hash 并与出口存储的值比较。使用示例：assert validate_password(hashed,secret password)上面的实现虽然只有简单几行，但借助了python 标准库的力量，已经是一个可用于生产环境的高安全的密码存储方案了。总结一下用户密码的存储：如果可能，不要存任何密码信息让别人来帮你做事（OpenID）如果非要自己认证，也只能存有损的密码信息。通过单向hash 和 salt 来保证密码明文只存在用户手中绝对不能存可还原密码原文的信息。如果因为种
12、种原因一定要可还原密码原文，请使用非对称加密，并保管好私钥密码传输问题上文 讲了密码在系统中的存储问题，接下来就简单说说密码在进入系统之前的传输问题。一般在线系统，密码的传输要经过下面几个步骤：用户在网络浏览器上输入原始密码：人 键盘 浏览器内存原始密码做一定的转换：内存中的原始密码 内存中的转换后的密码转换后的密码在线上传输：内存中转换后的密码 网络 系统 nnn 这其中的每一步都有可能导致原始密码的泄露，也有相应的应对之法应对。1 输入原始密码2 原始密码的转换3 转换后的密码的在线传输4 常用服务的密码传输方法5 小结名师资料总结-精品资料欢迎下载-名师精心整理-第 4 页，共 7 页
13、-6 其它7 2010年8月 6号更新1 输入原始密码在一个存储和传输每个环节都很安全的环境下，最危险的就是用户输入原始密码这第一步。常用的攻击方法包括：偷看输入密码值在公共场合输入密码很容易被人故意偷看，例如使用ATM 机取款的时候。一般输入密码的字符明文用*号代替，这种做法就是为了保证密码明文不被肉眼偷窥。不过这样以来，用户也不能直接看到自己输入的密码是否正确。iPhone 在这点上做了小改进，在输入一个密码字符时先显示明文，过大约0.5 秒再转成*显示，鉴于使用iPhone 虚拟键盘输入时，按错字母的概率还是比较高的，这个折中也是在可用性和安全性上做了妥协。有些系统，为了最大限度的防偷窥
14、，在输入密码的时候屏幕不输出任何东西，比如Unix/Linux 的 Console 登录。这样一来，就连输入的密码长度都看不出来。当然，在设置新密码的时候，相应的，一般也要通过输入两遍密码来保证没有任何输入错误。用木马程序记录键盘输入现在比较流行的QQ 或 网络游戏的盗号就常用这种方式进行。安装杀毒软件来防盗号自不必说，还可以做的是用屏幕软键盘输入密码，这样木马就记录不到键盘事件，只能通过分析鼠标点击和当时屏幕图象来破解密码。如果再进一步，软键盘的字符布局每次都随计产生，那就更加重了分析破解的难度。模仿或感染应用程序，直接得到内存中的密码值不管如何防范输入的过程，一旦密码到程序里，就会以明文的
15、形式呈现在内存中，只要恶意软件模仿安全程序（或模仿网站的外观）直接套取密码就轻而易举。现在出现的假ATM 机诈骗也是这种手法的衍生。还有一种，不是替换或模仿程序，而是用病毒感染原程序，将原程序内存中的值读到。要防范这种攻击，必须要对原程序的完整性和合法性进行验证，在验证通过后，才能进行正常的登录交互操作。这个验证可以用数字签名来实现。比如Windows 7 中所有微软的可执行文件都带有微软的数字签名。在网站上则是HTTPS 的验证。当然，这个验证过程还牵扯到人的判断，在社会工程学上，软件要配合一些强制的措施，才能保证人不会麻痹大意中招。比如浏览器在访问非信任机构签发的数字签名的HTTPS 站点
16、时，会阻止用户进行访问。Windows 7 现在所有的Driver 也都必须要有微软的数字签名才能运行。2 原始密码的转换原始密码会经过一些转换，才能在线上传输。这跟密码的存储类似。直接传输明文密码肯定是最不安全的。而用简单的可逆变换，或者固定密钥加密也只是增加了破解难度。最好是每次 Server 随机产生一个密钥，送给Client 端进行密码加密。如果使用HTTPS，那所有的通过SSL 通道的信息都是经过随机密钥加密的。自然也包括了密码。当然，使用HTTPS 最大的问题是性能。连接初始时密钥的协商是通过非对称加密的体系进行的，这会造成连接较慢（密钥协商好后的数据加密是纯耗CPU 的工作，在现
17、在的硬件条件下，并不是瓶颈）。一般金融在线系统是肯定要使用HTTPS 的。而大部分在线应用，出于性能的考虑，会选择在HTTP 层的简单交换随机密码的方式。名师资料总结-精品资料欢迎下载-名师精心整理-第 5 页，共 7 页 -随机密钥由Server 端生成，并发送给Client。Client 用密钥将密码加密，送给Server。这里并不要求加密方法是可逆的。一个比较安全的做法是Client 使用MD5 或 SHA-1 等非对称变换，对密钥进行不可逆转换，再加密送到Server。现在已经有很多Javascript 的加密库可以在浏览器端进行这样的转换工作。3 转换后的密码的在线传输一般来说，为了
18、保证安全传输，必须要用随机密钥对传输的明文进行加密转换后再传输。如果不使用HTTPS，那就算密码不被攻破，还是有可能发生重放攻击。传输的中间人截获了转换后的密码后，就有可能用转换后的密码进行认证和攻击。现在最新的研究是利用量子力学所揭示的粒子对的超距相关性来进行“量子加密传输”。这有点类似于古时候传送密信时在信的封口上用火漆封口，一旦信件被中间人拆开偷看，火漆肯定被破坏。收信人就会知道。量子加密很耗资源，通常是作为给绝密级别信息传输准备的技术。用于“量子加密传输”的信息一般也只有密钥。一旦双方通过“量子加密传输”确认了彼此的密钥，就可以使用平常的通道来传输加密后的密文了。看上去量子加密传输很象
19、终极解决方案，可最近也传出了针对量子加密的成功攻击的案例。4 常用服务的密码传输方法这里用抓包的方式分析一下常用的一些网络服务的密码传输，看看它们在安全性方面做的如何网站密码传输方式安全性bitbucket.org HTTPS 加密传输高微软 HTTPS 加密传输高G HTTPS 加密传输高开心网 HTTP 客户端Javascript 加密传输中西祠 HTTP 客户端Javascript 加密传输中 HTTP 客户端Javascript 加密传输中人人网 HTTP 明文传输低 HTTP 明文传输低天涯 HTTP 明文传输低强烈建议对那些既不支持HTTPS 登录，而且又不经过客户端加密，直接使用
20、HTTP POST 明文传送密码的网站，不要使用自己的关键密码来注册，避免泄露。5 小结密码的传输比 密码的存储 更加敏感和不安全，一般的应用大致有三个层次的传输策略：使用 HTTPS 加密传输，非常安全，但对Server 性能要求很高。也影响登录速度。一般用在高安全性的登录上面。Google 和微软的登录都强制使用HTTPS 确保安全第一。使用随即密钥对密码进行加密变换后传输，相对安全，密码明文很安全，但仍可能发生重放攻击。这种方式是性能和安全性的折中。一般的服务使用足亦。国内的开心网就使用这种方式进行登录认证。不做任何修饰，直接将密码明文通过HTTP POST 传输。这种方式漠视了用户密码
21、的安全。名师资料总结-精品资料欢迎下载-名师精心整理-第 6 页，共 7 页 -实现起来非常简单，但却是对用户隐私和资料的不负责任。很可惜，国内几个著名网站都是采用这种简单方式。用户的应对之道就是不要在这些网站上使用有价值的密码，例如你银行卡的密码。6 其它密码在传输过程中的泄露的途径很多，你很可能完全没有意识到密码正在传输中被窃听。比如最近的一个新闻，骗子利用音频分析软件对用户在电话上输入密码的按键音进行分析，进而得到用户的密码。大概我们在用电话按键输入密码时都没有想到，按键的声音居然也是我们密码传输的一种载体吧。7 2010年8月6号更新最近在使用浦发银行的400 电话服务时，惊奇的发现，当系统提示输入密码时，除了听到自己的按键音外，听筒里还有其它的按键音随机的响起。因为这些背景音的干扰，居然让人输入密码时有点手足无措。略一思考，这不正是防范输入密码的声音被有心者录下，通过音频分析软件盗取银行密码的安全措施吗。浦发连这点都想到了，不知道其它的电话系统是否现在也都采用了这种措施加强安全。其实，声音也是种UI 界面，当输入密码时声音的反馈被混淆和加噪后，确实有些不适应。原来一直忽略的声音UI，对人的重要性一点也不比图形UI 来的低。名师资料总结-精品资料欢迎下载-名师精心整理-第 7 页，共 7 页 -