大规模互联网用户密码泄露 风险控制对策 吴锐 2012-03-16

作者简介 吴锐 盛大风险控制部经理。 毕业于清华大学，2005年加入腾讯安全中心，在账号安全体系建设、打击垃圾广告、欺诈消息等方面成果显著。在盛大期间，先后担任资深安全架构师，风险控制部高级经理。通过创新风险控制方式，很好的控制了木马盗号、外部账号泄露盗号、针对盛大的网银钓鱼欺诈、网银木马欺诈等风险。在账号安全体系建设、安全评估、安全架构、欺诈检测、账号安全、支付安全等领域有着丰富的经验。 mail:wurui@snda.com wr.mail@qq.com 微博：http://t.qq.com/wurui82 QQ：47510169 Tel:18621587382

目录 一、避免密码泄露 密码存储安全、密码传输安全 二、已泄露账号风险控制措施 防批量登录与余额查询、风险账号检测、控制盗号转出

背景 过去的一年，上亿被泄露账号在互联网上被公开下载，互联网用户账号密码泄露，已不再是一个公司的问题，而是整个互联网行业必须共同面对的问题。 如何防范？

密码存储安全 OR 你的密码存储与校验方式安全吗？ 确保存储用户账号密码的服务器固若金汤。永远不被入侵者攻破。 使用一套合理的密码存储算法，使得即使数据泄露，也无法获取到用户密码。 OR 你的密码存储与校验方式安全吗？

密码存储安全——简单摘要算法 为什么不安全？ 通过md5/sha1这样的摘要算法处理后存储，曾经被认为是安全的密码存储与校验方式，但很快就被证明不安全。 Hash=md5(Password) Hash=sha1(Password) 为什么不安全？ 1、用户使用的密码长度是很有限的，可以把大部分密码对应的md5事先计算好存入db，知道摘要后的串后，只需要查表（彩虹表）即可得到明文。 所需空间：数T硬盘(成本很低) 所需时间：一个密码20ms左右 2、md5碰撞，目前对密码校验还不是问题，但今后可能越来越不安全。

密码存储安全 密码为6位和7位的用户超过50% 8-10位密码中有50%左右的用户密码为纯数字 对用户的密码分布情况进行统计： 其他较长的密码，也大多数是一些常用单词和字符串的组合。

