網路中的「豆腐渣工程」與真正的二次認證

用戶名 + 密碼 = 危險。

自白

我是一名業餘菜鳥黑客。

我業餘到什麼程度呢？

我連代碼都不會敲，我沒考上大學，只是看過幾本黑客的書算作入門，混過黑圈打過醬油。開始我還會覺得會自卑，畢竟是想混傳說中精英薈萃的黑客圈。但不久後我發現，大多數黑客們，都和我一個德性。

只通過市場上能夠購買到，甚至免費使用的工具，我已經成功攻破了一千三百多個網站的用戶系統，獲取到上千萬條用戶名和密碼信息。將這些信息賣掉，我下半生衣食無憂。

網路上遍布了無數的「豆腐渣工程」。

感謝這些開發者們，感謝這些工程，感謝你們。

老生談新事

對於唱衰用戶名+密碼身份驗證的文章屢見不鮮，但是所有主流的互聯網產品，仍然在使用著這一傳統但有效的驗證系統。

我周圍有兩種人，一種對於身份安全毫無理解、毫無意識，他們會在各種網站上用最簡單易記的同一組用戶名與密碼（他們也沒有辨別釣魚網站的能力）；另一種則緊張兮兮、小心翼翼，驚弓之鳥們不一定會有足夠的信息安全知識，但是已經被各種新聞和話語搞得緊張兮兮，他們使用各種類似 LastPass 、 1Password 等身份管理工具來幫助他們管理無數條身份數據。

但是，就算是使用了這些密碼管理工具，也不過是在試圖延長「用戶名+密碼」這種身份認證方式的存在時長罷了。未來渴求著更便捷安全的方式。用戶安全已經不能再用用戶名+密碼來保障了。

至少，不能只用用戶名+密碼。

溫柔的密碼

開發者們都知道，大多數的密碼存放都是通過哈希演算法，將密碼轉化成沒人看得懂也無法還原回去的一段信息，存儲在資料庫里。當需要驗證密碼是否有效的時候，會將剛輸入的密碼用同樣方式轉化，用這個結果與存儲的結果比對。也就是說，資料庫內不會存放真正的密碼信息，無法找回、無法讀取。

相比於很多年前很多密碼直接明文存放在資料庫內的做法，這種方式無疑可靠了非常多。但是這種方式又依賴於所使用的哈希演算法的有效性。

例子

我舉一個很常見的例子：一個用戶的密碼為 ILoveJGSH@2017 ，開發者將密碼使用 MD5 進行哈希計算後存儲到資料庫內。這個密碼的長度不短，和大家日常用的密碼相比，強度也不低。MD5也是開發者們非常廣泛採用的哈希演算法。

在整個黑客破解過程中，有兩個因素決定了某一個密碼（比如我自己的密碼）能否被破解成功：密碼強度和演算法強度。密碼越複雜越隨機，演算法強度越高、措施使用越得當，就越難還原。

在上面舉例的情境中，破解弱點如下：

1. MD5哈希演算法有漏洞。從二十餘年前起，幾乎每年都有新的MD5演算法漏洞或者弱點被發現，直到2010年，位於卡內基梅隆大學的「軟體工程機構」宣布：MD5演算法 "cryptographically broken and unsuitable for further use" [1, Dougherty] (筆者譯:密碼學角度上已被攻破，不適合繼續使用)，應該使用SHA-2家族哈希演算法替換。

2. 密碼強度不夠。這個密碼的長度是合格的，超出大多數系統內密碼最低要求和平均值，也包含大小寫字母、數字和特殊字元，在同時嘗試破譯成千上萬個哈希後密碼的時候，黑客不會有充足的時間針對其中一個進行特殊進攻。在這種情況下，這個密碼很難被破解。但是如果有時間或有目的地只向著一個密碼專門進攻（比如某個有特別價值的賬號，某個富豪、或者某個公司的財會或IT賬號），我們可以看到前九位都是字母，特殊字元@後面都是數字，前五位是英文ILove，後四位是當前年份。這些常見規律會極大地降低密碼分析的難度，從而使得解碼變為可能。

我曾經做過一個實驗，（合法但不為人知地）獲取到了某一個用戶系統內的五千餘條真實的用戶信息（用戶名+哈希過後的密碼），使用了某個在網上可以下載到的黑客哈希破解工具，在一個半小時內將超過半數的密碼破解掉，其中包括abc123或者root這種低安全等級密碼，也包括類似alice_lee007，AllHailNY1這種可能看似足夠安全的密碼。

