用户表如何存放用户密码

先上结论：密码安全性从低到高

数据库存密码原文<数据库存密文（成本=彩虹表）<数据库存加固定盐（固定盐甚至不能被称为盐）的密文（成本=计算出盐值+制做彩虹表）<数据库加随机盐的密文（成本=用户数*制做彩虹表）<（随机盐+固定盐+原文）加密（成本=计算固定盐值+用户数*制做彩虹表）

咱们都知道，密码存原文，这在如今几乎是不可能的，用户密码通常以密文的形式，存放于表中。若是仅仅是对密码作一层加密，那么当用户表数据泄露时，假若黑客以彩虹表逆向破解密文，加密的密文实际上破解难度并不大（成本=彩虹表，网上现成的），这是由于一些用户的密码并不复杂。因此咱们须要在加密的过程当中，加入盐值，将密码原文和盐值一块儿加密。而盐值若是是固定的值，实际上也等于没加，由于若是密码原文同样，盐值同样，最后产生的密文值仍然是同样的，可是这种加固定盐的方式，能够加大彩虹表破解的难度。由于黑客须要知道盐是什么，才能经过彩虹表破解（成本=计算出盐值+制做彩虹表）。可是咱们不能把但愿寄托于黑客不知道盐的状况（这样就违背了密码学准则），虽然通常来讲，数据库数据被盗取的可能性，大于源码被破解的可能性（固然了库能拖走，源码也能反编译），甚至黑客能够注册一个用户，密码123456，经过看数据库里的密文，反向计算出固定盐值，因此这种方法安全度不高。从密码学的角度来讲，咱们但愿哪怕两个用户的密码原文是同样的，可是数据库里存放的密文是不同的。这时，有一种经常使用的办法，就是加随机盐，盐值随机产生，这样就能够保证用户密码原文一致，但密文不一致。那么就出现了一个新的问题，随机盐怎么获取？有人说产生一个随机数，例如用户注册时间，没错，那么咱们在判断密码是否正确的时候，须要知道盐值是多少，换句话说，若是咱们使用随机盐，咱们就须要保存随机盐，那只能保存到数据库中，但是前文已经提到前提：数据库数据泄露的状况下。那么所谓的随机盐，也就是一个笑话了。固然了，随机盐的手段，更能提升黑客破解的难度，哪怕黑客获取了数据，他也须要针对不一样的盐，制做不一样的彩虹表才能反向破解，这大大提升了黑客的成本（成本=用户数*彩虹表）。还有一种手段，比上述加密更难以破解，就是采起随机盐+固定盐一块儿，做为盐值，数据库表里以某个字段的值做为随机盐，好比用户注册时间、建立时间、手机号、用户名等等，源码里设置一个固定盐，以此来做为真正的盐加密。甚至能够为了复杂度，截取随机盐的某几位，将固定盐MD5做为盐值等等（成本=计算固定盐值+用户数*彩虹表），其实说实话，计算固定盐值的难度，远远低于用户数*彩虹表的难度，由于一个是沉没成本，一个是边际成本。