Hash

一般翻譯做“散列”，也有直接音譯為“哈希”的，就是把任意長度的輸入通過散列算法變換成固定長度的輸出，該輸出就是散列值。這種轉(zhuǎn)換是一種壓縮映射，也就是，散列值的空間通常遠小于輸入的空間，不同的輸入可能會散列成相同的輸出，所以不可能從散列值來確定唯一的輸入值。簡單的說就是一種將任意長度的消息壓縮到某一固定長度的消息摘要的函數(shù)。(來源百度百科解釋)

Hash的特點

• 算法是公開的
• 對相同數(shù)據(jù)運算,得到的結(jié)果是一樣的
• 對不用數(shù)據(jù)運算,如MD5得到的結(jié)果都是32個字符長度的字符串
• 這玩意沒法逆運算

Hash的運用場景

通過它的這幾個特點.我們可以談?wù)凥ash它的運用場景了

登陸密碼加密

我們在開發(fā)的過程中首次登陸需要向服務(wù)器發(fā)送用戶密碼進行賬戶驗證.但是用戶的密碼是非常隱私的信息.所以一定要使用加密保護.

直接使用Hash

那么目前最優(yōu)的解決方案就是使用密碼的Hash值進行驗證

客戶端直接將用戶輸入的密碼進行Hash運算,得到結(jié)果發(fā)送給服務(wù)器驗證.因為Hash算法無法逆運算,所以就算Hash值泄露,用戶真實密碼也不會泄露.

服務(wù)端需要服務(wù)器配合,在用戶注冊的時候,服務(wù)端的數(shù)據(jù)庫中保存的就是用戶密碼的Hash值,而不是密碼本身(根據(jù)Hash的特點,對相同的數(shù)據(jù)加密結(jié)果是一樣的).這樣就算服務(wù)器被攻克,用戶的隱私信息也能起到一定的保護.

也就是現(xiàn)在為什么各類產(chǎn)品只提供重置密碼的功能,而不再有找回密碼的功能了.因為服務(wù)端本身也不知道用戶的真實密碼.

特別說明:用戶的密碼屬于非常隱私的信息.因為大多數(shù)用戶有一個特點.密碼喜歡使用重復(fù)的.如果你的APP泄露了用戶的密碼.那么很有可能,黑客利用用戶的手機號碼加上密碼,可以套出用戶的支付信息.這種后果是非常嚴重的!

再加一點東西

上面所說的案例理論上已經(jīng)非常的"安全"了.因為就算黑客知道了你的Hash值,也沒法逆運算出用戶的密碼.但情況并不樂觀.我們眼見為實!

以MD5為例:在終端上演示一下(比如我的密碼是123456)

$md5 -s "123456"

MD5的結(jié)果是: e10adc3949ba59abbe56e057f20f883e

接下來隆重介紹一個網(wǎng)站腳本之家在線工具我們只需要將Hash值進行反向的查詢.

查詢結(jié)果圖

可能你會問,Hash既然不能反算為何這個網(wǎng)站能夠查詢出來?仔細看下網(wǎng)站的介紹不難發(fā)現(xiàn):其實它是一個巨大的數(shù)據(jù)庫.利用明文和Hash的數(shù)據(jù)記錄,進行反向查詢.

網(wǎng)站介紹

當(dāng)然,提供哈希反向查詢服務(wù)的不僅僅只有這個網(wǎng)站,還有很多盈利性的公司提供有償服務(wù).

所以如果我們單純的直接使用Hash算法,用戶的密碼安全性會非常低.

早期的解決方案加鹽

//用戶密碼
NSString * pwd = @"123456";
//足夠復(fù)雜 足夠長!!
static NSString * salt = @")@#(*URJ(@FJ_(@JF_(IJEFIOJ_@(IJWD{OIJW_(DIJ!W";
//先將明文拼接一個鹽
pwd = [pwd stringByAppendingString:salt];
//再進行Hash算法
const char *str = pwd.UTF8String;
uint8_t buffer[CC_MD5_DIGEST_LENGTH];
CC_MD5(str, (CC_LONG)strlen(str), buffer);
NSMutableString *md5Str = [NSMutableString string];
for (int i = 0; i < CC_MD5_DIGEST_LENGTH; i++) {
        [md5Str appendFormat:@"%02x", buffer[i]];
 }

這種方式,對于反向查詢來說就比較困難了.安全系數(shù)也相對較高.

HMAC(Hash-based Message Authentication Code)

對于簡單的使用鹽的方式還是會有安全隱患,因為如果鹽被泄露了.那么整個項目將陷入被動.因為這種方式將鹽寫死在程序里面了,要想今后換掉是非常難的.

那么接下來介紹一種加密方案HMAC.它使用一個密鑰,并且做了兩次散列!