整個破解過程中幾乎不需要任何專業知識，只需要知道怎麼用幾個工具而已。

針對薄弱的哈希演算法，我們可以使用更強力的哈希工具替換，但是仍然不能完全保證不被破解。

真實的黑客破譯方式是多元的，比如一個弱密碼使用任何哈希演算法都不能真正防禦彩虹表進攻。而且，上面例子中的兩個弱點指的只是解碼過程中的弱點，還沒有算傳輸過程中可能的弱點、中間人進攻、中途相遇進攻、釣魚進攻、病毒木馬進攻、跨域腳本進攻等等防不勝防的進攻方式，甚至用戶自己也會把密碼寫在某個公開的位置（紙上、文件里、借給別人用）。如果能通過別的方式直接獲取到密碼，那麼甚至連解碼都不需要了。

而如果想要增強密碼強度，我們可以來看看一個真正的強密碼的例子，由 LastPass 軟體生成：

強密碼舉例：hzMVX*4AjPve9skC

完全無法記憶，沒有任何規則，長度16位，包括隨機數量的大小寫字母、數字和特殊字元。只有在這種情況下，黑客才會被迫和演算法本身硬碰硬。有跡可循的密碼同時也讓黑客有跡可循。

好記的密碼，同時意味著更容易被破解。

大家可以比對一下，自己最常用的密碼，到底是屬於強密碼範疇，還是屬於剛才例子中會被我輕鬆破解的範疇。如果你想每個應用都換個不同的強密碼的話，那麼記憶將完全不可能，只能使用工具代為輔助。

50個最常用的密碼

上圖摘自http://wpengine.com，他們選取了一千萬個密碼並做了詳盡的數據分析，可以明顯看出，大多數用戶都使用了非常弱的密碼，絕大多數用戶對於身份安全幾乎沒有任何理解或防範。鏈接在此：Unmasked: What 10 million passwords revealabout the people who choose them 。

不完整的救星

針對這種解碼方式，最直接的對抗者就是加「鹽」。在密碼中添加一段隨機字元叫做「鹽」，然後再通過哈希演算法計算。這樣得出的結果，就算是兩個完全相同的密碼，由於「鹽」不一樣，結果也會南轅北轍。

如果你開發的網站或使用的網站恰當地使用了加「鹽」，那麼你的用戶密碼安全就比其他網站都會更勝一籌。

但是，每當引入一種新的安全機制的時候，就會同時衍生出各種新的進攻點。如果一個用戶的「鹽」被獲知，就會極大地降低解碼的複雜度。保護「鹽」又成了關鍵的任務。

針對加鹽密碼哈希的弱點和攻防，這裡有一篇由 伯樂在線 翻譯的非常專業的普及文章，如果希望了解更多看更多例子，或者對密碼安全的複雜度認識不夠的話，請看：「加鹽密碼哈希：如何正確使用」。

然而就算是使用了最最專業的密碼保護措施，把自己的用戶密碼保護地像一座堡壘一樣萬夫莫開，也有一個最最關鍵、卻又沒有解決的問題：

在不斷的攻防之中，我們可以把一個系統保護地固若金湯，但是我們沒有辦法保護別人的系統。在70%用戶在多個網站使用同一個密碼的情況下，如果攻破了別的網站，也就相當於攻破了你的。無論你使用了怎樣的保護機制，如果只有用戶名+密碼，那麼就會形同虛設。

在用戶名+密碼的安全系統內，這個問題無解。

這是用戶名+密碼的最大限制和最大威脅，也是得出「不安全」結論的致命一擊。

在國外，已經有80%的人對他們的在線身份安全感到憂慮，同時有超過70%的人認為用戶名+密碼的方式不足夠保障身份安全。[2, OKyle]

多因素認證（Multi-Factor Authentication）

阿里雲在用、淘寶在用、百度在用、騰訊在用、魔獸世界已經用了十幾年、微博微信都在用，Twitter在用，Apple 在用，Google、微軟、 Facebook、 亞馬遜 已經沿用很久。什麼是多因素認證？

救星來了。

如果單純的用戶名+密碼不足夠安全的話，那麼就再添加一層認證就好了。這種多重認證方式叫做：「多因素認證」。也叫多重認證。當認證次數為二的時候，也叫二次認證、二次驗證等等。

