為什麼無密碼認證能夠有效

2014年12月，我釋出了一篇名為“Would You Implement Passwordless Login”?它對其他文章做了擴充，例如“Justin Balthrop’s Passwords are Obsolete”和“Ben Brown’s is it time for passwordless login?”Node.js的無密碼專案激發了其他語言，包括PHP和Ruby。

我提到過我正在構思一個無密碼認證的客戶端專案，我很高興，它已經運轉了幾個月，並且已經成為一個啟示，不久將介紹更多內容，但是首先讓我們先複述一遍……

什麼是無密碼認證？

我們還在使用網路初期設計的認證方式，不幸的是，密碼越來越容易破解。

調查顯示有十分之一的帳號使用的密碼包含在前20個使用最多的密碼中，超過4%的帳號使用“12345”作為密碼，“password”任然是第二個最常使用的密碼。

人們在多個網站上使用同一個糟糕的密碼。如果你碰巧破解了某人的facebook的帳號，你就很有可能進入他的的PayPal賬戶，你的唯一密碼就跟你使用的安全性最弱的系統一樣糟糕。

群體黑客行為越來越常見並且引起了主流媒體的關注，給自己建立一個名稱，提取報復或沉溺於勒索是一件很容易的事。很少公司做好應對恐怖主意的行為準備，很多突破口其實就是由很差的開發技術引起的sql注入，儘管通常都聲稱是由“持續的攻擊”引起的。

從編碼的角度來看，身份認證是一個冗長乏味的過程並且容易犯錯，檢查證照時問題的開始，你需要通過強（或若）演算法得出的雜湊字串來確保安全性沒有被破壞。允許使用者重置忘記的密碼，並且給那些似乎不能想起或不能打出密碼的困惑的人提供客服電話支援。

還有其他可選的解決方案，如基於硬體的生物識別技術和基於合適的社交媒體帳號的第三方認證，很少有網站能夠把它們做好，部分人還是得回到郵箱密碼的認證方式。

無密碼認證方式的前提是：當使用者中的大部分人都擁有一個安全的個人通訊帳號如郵箱或簡訊時密碼不再是必須的。應用程式可以使用下面的系統：

1：登入時，使用者訪問一個網站並輸入郵箱之類的Id。

2：它們傳送一條帶有連結的資訊，點選後就能登入。

換句話說，應用建立了一個隨機的、一次性的密碼，並且在使用者需要訪問的時候悄悄地告訴他們。這跟重置密碼的過程類似，這是許多使用者每次登入的時候都會幹的事。郵箱是首選，但是其他的通訊服務也可以被利用，如簡訊、Slack、Skype，及時訊息甚至於Twwiter的直達訊息。如果你不想依賴一個系統，你可以多個選擇。

系統後臺確保登入連結只能有一個人使用比看起來要複雜，通常的處理過程如下：

1. 當進入的時候，系統驗證確實存在跟郵箱繫結的帳號；

2. 伺服器建立兩個識別符號，如24個字元的16進位制全球唯一識別符號，然後把這兩個識別符號都跟登入嘗試相關聯。第一個識別符號被髮送到登入裝置，通常是作為一個瀏覽器的cookie，第二個識別符號被編碼到連結中傳送到使用者郵箱；

3. 當連結被點選的時候，伺服器將收到兩個識別符號，通過它們來驗證登入嘗試，另外，還可以做更進一步的檢查來確保連結在幾分鐘內被點選以及ip地址和瀏覽器的user-agent字串沒有變。

4. 如果每一個都驗證通過，一個真的session被建立，使用者登入成功；如果有一個驗證不通過，所有相關的識別符號都要被銷燬，不能再被使用。

無密碼認證的好處：

對使用者來講相當簡單。不需要建立和儲存密碼，除了你的通訊服務，不再需要其他的社交帳號或者第三方軟體，註冊必須要有合法的認證；

更加安全。沒有儲存密碼也就沒有東西可以被攻擊或猜測，及時某人擷取了你的資訊，他也只有一個識別符號，還是不能登入；

經濟上更划算。需要編寫和釋出的程式碼更少，登入程式碼大部分被另外一個具有超強安全性的服務所處理，你的支援團隊從無窮無盡的密碼問題中解放出來。

無密碼認證可以被用在哪？

登入時花的時間更長，但是使用密碼管理工具同樣花時間。無密碼認證適用於那些擁有合理的較長session有效期的應用，或者使用者不需要經常登入的應用。購物網站、社交網路、論壇、訂票系統和內容管理系統都是好的應用例項。

在通訊服務系統上使用無密碼認證會很奇怪，因為你將需要另外一個通訊系統來登入。你也不會讓你的銀行賬戶安全性唯一的依賴於你的Aol，儘管第二道身份識別過程會做補充。

當你在建立一個新的應用的時候可以考慮使用無密碼方式，然而，更新一個已經存在並且有很多使用密碼的使用者的應用將面臨許多問題，我建議同時使用兩種登入方式而不是突然就切換為一種新的登入方式。把無密碼認證作為一種選擇，尤其是對於那些需要充值密碼的使用者，等幾個月以後再通過評估來決定是否可行。

真實測試

我在一個新的客戶端應用上使用無密碼認證方式，這個應用給幾百個內部員工和外部客戶使用，這些人裡面大約有一半具有好的IT技能並且每天都登入，所以他們的session很少過期，另外一半幾乎都是一兩個月才登入一次的管理人員，他們中許多人會忘記密碼或拼錯密碼。

最大的問題：必須要讓顧客深信這是安全的

“無密碼”聽起來不安全，並且很少有人在其他地方看到使用，我很幸運，那個客戶端應用有一個科技悟性很強的並且理解這個觀念的專案經理，即使在那時我已經同意如果有任何一點失敗時可以新增密碼。

從那個時候開始事情變得一帆風順，由於技術上的原因，我不得不整合我自己的實現而不是依賴於第三方庫。這個過程花了不到一天的時間，並且不需要再做密碼管理——我們通常開發和測試的那些取雜湊值、重置密碼等沒有意義的工作。

最大的額外好處：使用者理解了無密碼認證方式。這個過程很簡單，但它是在各個階段提供簡單指示的最好方式。例如：

1．一個登入連結已經傳送到您的郵箱，如果沒有收到請檢查一下垃圾郵件。

2.請點選這個連結來登入…您有10分鐘時間在同一個瀏覽器中開啟這個連結。

沒有人感到困惑，沒有人掙扎，沒有人讚美這個系統但是也沒有人抱怨，人們接受這個過程並且它也沒有阻礙人們，跟密碼相關的登入問題從三到四周每次減少到0。

結論

我不能聲稱無密碼認證方式在哪都可以用，但是經驗已經表明它絕對的正面。我是一個改變觀念的人，從今以後所有我的應用都將是沒有密碼的，一些使用者可能會不高興，但是我將僅僅在他們的登入表單中彈一個虛假的密碼框並且忽視它。

原文連結：http://www.gbtags.com/gb/share/9521.htm