用戶表如何存放用戶密碼

先上結論：密碼安全性從低到高

數據庫存密碼原文<數據庫存密文（成本=彩虹表）<數據庫存加固定鹽（固定鹽甚至不能被稱爲鹽）的密文（成本=計算出鹽值+製做彩虹表）<數據庫加隨機鹽的密文（成本=用戶數*製做彩虹表）<（隨機鹽+固定鹽+原文）加密（成本=計算固定鹽值+用戶數*製做彩虹表）

咱們都知道，密碼存原文，這在如今幾乎是不可能的，用戶密碼通常以密文的形式，存放於表中。若是僅僅是對密碼作一層加密，那麼當用戶表數據泄露時，假若黑客以彩虹表逆向破解密文，加密的密文實際上破解難度並不大（成本=彩虹表，網上現成的），這是由於一些用戶的密碼並不複雜。因此咱們須要在加密的過程當中，加入鹽值，將密碼原文和鹽值一塊兒加密。而鹽值若是是固定的值，實際上也等於沒加，由於若是密碼原文同樣，鹽值同樣，最後產生的密文值仍然是同樣的，可是這種加固定鹽的方式，能夠加大彩虹表破解的難度。由於黑客須要知道鹽是什麼，才能經過彩虹表破解（成本=計算出鹽值+製做彩虹表）。可是咱們不能把但願寄託於黑客不知道鹽的狀況（這樣就違背了密碼學準則），雖然通常來講，數據庫數據被盜取的可能性，大於源碼被破解的可能性（固然了庫能拖走，源碼也能反編譯），甚至黑客能夠註冊一個用戶，密碼123456，經過看數據庫裏的密文，反向計算出固定鹽值，因此這種方法安全度不高。從密碼學的角度來講，咱們但願哪怕兩個用戶的密碼原文是同樣的，可是數據庫裏存放的密文是不同的。這時，有一種經常使用的辦法，就是加隨機鹽，鹽值隨機產生，這樣就能夠保證用戶密碼原文一致，但密文不一致。那麼就出現了一個新的問題，隨機鹽怎麼獲取？有人說產生一個隨機數，例如用戶註冊時間，沒錯，那麼咱們在判斷密碼是否正確的時候，須要知道鹽值是多少，換句話說，若是咱們使用隨機鹽，咱們就須要保存隨機鹽，那隻能保存到數據庫中，但是前文已經提到前提：數據庫數據泄露的狀況下。那麼所謂的隨機鹽，也就是一個笑話了。固然了，隨機鹽的手段，更能提升黑客破解的難度，哪怕黑客獲取了數據，他也須要針對不一樣的鹽，製做不一樣的彩虹表才能反向破解，這大大提升了黑客的成本（成本=用戶數*彩虹表）。還有一種手段，比上述加密更難以破解，就是採起隨機鹽+固定鹽一塊兒，做爲鹽值，數據庫表裏以某個字段的值做爲隨機鹽，好比用戶註冊時間、建立時間、手機號、用戶名等等，源碼裏設置一個固定鹽，以此來做爲真正的鹽加密。甚至能夠爲了複雜度，截取隨機鹽的某幾位，將固定鹽MD5做爲鹽值等等（成本=計算固定鹽值+用戶數*彩虹表），其實說實話，計算固定鹽值的難度，遠遠低於用戶數*彩虹表的難度，由於一個是沉沒成本，一個是邊際成本。