在支付寶進行支付的時候，會要你在已經登錄的情況下輸入六位支付密碼，並且會確認「安全環境」；在ATM取款機前，你需要同時插入正確的卡片和輸入正確的口令；在使用用戶名+密碼登錄微信公眾號之後，會彈出需要使用微信掃碼才能繼續訪問的界面。在試圖修改阿里雲伺服器的安全組的時候，可能會發送驗證碼到你的綁定手機號；電影大片中開門使用的指紋、虹膜和密碼三位一體……

簡訊驗證碼示例

雖然「多因素認證」這個名字仍顯生疏，但無論是開發者還是用戶，已經早已離不開它的保護。

只要一個賬號有價值，它就應該（或者已經）被多因素驗證保護起來。

想像一下，有多少黑客你可以在遠程黑掉你的用戶名和密碼信息的同時，還能走到你面前搶走你的手機、U盾，或者同時盜用你的郵箱或者指紋？

幾乎不可能有。

如果沒有多因素認證，遇到用戶名密碼泄露，用戶信息就赤身裸體地等著不法人員去翻看。而有多因素認證的保護，尷尬的就該是黑客了。沒有多因素認證保護的用戶系統，絕對不會是一個安全的產品，也就是網路中的「豆腐渣工程」。

網路中的「豆腐渣工程」和現實中的「豆腐渣工程」非常相似：表面看上去毫無問題、需要專業人員才能為其檢測定性、非安全相關人員幾乎沒有能力去辨別，但是一旦有任何風吹草動、黑客攻擊或地震泥流，二者都同樣會崩潰。人們、甚至包括被可能蒙在鼓裡的項目負責人，才會發現安全問題的重要性。

而到那時，損失已成，媒體曝光，悔之晚矣。

「豆腐渣工程」：是指那些由於偷工減料等原因造成不堅固的危險容易毀壞的工程。 （百度百科）

網路中的「豆腐渣工程」：是指那些由於缺乏必要安全知識、或由於為了減少研發開支等原因造成的有可怕安全風險的容易被攻破的網路工程。

我們日常中最常見到的二次認證認證，在國內是由手機驗證碼實現的，在國外是由郵箱實現的。這兩種方式做到的都是同一個事情，都是在已經確認了用戶名和密碼的情況下，再次從另外一個維度去驗證你的身份：確認你擁有綁定的手機、確認你擁有綁定的email。

然而，真正的多因素認證，可以在維持安全性的情況下，遠遠比上面的例子更加靈活。我們來看多因素認證的定義：

Multifactor authentication (MFA) is a security system in which more than one form of authentication is implemented to verify the legitimacy of a transaction. [3, Mohamed]

筆者譯：多因素認證是一種使用多於一種認證元素來驗證當前操作合法性的安全機制。

多因素認證的安全性取決於兩個方面：

其一，單個因素的強度。我們很難說手機上的指紋認證肯定會比用戶名密碼更安全，但是我們知道密碼越長越複雜隨機就越安全，不聯網的硬體通常比互聯網上的軟體安全等等；

其二，兩個元素之間的隔離度。在非法獲取了一個因素的同時，是否更容易獲取另外一個因素，越不容易，隔離度就越好，安全性就越高。在獲取到了手機的時候，如果二次認證使用的是驗證手機號碼+手機指紋的話，很明顯就不如驗證手機號碼+用戶名密碼安全，因為獲得到了手機的時候，手機指紋的破解難度會急劇降低，但破解用戶名密碼的難度可能不變。

在銘記這兩點的時候，我們可以隨意前後打亂我們希望實現的二次認證中的兩個「因素」。不一定要先使用用戶名+密碼進行驗證之後再發送驗證碼到綁定的手機號上。

目前最常見的二次認證，是用戶名+密碼再加上這些驗證方式的一種：第二個密碼、手機號驗證、郵箱驗證、手機App驗證。這之中最常見的是手機號驗證，在企業中常用的是手機App驗證。

手機號驗證的好處很多：最寬廣的用戶覆蓋、用戶沒有任何使用成本、已經成熟的不用學習的使用方式。而且對很多開發者/應用擁有者來講，很關鍵的一點是：可以獲得到真實的可以聯繫到的用戶手機號，並且向用戶隨時發送消息。

缺點也很明顯：

1. 收費。一天如果發1W條的話，按照市面上最便宜的提供商，開支就是10,000條/天 * 0.04元/條 * 30天 = 12,000元/月，十分可觀。

