iOS 登陸加密

第一種:明文

有一些APP的登陸註冊就直接明文，其實這是十分危險的，危險因素多的數不勝數。 譬如

• 後臺被黑客攻破，用戶的全部信息都會暴露出來
• 網絡劫持：劫持以後也能夠直接看到咱們的明文密碼
• 若是攻擊者破解app，拿到了沙盒中的數據，也會形成數據泄漏

之前聽一個朋友講他們公司最開始的時候就是用明文進行登陸註冊的，而後有一個大三的學生把他們公司的服務器給攻破了。辛虧那位學生並無按什麼壞的心眼，只是把攻破的結果告訴了他們公司，而後他們公司的程序員一個兌一兩千塊錢給了那個學生，算是息事寧人了。因而可知，使用明文登陸註冊是多麼危險。其實如今通常公司都是會對數據進行加密的，除非是那些外包公司作的外包項目，他們實在是懶得跟你加密，纔回使用明文。

第二種：MD5加密

MD5是一個安全的散列算法，輸入兩個不一樣的明文不會獲得相同的輸出值，根據輸出值，不能獲得原始的明文，即其過程不可逆；因此要解密MD5沒有現成的算法，只能用窮舉法，把可能出現的明文，用MD5算法散列以後，把獲得的散列值和原始的數據造成一個一對一的映射表，經過比在表中比破解密碼的MD5算法散列值，經過匹配從映射表中找出破解密碼所對應的原始明文。

MD5有一下四個特色：

• 不可逆的
• 數量是有限的，可使用窮舉法破解，MD5破解就是根據這個
• MD5算法 不論是什麼語言獲得的結果都是同樣的。
• 字符串，圖像，視頻均可以使用MD5加密成32爲字符串

蘋果內部用C語言寫了MD5加密算法，可是咱們對只用用C語言來寫的話，會感到一點點的麻煩，因此，網上有不少的人都對MD5進行了一些簡單的封裝，我這裏就隨便摘抄一段

+(NSString *)MD5ForLower32Bate:(NSString *)str{
    const char* input = [str UTF8String];
    unsigned char result[CC_MD5_DIGEST_LENGTH];
    CC_MD5(input, (CC_LONG)strlen(input), result);
    
    NSMutableString *digest = [NSMutableString stringWithCapacity:CC_MD5_DIGEST_LENGTH * 2];
    for (NSInteger i = 0; i < CC_MD5_DIGEST_LENGTH; i++) {
        [digest appendFormat:@"%02x", result[i]];
    }
    
    return digest;
}
複製代碼

我來對上一段的代碼進行簡單的分析啊。

• const char* input = [str UTF8String];，進行UTF8的轉碼，把字符串類型轉化爲char類型，由於加密的底層是C語言寫的，咱們要轉化爲C語言能看懂的語言。

• unsigned char result[CC_MD5_DIGEST_LENGTH];，設置一個接受字符數組

• CC_MD5(input, (CC_LONG)strlen(input), result);,extern unsigned char *CC_MD5(const void *data, CC_LONG len, unsigned char *md)官方封裝好的加密方法。把字符串轉換成了32位的16進制數列（這個過程不可逆轉） 存儲到了result這個空間中

加密結果：e10adc3949ba59abbe56e057f20f883e 而後把這個字符串放到MD5解密網站上

因此，單純的MD5對咱們的登陸密碼進行加密也不是十分完善的。那些比較懶的用戶可能會輸入一個比較簡單的密碼，咱們也要保護這部分用戶的密碼不會被輕易的破解。這時候咱們就引入了下一個概念。

第三種：加鹽

普通的MD5加密，如今已經有軟件能夠進行破解，全部咱們想出來一種方法，使MD5這種加密更加複雜，更難被破解。這種方式就是加鹽(原始密碼 + 鹽) MD5 運算.保證密碼不被破解,就要保證鹽值足夠長/足夠鹹

什麼是加鹽值

爲了增強MD5的安全性（自己是不可逆的），從而加入了新的算法部分即加鹽值，加鹽值是隨機生成的一組字符串，能夠包括隨機的大小寫字母、數字、字符，位數能夠根據要求而不同，使用不一樣的加鹽值產生的最終密文是不同的。

代碼中如何使用加鹽值

因爲使用加鹽值之後的密碼至關的安全，即使是你得到了其中的salt和最終密文，破解也是一個耗費至關多時間的過程，能夠說是破解單純MD5的好幾倍，那麼使用加鹽值之後的密文是如何產生的呢？ 1).首先咱們獲得的是明文的hash值 2).進行計算獲取MD5明文hash值 3).隨機生成加鹽值並插入 4).MD5插入加鹽值獲得的hash 5).獲得最終的密文

咱們就簡單的使用一下

一樣的字符串123456在加鹽之後就解密不出來了

固然鹽後臺傳給咱們是最好的，使用後臺傳來的鹽（salt）時，登陸註冊咱們須要考慮一下邏輯

