【问题引出】
由于公司主要是基于虚拟交易的电商业务，WEB系统一直存在帐号硬件绑定的需求，以提升系统的安全性和可靠性，防止密码盗用和木马侵入导致的财产损失。
大家也知道，手机端（不管是android还是IOS）或者windows的C/S模式的系统都非常容易获取MAC地址、硬盘编号等物理信息，记录校验，也就不难实现所谓的“硬件绑定”；可是由于浏览器的多样化且需要控件的支持，导致WEB上的“硬件绑定”相对麻烦，业内通常的技术实现是用web端程序调用第三方的控件（OCX、DDL）来实现硬件的读取，但是控件加载又限制用户只能使用ie系列的浏览器实现这一功能（银行网站如农行站就存在这样的控件兼容性问题），某种程度降低了用户体验。
【方案对比】
其实本人一直对安全这块很感兴趣，工作以来对这一块的内容也比较关注。
1、加密：
普通应用对密码会进行各种加密操作，如对称加密RSA、DES，签名算法MD5等等，其中RSA多用用于证书，MD5不可逆多用于签名；缺点是对称加密密钥保存存在安全隐患，而MD5虽然不可逆，但是网上有人专门弄了“键值库”，暴力破解；
2、外置狗（U盾）鉴权
各大银行多采用外置u盾来实现物理鉴权，u盾与计算机分离，且可靠性高；缺点是抽插麻烦，容易弄丢；
3、短信、邮件验证
这一方式也为多数企业沿用，安全级别算是比较高的；缺点是短信服务器需要耗费较高的成本，而第三方的邮箱对大量邮件可能不支持，需自己搭建邮件服务器；
4、移动令牌
眼下，随着移动互联网火热发展，移动令牌粉墨登场；小米系统的“小米手机令牌”、支付宝的“手机宝令”，腾讯QQ安全管家的“令牌”如出一辙，通过android客户端或者IOS客户端生成一组随机字符实现鉴权——高效、可绑定手机IMEI编号（变向硬件绑定）、低成本（仅流量）、还很酷；不瞒说，也有缺点：需要智能手机的支持。
实现思路：
1、保证手机令牌和服务端生成字串的一致性（算法一致）；
2、按时间刷新；
3、区别不同用户；
4、算法保护；
5、防止时间不同步；