2. 速度不穩定。有多少次你在登錄或者註冊的時候拿著手機靜靜等待著不知道什麼時候會收到的手機簡訊？

3. 用戶使用不順暢。又有多少次你一個數字一個數字地確認自己沒有輸入錯誤？

而手機App的優缺點也很明確：沒有簡訊費用，用戶使用簡便（可以不輸入數字，只按確認按鈕，甚至某些機型可以做到無感知驗證），但是有一個巨大的缺點：用戶需要下載一個應用。這就是為什麼在企業中這種方式可以得到推行，但是在面向普遍用戶的時候，手機App的推行會很困難的原因——簡訊功能誰都有，手機App可不一定。對於面向大眾的服務，每一次身份驗證都會有或多或少的用戶流失，而如果讓用戶下載一個App專門驗證的話，可能用戶就因此而放棄使用整個服務了。

然而，在國內大行其道的目前還是針對大眾的應用，針對企業的服務還仍然處於萌芽成長期。

我自己負責開發過的多個產品，大多也是面型大眾用戶的，在我為它們設計二次認證系統的時候，我一直在尋求一種更加完美的方法。

有沒有什麼方法，能夠降低簡訊驗證碼的成本，同時擁有不遜於手機簡訊的覆蓋率？能夠避免輸入錯驗證碼，或者乾脆無須輸入驗證碼，同時還能夠確保身份驗證的即時性，無須等待？

有沒有辦法把手機App驗證和簡訊驗證的優點結合起來？

或者換個問法，有沒有哪個應用，覆蓋率足夠廣，人人都有都會常用，並且有足夠的開發者許可權允許進行二次開發？

答案呼之欲出。

微信。

微信

使用 微信 的二次認證利弊

使用微信做二次認證的優點：

1. 覆蓋面極廣。你的目標用戶中會有多少希望使用你的應用，但是不使用微信的？

2. 無需安裝。相比於一個需要下載一個新的App來做專門的認證而言，使用已有的無疑對最終用戶來講是個福音。

3. 無須教學。相比於一個新的App，用戶需要時間和精力去學習、嘗試才能掌握。但是人人都已經熟悉微信掃碼的功能。

4. 極低成本。除去開發費用外，只有網路通訊費用，沒有每條簡訊的費用。將通訊商從流程中剔除掉，可以極大降低成本。

5. 穩定的速度。和網速直接掛鉤，在大多數網路通暢的地方，無須等待，掃碼即過，暢行無阻。極大優化用戶體驗。

6. 無須輸入。用戶不用再小心地輸入驗證碼。驗證碼的作用本身就是驗證用戶擁有該手機號，使用微信後可以做到類似手機App認證的體驗，掃碼直接驗證。

有利就有弊。

1. 依賴網路。微信的速度依賴於網路，如果你的用戶經常出現在沒有網路的地方，那麼微信的速度可能還沒有簡訊快。在安全級別非常高的系統中，微信的可用性值得考量。

2. 無法獲取用戶的聯繫方式。在只需要身份驗證的情況下，聯繫方式拿來是沒有用處的。有的系統需要給用戶發送提醒，比如支付、轉賬、密碼修改等等，微信不能靈活地聯繫用戶。使用微信服務號會有很大幫助，但仍然做不到手機號碼一樣靈活。

我們可以看出來，在用戶聯網狀態，在應用方不需要聯繫用戶的情況下，微信的優勢非常明顯。

開發有多困難？

開發完整安全的手機驗證碼二次認證系統不僅僅是一個簡單的調用一個發送消息介面並檢查驗證碼那麼簡單。有非常多的附加功能需要開發，讓這個系統變得真正完善可用。我可以隨便舉些例子：

1. 需要資料庫記錄每次驗證嘗試，可以追溯什麼人在什麼時間做了什麼驗證。

2. 可以驗證時記錄IP、地理位置、使用時間、瀏覽器型號等等，以此為據來進行更多角度驗證。

3. 在驗證過後一定時長內可以不用重複驗證。

4. 需要用戶有綁定微信的入口和伺服器機制。

5. 需要提供用戶解綁微信並綁定新微信的機制。

6. 需要在用戶微信失效、換手機、換號碼、沒有網路鏈接等情況下提供備用驗證方式。

7. 如果使用微信開放平台的話，需要認證費用每年300元，需要提供各種驗證資料，並有至少數天的審核時間。

8. 如果使用微信公眾平台的話，需要認證費用每年300元，除了認證審核外，還需要實現你自己的WebSocket機制和多個前端、手機端流程頁面。