• 在註冊時成功後，後臺給咱們隨機的返回一個salt，而且後臺使用鹽（salt）md5加密
• 登陸的時候，咱們用鹽（salt）加密
• 當咱們更換手機登陸的時候，咱們向註冊帳號發送登陸請求信息，當登陸帳號容許新的手機登陸的時候，後臺給新的手機發送之前的salt值（案例：咱們跟換微信登陸的時候，微信會給咱們發送一個驗證碼，咱們輸入驗證碼的過程就是咱們想後臺請求salt的過程）

第四種：HMAC加密

其實上面的思想都有一點HMAC加密的思想，如今國外HMAC加密用的十分普遍了。

HMAC加密算法是一種安全的基於加密hash函數和共享密鑰的消息認證協議．它能夠有效地防止數據在傳輸過程當中被截獲和篡改，維護了數據的完整性、可靠性和安全性. HMAC加密算法是一種基於密鑰的報文完整性的驗證方法，其安全性是創建在Hash加密算法基礎上的。它要求通訊雙方共享密鑰、約定算法、對報文進行Hash運算，造成固定長度的認證碼。通訊雙方經過認證碼的校驗來肯定報文的合法性。HMAC加密算法能夠用來做加密、數字簽名、報文驗證等。

HMAC加密算法的定義

HMAC加密算法是一種執行「校驗和」的算法，它經過對數據進行「求和」來檢查數據是否被更改了。在發送數據之前，HMAC加密算法對數據塊和雙方約定的公鑰進行「散列操做」，以生成稱爲「摘要」的東西，附加在待發送的數據塊中。當數據和摘要到達其目的地時，就使用HMAC加密算法來生成另外一個校驗和，若是兩個數字相匹配，那麼數據未被作任何篡改。不然，就意味着數據在傳輸或存儲過程當中被某些居心叵測的人做了手腳。 代碼以下:

+  (NSString *)HMacHashWithKey:(NSString *)key data:(NSString *)data{

    const char *cKey  = [key cStringUsingEncoding:NSASCIIStringEncoding];
    const char *cData = [data cStringUsingEncoding:NSASCIIStringEncoding];


    unsigned char cHMAC[CC_SHA256_DIGEST_LENGTH];

    //關鍵部分
    CCHmac(kCCHmacAlgSHA256, cKey, strlen(cKey), cData, strlen(cData), cHMAC);

    NSData *HMAC = [[NSData alloc] initWithBytes:cHMAC
    length:sizeof(cHMAC)];

    //將加密結果進行一次BASE64編碼。
    NSString *hash = [HMAC base64EncodedStringWithOptions:0];
    return hash;
}
複製代碼

其中被加密的字段data，咱們能夠設定一種特殊的生成方式。 加密的密匙key也能夠和server端商定一致。

咱們作了這些已經爲保護用戶帳號安全作了不少了，可是，咱們還有改進的機會。

咱們知道，如今用戶常常鏈接公共Wi-Fi，而黑客能夠經過這個公共Wi-Fi來獲取咱們加密後的密碼以及key，這個時候咱們還能夠添加一層新的防禦

第五種：時間戳密碼+HMAC

基本介紹

• 動態密碼：相同的密碼明文+相同的加密算法-->由於每次登錄時間都不一樣,因此每次計算出的結果也都不相同.能夠充分保證密碼的安全性.

• 服務器會計算兩個時間值,當期時間和前一分鐘的時間(好比:第59S發送的網絡請求,一秒鐘後服務器收到並做出響應,這時服務器當前時間比客戶端發送時間晚一分鐘，仍然可以判斷準確的值)

補充介紹：token值

token 值: 登陸令牌.利用 token 值來判斷用戶的登陸狀態.相似於 MD5 加密以後的長字符串.

用戶登陸成功以後,在後端(服務器端)會根據用戶信息生成一個惟一的值.這個值就是 token 值.

基本使用:

• 在服務器端(數據庫)會保存這個 token 值,之後利用這個 token 值來檢索對應的用戶信息,而且判斷用戶的登陸狀態.

• 用戶登陸成功以後,服務器會將生成的 token 值返回給 客戶端,在客戶端也會保存這個 token 值.(通常能夠保存在 cookie 中,也能夠本身手動肯定保存位置(好比偏好設置.)).

• 之後客戶端在發送新的網絡請求的時候,會默認自動附帶這個 token 值(做爲一個參數傳遞給服務器.).服務器拿到客戶端傳遞的 token 值跟保存在 數據庫中的 token 值作對比,以此來判斷用戶身份和登陸狀態.

登陸狀態判斷

• 若是客戶端沒有這個 token 值,意味着沒有登陸成功過,提示用戶登陸.

• 若是客戶端有 token 值,通常會認爲登陸成功.不須要用戶再次登陸(輸入帳號和密碼信息).

token 值有失效時間:

• 通常的 app ,token值得失效時間都在 1 年以上. 特殊的 app :銀行類 app /支付類 app :token值失效時間 15 分鐘左右.
• 一旦用戶信息改變(密碼改變),會在服務器生成新的 token 值,原來的 token值就會失效.須要再次輸入帳號和密碼,以獲得生成的新的 token 值.

惟一性判斷: 每次登陸,都會生成一個新的token值.原來的 token 值就會失效.利用時間來判斷登陸的差別性.