读者可能已经熟悉访问https服务器时,验证服务器的身份是强制的,必不可少的。
而服务器验证客户端的身份却是可选的。
之所以这样规定是为了防止客户端与冒充的服务器通信,并且由于客户端很少拥有自己的证书,所以采用了客户端单向认证服务器,而服务器不必验证客户端。
但是,在一些场景下服务器却需要验证客户端的身份,比如企业网上报税,则需要双向的认证。在https安全握手阶段,不仅报税软件要验证税务局的服务器身份,同时税务局服务器要验证客户端的企业身份。
假设Token保存在Alice的电脑,有一天Alice的电脑在办公室被盗了,或者出差的途中丢了,被Eve捡到了,公司的私钥就面临泄露的风险。
很显然不能,如果Alice不小心将物理Token丢失,再一次被Eve见到,Eve一样可以读出明文的私钥。所以,私钥需要加密保存,即使被Eve捡到,也只能望Token兴叹,因为没有密钥,Eve读不出私钥啊!
能使用不对称方式加密吗?比如使用公司的公钥来加密私钥,很显然不能!为什么?Alice要想读取Token里的私钥,必须要拥有私钥,而私钥却加密保存再Token里,所以这是一个自锁的矛盾过程。
能否使用另外一张Token的公钥来加密Alice的私钥?
可以是可以,那另外一张的Token的私钥怎么来保护呢?如果也像保护Alice的私钥一样的方式,将会是一个无限的循环,无穷无尽。
Token的PIN码,PIN码很拗口,如果用口令或密码则很好理解。
Token在发放到Alice手中时,需要Alice在税务局的柜台输入自己的口令,通常至少要8位密码,比如“abc12345”,Token会使用“abc12345”来加密Alice的私钥?
No,这个密码不够随机化,需要使用Hash()函数将密码随机化,然后才能当做密钥使用。此外,为了提高安全性,还需要撒点盐(Salt),盐通常包括,企业单位的名称、企业账号,然后和口令连接成字符串,做Hash运算,将Hash运算的输出,截短为128位,或扩展到256位,即得到加密密钥(Encryption Key),同时也是解密密钥(Decryption Key)。
税务局的电脑使用加密密钥将Alice的私钥加密之后,将其写入USB Token。
Alice输入口令,Token将口令与预先保存在Token里的盐做字符串连接,计算Hash,得到密钥,然后用密钥解密,即得到明文的私钥。
如果Alice输入的口令错误,自然无法得到正确的密钥,自然无法解密。
Alice的电脑、Token一起丢失,Eve捡到了,没有Alice的口令Eve无法从Token里读出私钥。
万一Alice的电脑、Token丢失了,Alice的口令写在Token上,那神仙来了也救不了Alice。Eve可以轻松地读出Alice的私钥。
此外,如果Alice的口令非常简单,比如“12345678”,Eve捡到了Alice的Token,只要尝试几下就可以成功,就可以毫不费力地得到Alice的私钥。
所以,提高网络安全不仅仅要依赖于技术手段,而且还要依赖于人的安全意识。以上种种技术手段仅仅是将人为失误造成的风险降到最低。
只要Alice不把自己弄丢、不把口令写在Token上,将口令设置得尽量复杂,那么Alice的私钥就是安全的。
●编号932,输入编号直达本文
●输入m获取文章目录
Linux学习
更多推荐《25个技术类公众微信》
涵盖:程序人生、算法与数据结构、黑客技术与网络安全、大数据技术、前端开发、Java、Python、Web开发、安卓开发、iOS开发、C/C++、.NET、Linux、数据库、运维等。