無需密碼登陸的時代，到了嗎？

編者按：本文是一名軟件開發者寫的 博文，討論了目前各大網站密碼登陸系統存在的問題，并舉出了幾種可能的身份驗證方案，歡迎讀者討論，拍磚。

        你肯定有過這樣的經歷，不管登陸哪個網站，都需要輸入各種用戶名和密碼。除了密碼容易忘以外，現在移動設備越來越普及，在小小的屏幕上輸入用戶名和密碼也更麻煩了。事實上，即便是那些人氣超高的網站也經常會收到用戶關于登陸的各種問題反饋。

        怎么才能讓上面的登陸過程變得盡可能簡單呢？假如用戶想通過多臺設備訪問我們的產品，那他們為什么一定要在每臺設備上輸入自己的用戶名和密碼呢？可不可以不輸這些符號呢？

        在回答這個問題之前，讓我們先看看目前市面上的登陸體系：

        可以看到，非死book 的登陸頁面有 6 個不同的控件（點擊會出現不同結果的控件，比如上面的 Log In 按鈕）。

        而 Yahoo 的登陸頁面放了高達 9 個不同的控件。

        因為有些用戶已經有賬戶，而有些用戶是新來的，所以網站還需要在登陸頁面添加注冊這一選項。對老用戶來說，在最好的情況下，他們也需要輸入一次 用戶名和密碼。假如密碼和賬戶不匹配，他們通常會在信息提交之后才會被告知，所以就需要同時重輸用戶名和密碼。實在記不住的時候，還需要通過郵件重置密 碼。而對新用戶來說，他們除了在注冊時需填寫用戶名和密碼以外，一般也都需要登錄自己的郵箱來核實郵件地址，才能激活賬戶。

        針對這個問題，lukew 提到了一種登錄的設計模式：允許用戶名字段自動填充。用戶可以從一系列現有的名字中選擇自己的名字，而不是全部手動輸入。然后，假如用戶成功登錄過一次，網站起碼可以永遠記住用戶名，下次為用戶自動提供。

        我認為這一步的方向沒錯，因為這樣用戶就只要記住密碼就行了。而且，假如用戶輸入的名字沒有跟列表里面的名字匹配，軟件還可以自動從登陸轉到注冊這一項。

        但是，這種方案還是要求用戶輸入自己的密碼，這些密碼要么長得奇形怪狀不容易記住，要么就會像之前的 lukew 網站披露的那樣，都是一些“123456”這樣無效的傻子密碼，根本達不到保護賬戶的目的。

        我自己個人更喜歡，認為更好的一個方案是，將輸入密碼這一步也完全剔除。目前，已經有一些系統允許用戶無需輸入用戶名和密碼就登錄，其中以 Oauth 最受歡迎。Oauth 的方法是：允許用戶使用其他服務上已有的賬戶登錄，比如說 推ter 或者 非死book。但是，用戶用上面的社交賬戶登錄 Oauth 卻有潛在風險：容 易泄露自己的好友列表和自己的社交網絡資料。而對 Oauth 自己來說，假如第三方軟件的 API 改變，或者一個外部宕機，都可能對自己的服務產生影響。而且，盡管 Oauth 想要簡化登陸流程，但是在某些情況下，它的用戶也有可能會被導向諸如 非死book 或者 推ter 這樣的第三方服務，然后他們還是需要輸入這些服務的用戶名和密碼，并被這些第三方服務要求授權給 Oauth，才能最終登陸 Oauth 自己的服務。整個登陸過程真的被簡化了嗎？

而我的方案是：讓用戶直接通過自己的 email 登陸。用戶在第一次使用的時候輸入自己的 email 地址，以后需要登錄的時候，他們直接通過收到的郵件里面的鏈接登陸賬戶，而根本不需要記各種各樣的密碼。

        假如我們將這種方法跟上面 lukew 提到的用戶名自動填充方法結合，那么老用戶就只要點幾下（選擇用戶名，點擊郵件里面的鏈接），而無需輸入就實現登陸。而對新用戶來說，整個過程也是類似的：他們只需在注冊時輸入自己的 email 地址，然后他們在核實郵件地址的同時，點擊里面的鏈接，就可以登陸賬戶。

        而且，這個認證系統除了應該簡化用戶的登陸過程以外，也應該被設計成允許登陸鏈接在多個設備上使用。設想一下，假如你的新用戶只要輸入 email 地址一次，就可以在他們的手提電腦，手機，平板和其他任何設備上登陸你的軟件，是不是很方便呢？此外，這個登陸鏈接還應該可以擴展到移動設備的原生應用上。也就是說，用戶點擊鏈接之后，就可以一邊打開應用，一邊把驗證細節傳過去。而對 web 端的應用來說，整個過程就更簡單了：用戶只要點擊一次，就可以即登即用。

        不過為了保證安全，上面的登陸鏈接應該有一個生命期，只能被使用一次，或者在一小段時間內有效。這些鏈接可 以被存儲在瀏覽器的歷史記錄里面，或者存在代理或者緩存系統里面。而且，我們必須記住，上面提到的登陸方法也有一個大前提，即你的郵箱賬戶一直是安全的， 而這也是大多數密碼重設工具假定的大前提。所以出于這方面的考慮，我并不建議那些存儲敏感信息應用也通過同樣的方法驗證用戶身份。