………………

這不是小菜一碟。

集成完整一整套的二次認證系統，在順利的情況下，也會需要幾十個工時的時間。

如果你的團隊有人有錢有時間精力，那自然不在話下。但是對於非常多的創業型項目、外包型項目和一些定製項目，我們會追求速度，追求低成本，追求快速迭代試錯。很可能一個月甚至一兩周就可以出現一版產品的情況下，花費大把的時間在一個與產品業務幾乎沒有任何關係的「二次認證」上，就顯得難以接受了。然而，安全系統是與產品業務系統同枝共長的，如果等到產品發展起來後再考慮安全，成本將會指數提高。

搜遍網路，在國外有Authy，Duo這種成熟的二次認證服務提供給大眾和企業用戶，但是在國內，還是一片空白。開發者想要實現自己系統內的多因素認證，就只能漫道真如鐵，邁步從頭越。甚至任何關於如何搭建二次認證系統的信息都搜索不到。而沒有可用服務的現實，直接導致了非常多的用戶系統不會使用足夠的安全手段去保護。

想像一下軟體和網路正在如何改變你的生活，你的網路身份究竟有多重要，就可以發現開發者對於身份安全有巨大的知識漏洞。

百度搜索結果 「開發 二次認證」

在 2017 年美國 Verizon 信息泄露事故報告中，超過80%的成功黑客行為是基於薄弱、默認或者被盜竊的密碼。[4, Duo Security] 而多因素認證，是最直接、最簡單幹脆能夠抑制住這種極其普遍且極易造成巨大危害病因的良藥。

傳統的二次認證服務提供方普遍有著普通企業根本無法支付的開銷、上世紀80年代古老的用戶體驗和界面，和極其複雜的安裝部署流程，導致了企業和開發者們對購買、集成和維護的強烈抗拒。

但是在任何情況下這都不足以構成忽略基礎安全的借口。

我誠懇地希望產品負責人們、開發者和用戶們都可以意識到網路「豆腐渣工程」的危害，並將一些基本的安全保護措施從一開始就設計進系統中，以免黑客從你們的錢包和信譽中獲利。

「安全第一」這個口號，終究要喊到網路中來。

輕鎖 微信二次認證 服務

作為互聯網安全公司的一員，我們九州雲騰團隊開發了一款微信二次認證的工具，叫做 輕鎖 。輕鎖的最終目的是幫助開發者管理、維護並設計出安全的用戶身份系統，雖然目前只提供微信二次驗證的功能，但是會逐步添加各種面向開發者的安全服務，並逐漸成一個支持各種認證方式、支持內外網並提供所有相關功能的身份認證服務。輕鎖設計的最關鍵理念，除了安全本身，就是快捷。用戶使用快捷通暢，開發者集成快捷無阻。希望 輕鎖 能在設計用戶系統時，給開發者們提供一個真正安全快捷的選項。

如果你是一家企業並有更加廣泛的身份安全需求，可以直接聯繫 北京九州雲騰 或致電 010-58732285，我們的產品包括了身份、認證、授權、審計、應用單點登錄、數據安全交換、掃碼登錄、二次認證等等一整套的企業身份安全服務體系。

世界正在被網路轉化中，而所有的系統、網路、應用的關卡和門鎖，就是身份驗證。身份安全的重要性一再被提及，也一再被忽略。

世界需要的從來都是推波助瀾，而不是隨波逐流。

九州雲騰 Michael

引用（References）：

1. Chad R, Dougherty (Dec 31 2008). Vulnerability Note VU#836068 MD5 vulnerable to collision attacks, Vulnerability notes database. CERT Carnegie Mellon University Software Engineering Institute. Retrieved3 February2017., https://www.kb.cert.org/vuls/id/836068

2. Okyle, Carly (June 3 2015). Password Statistics: The Bad, the Worse and the Ugly (Infographic), https://www.entrepreneur.com/article/246902

3. Mohamed, Tamara Saad (2014) , Security of Multifactor Authentication Model to Improve Authentication Systems, ISSN 2224-5758 (Paper) ISSN 2224-896X (Online), Vol.4, No.6, 2014, http://www.iiste.org/Journals/index.php/IKM/article/viewFile/13871/13939

4. Duo Secruity Inc., 2017, Two-Factor Authentication Evaluation Guide, https://duo.com/resources/ebooks/two-factor-authentication-evaluation-guide

推薦閱讀：