密码存储安全——加盐后再摘要 为什么不安全？ UserName Id Salt Hash Tony 1 WtXccU12V e10adc3949ba59abbe56e057f20f883e Kitty 2 KI&ffs3TeF c0a27f801162b8b862cd5f5a1a66e85a Hash=md5(Password+Salt) Salt为随机生成的字符串 <?php function hash($salt,$a) {     $b=$a.$salt;  //把密码和salt连接     $b=md5($b);  //执行MD5散列     return $b;  //返回摘要后的值      } ?> 为什么不安全？ Discuz等开源系统采类似的密码保存方法。 这种方式比只进行摘要算法后保存安全，但通过暴力破解，还是可以还原用户密码中绝大部分。

密码存储安全——暴力破解加盐后的摘要算法 ATI HD5870： 约2400M/s     MD5 约795M/s      SHA1 ATI HD4850: 约980M/s      MD5 约305M/s      SHA1 nVidia GTX260/192SP: 约550M/s      MD5 约175M/s      SHA1 CPU 大约100M/s MD5 如果用户密码数据库发生了泄露， 即使不采用任何简化方法，一台电脑暴力破解一个7位小写字母+数字密码或10位纯数字密码所需时间都不超过10分钟。 七位数字密码组合： 36^7= 78364164096 10^10= 10000000000

密码存储安全——更安全的做法 客户端： 服务器端 （一）注册过程 客户端： 服务器端 Hash=sha1（Sha1_10000(user+PassWord)+salt） 存储Hash、salt （二）密码校验过程 HashA=Sha1_9999(user+PassWord) HashB=Sha1(HashA) 比较sha1(HashB+salt)=Hash？ 注：Sha1_10000表示进行10000次Sha1计算 Sha_9999表示进行9999次Sha1计算，下面内容中都适用 优点： 1）加大计算复杂度，将极大提高抗破解能力。 2）计算在客户端进行，对响应时间影响10ms左右，不影响用户体验。

目录 一、避免密码泄露 密码存储安全、密码传输安全 二、已泄露账号风险控制措施 防批量登录与余额查询、风险账号检测、控制盗号转出

密码传输安全 有没有两全其美的方案？ （一）明文传输： （二）传输摘要后的密码，例如： （三） Https： 随着无线业务的发展，WIFI使用的增多，密码传输过程中的安全性越来越重要。 （一）明文传输： 显而易见不够安全。 （二）传输摘要后的密码，例如： 后台数据库中存储2次md5后的摘要值 传输过程中传输1次md5后的摘要值 这样及时截包获得了协议包的内容，获得的也是摘要后密码 缺点：获得了摘要后密码与获得密码本身能做的事情基本相同，安全性一样不高。 （三） Https： 比较安全，但对服务器硬件要求高一些。 无线应用，很多不适合使用https 有没有两全其美的方案？

密码传输安全 效果如何？ 客户端： 服务器端 （一）客户端向服务器端请求获取挑战码： 得到Code Code=随机数挑战码 客户端： 服务器端 （一）客户端向服务器端请求获取挑战码： 得到Code Code=随机数挑战码 （二）密码校验过程 HashA=md5(md5(PassWord)+Code) 从存储中取Hash=md5(PassWord) 进行相同的计算： HashB=md5(Hash+Code) 比较HashA与HashB 多个互联网公司都在使用类似方式， Js代码：PostPwd=sha1(““+sha1(sha1(password)) + me.servertime + me.nonce); 效果如何？ 缺点： 1）如果通过网络截包获取到了Code与HashA，很容易通过暴力破解获取到PassWord 2）数据库中必须存储了简单摘要后的PassWord，才能进行比对，存储安全性较差

密码传输安全 是否解决了安全的问题？ 客户端： 服务器端 （一）客户端向服务器端请求获取挑战码： 得到Code Code=随机数挑战码 客户端： 服务器端 （一）客户端向服务器端请求获取挑战码： 得到Code Code=随机数挑战码 （二）密码校验过程 HashA=md5(md5_10000(PassWord)+Code) 从存储中取Hash=md5_10000(PassWord) 进行相同的计算： HashB=md5(Hash+Code) 比较HashA与HashB 是否解决了安全的问题？ 缺点： 1）数据库中存储了md5_10000(PassWord)，or更低阶的Hash才能进行这种比对 2）一旦数据库中的hash值泄露，和泄露密码本身造成的威胁一样。

密码传输安全——不采用SSL情况下安全的做法 客户端： 服务器端 （一）注册过程 Key=md5_10000(User+PassWord) 存储Key和Hash Hash=sha1_10000(User+PassWord) Key用于通讯过程对称加密 Hash用于身份校验 （二）登录过程 1、客户端向服务器端请求获取挑战码： 得到Code Code=随机数挑战码 2、密码校验过程 HashA=sha1_9999(user+PassWord) 从存储中取Key,Hash Var=AES(Key, HashA, Code) 通过Key解密Var，获取HashA，Code 判断Code是否正确 判断sha1(HashA)与Hash是否相等 优点： 1）无论是数据存储，还是传输过程，都非常安全。 2）即使摘要算法被进一步破解，该方法一样能确保安全。 3）便于实现业务的分层安全，例如客户端保存密码登录使用sha1_9999(PassWord)，普通登录使用sha1_9998(PassWord)，安全性要求更高时，例如修改密码时使用sha1_9995(PassWord) 。

其他安全做法 使用加密方法保护用户密码。 加密密钥存储与互联网隔离。 加密主机 密码加密 注册 硬件加密卡 密码校验 登录 密钥

密码传输安全——安全的传输方式 安全的密码存储与传输可以做到 呼吁行业内各个公司一起重视并提升密码存储与传输安全！ 现状令人堪忧

目录 一、避免密码泄露 密码存储安全、密码传输安全 二、泄露账号风险控制措施 防批量登录与余额查询、风险账号检测、控制盗号转出

背景 拖库 洗号 获利 黑客 入侵系统，盗走用户账户密码数据库 买卖、公开泄露等方式 盗号团伙 批量查询网络财产余额 在各个平台批量验证密码是否正确 获利 转移财产 用于诈骗、广告 刷活动、投票等

防批量登录尝试与余额查询——IP策略 盗号者获取到大量账号密码后，必然要进行批量登陆尝试，可利用针对IP的控制策略，对非法的尝试行为进行控制。 作用：可将批量的登录尝试控制在一定规模内 局限： （一）由于存在较多用户共用相同IP的情况，存在误杀的情况。 （二）盗号者往往采用如下几种方式绕过针对IP的限制策略。 绕过验证码 说明 对抗办法 重新拨号变换新IP 盗号者可以通过ADSL重新拨号获得一个新的IP，大多数情况和之前IP处在同一个网段 结合IP和IP段进行限制策略 使用代理IP 利用Http代理、VPN代理等手段，获得大量可使用的IP地址 代理IP检测机制 IP伪造 当用户到服务的web访问通过了F5，nginx等代理进行转发时，Web程序一般会获取Http头中的x-forwarded-for中的IP，如果处理不当，存在用户IP被伪造可能。 规范开发运维，避免获取的用户IP被伪造。

防批量登录尝试与余额查询——IP策略 IP伪造原理与防范 client 61.0.0.1 CDN 10.0.0.1 F5/Nginx 10.0.0.2 Web Server 10.0.0.3 获得IP 61.0.0.1 正确！ 1、正常情况 HTTP_X_FORWARDED_FOR =“61.0.0.1” HTTP_X_FORWARDED_FOR =“61.0.0.1 ,10.0.0.1” client 61.0.0.1 F5/Nginx 10.0.0.2 Web Server 10.0.0.3 2、被伪造情况 获得IP 1.1.1.1 错误！ HTTP_X_FORWARDED_FOR =“1.1.1.1” HTTP_X_FORWARDED_FOR =“1.1.1.1,61.0.0.1”

防批量登录尝试与余额查询——代理IP检测 技术检测 代理IP检测 用户行为特征检测 爬虫检测

防批量登录尝试与余额查询——验证码 缺点： 1）国外被证明防破解效果比较好的验证码，如google和recaptcha，对国内用户来说难度过大 2）而识别相对容易的验证码，则面临被自动破解的问题 动态运营非常重要，可采用多种方式优化验证码效果，例如： 1）针对不同风险等级的场景，显示不同难度的验证码图片。 2）对验证码图片本身进行分析，并实现自动优化能力。

防批量登录尝试与余额查询——验证码

目录 一、避免密码泄露 密码存储安全、密码传输安全 二、泄露账号风险控制措施 防批量登录与余额查询、风险账号检测、控制盗号转出

风险账号检测 （一）恶意行为特征 访问量集中 不存在账号比例较高 密码错误比例较高 异地登录账号比例较高 已发现风险账号占比较高 验证码图片拉取频繁 验证码验证正确率较低 登录后马上查询余额的账号比例较高 登录时间分布，业务分布 。。。。 （二）技术特征 Cookie UserAgent 点击流信息 Js信息收集 绝大部分恶意登录都有明显的特征， 绝大部分账号泄露用户都在检出的风险账号库中

风险账号检测 Web程序防“外挂”思路 登录页 登录 Js代码 上报数据 不仅可以用于风险账号检测，也可以用作木马发起的欺诈支付订单的检测，均能取得很好的效果。 无规律更新

目录 一、避免密码泄露 密码存储安全、密码传输安全 二、泄露账号风险控制措施 防批量登录与余额查询、风险账号检测、控制盗号转出

防盗号财产转移 是否被盗账号 特征是否异常 （IP、Cookie等） 是否风险交易 交易成功 交易类型 （赠送他人，购买可转移的物品等） 要求进行补充验证 （手机、邮箱、资料等）

防盗号财产转移——技术实现 用户行为习惯服务 其他基础服务（IP库等） 数据采集模块 业务数据 特征计算引擎 风控策略规则引擎 风控结果查询审计系统 中间数据 （黑白名单库等）

防盗号财产转移 最终主要的瓶颈在于覆盖率与准确率之间的平衡。 覆盖率 准确率

Thank You！