注意:在開發(fā)過程中,這個密鑰KEY是從服務(wù)器獲取的.并且一個用戶對應(yīng)一個KEY

廢話不多說,直接上代碼

//用戶密碼
NSStirng * pwd = @"123456";
//加密用的KEY,注意是從服務(wù)器獲取的
NSString * key = @"hmackey";
//轉(zhuǎn)成C串
const char *keyData = key.UTF8String;
const char *strData = pwd.UTF8String;
uint8_t buffer[CC_MD5_DIGEST_LENGTH];
//hmac加密
CCHmac(kCCHmacAlgSHA1, keyData, strlen(keyData), strData, strlen(strData), buffer);
NSMutableString *hmacStr = [NSMutableString string];
for (int i = 0; i < CC_MD5_DIGEST_LENGTH; i++) {
        [hmacStr appendFormat:@"%02x", buffer[i]];
 }

對于這種加密方案.就可以很好的保護用戶的隱私信息.因為就算泄露了KEY.這個KEY也只是一個用戶的.不會污染整個項目.

如果拿到這個KEY,然后想反查詢出用戶的明文密碼.這個成本,除非這是馬云的賬戶.

所謂安全,無法做到絕對安全.他們灰產(chǎn)有句話:只要錢到位,沒有什么不可能!我們要做到的就是相對安全.讓破解的成本大于破解的利潤.

登錄加密補充

今天寫得開心.所以再分享一點干貨.

剛才我們一直停留子在黑客想要拿到用戶的真實密碼.那么如果黑客換了一個思路.大哥就是想要拿到用戶的登錄權(quán)限呢?

那么我們這種加密.無論你怎么玩.妥妥的都是給服務(wù)器一個Hash串進行驗證啊,也就是我只需要拿到你的Hash值.那么我只要模擬你客戶端進行登錄是再簡單不過了.

當(dāng)然,這樣的防護手段有很多.我介紹一種有效的防護方式.有更好的建議可以留言寫在下面,一起交流,向您學(xué)習(xí).
注冊的過程注冊的過程還是一樣.服務(wù)器保存的還是一串HMAC加密之后的HASH值.進行校驗.但是登錄時的驗證做點修改.

客戶端

• 通過服務(wù)器的KEY進行HMAC加密,得到HMAC的Hash串
• 將得到的Hash串拼接一個時間字符串@'201807102248'注意只到分(當(dāng)然根據(jù)你的情況可以到秒)
• 然后將這個拼接完成的串,再次Hash.將這個結(jié)果發(fā)給服務(wù)器驗證

服務(wù)端服務(wù)器保存了hmac的Hash串,以同樣的算法,拼接服務(wù)器的時間,進行運算,然后校驗.比如時間是59秒99發(fā)送的請求.服務(wù)器正好跳過一個分鐘.過程如下:

• (服務(wù)器的Hash串+@"201807102249")Hash.這次不通過再來一次
• (服務(wù)器的Hash串+@"201807102248")Hash.和上一分鐘對比,一次通過算成功

 這樣的好處,可以做到每登錄發(fā)送給服務(wù)器的Hash值是不一樣的.黑客不能通過保存Hash值模擬登錄.

版權(quán)&文件識別

當(dāng)然Hash的作用除了用于登錄密碼加密以外.還有版權(quán)的運用.

比如如何識別一段視頻或者一段音頻,這種數(shù)字文件是正版的.這個時候,我們使用肉眼是沒法判斷的.因為翻錄的視頻和音頻文件幾乎看不出來.但是,文件的二進制不一樣,它的Hash值是不會欺騙群眾的.所以類似YouTube這樣的網(wǎng)站,在你上傳視頻的時候,它會將文件的Hash值保存.當(dāng)其他的網(wǎng)站上傳這個視頻,那么看是否是正版,就是對比文件的Hash值.

既然可以識別文件.那么還有一個非常廣泛運用的就是像百度云這樣的云端服務(wù).舉個例子:
很多小伙伴保留的視頻,經(jīng)常被"和諧".有的人將視頻的名稱全部改為葫蘆兄弟,黑貓警長但是還是被和諧了.
百度識別你的視頻文件,和你的文件名稱,以及文件后綴(有人改成.txt)沒有半毛錢關(guān)系.它只會看這個文件的Hash值.那么如果想要逃脫.你唯一的出路就是改變文件原有的二進制.(翻錄\視頻格式轉(zhuǎn)換).

那么最簡單的,就是一個壓縮包,全部搞定.(我是很嚴肅的在討論技術(shù)... ...的運用場景)

以上就是Hash算法示例應(yīng)用場景解延伸探究的詳細內(nèi)容，更多關(guān)于Hash算法應(yīng)用的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論