在資料庫存的會是
使用者輸入帳號密碼的時候,伺服器端會透過同樣的雜湊邏輯,就可以得出跟資料庫儲存的一樣的雜湊,這樣就完成一個正常的密碼驗證。
也由於 hashing 會讓輸入的字串跟得到的雜湊有很不一樣的結果,即使只改輸入的密碼一個字元,得到的 hash 也會完全不一樣。這樣的機制導致 Timing Attack 在這個例子上就完全沒有用了,因為攻擊者根本不能預期真正在做字串比對的那個雜湊是不是如攻擊者預期的一個字元一個字元改變,那如此即使有時間上的差異,也跟第幾個字元比對失敗沒有直接的關係。
那到底有沒有其他例子是真的會需要注意這個漏洞的呢?我能想到的大概就是像是某些加密貨幣交易所,他們的 API 幾乎都需要做所謂的簽章。概念如下:交易所需要透過 API key/secret 確保這個請求是來自合法的使用者,所以每個請求都必須附帶上簽章,公式大概是這樣:
這個的用意是使用者利用自己的私鑰去加密請求的參數,來證明自己是真的自己。
伺服器端則會用使用者本次請求的參數加上使用者的私鑰來去重組 Signature,假設 Signature 跟請求端附帶的一樣,那就是合法的請求。
在駭客的角度,由於沒有使用者的私鑰所以沒有辦法用正規途徑得到 Signature,但是利用 Timing Attack 這招就可以猜出本次請求所對應的 Signature 從而達到偽造身份的效果。但這有幾個不實際的地方:
講白了這個攻擊手段我個人覺得看起來很厲害但其實沒這麼可怕。除非是菜鳥工程師,不然實務上不太可能做出會被這個攻擊手段影響的系統…
Reference:
[1] Return early and clearly https://arne-mertz.de/2016/12/early-return/
[2] 這個例子其實是所謂的 Order of evaluation, 跟 Early return 有一點不同。https://en.cppreference.com/w/cpp/language/eval_order
[3] Adding Salt to Hashing: A Better Way to Store Passwords
[4] nonce 可以有效避免重送攻擊。 (重送攻擊我常常用,可參考我的另一篇文章 從奧客玩家視角看遊戲防禦性設計)
另外補充一篇也是在介紹 Timing Attack 的文 Using Node.js Event Loop for Timing Attacks