產(chǎn)品設(shè)計中，為什么要讓用戶在輸入密碼時看到明文？

在 2012 年時，我（英文原文作者）曾解釋過為什么應(yīng)該讓人們在輸入密碼時看到明文，尤其是在移動設(shè)備上。兩年過去了，相關(guān)的實踐模式越來越多的進入我們的視野。

拓展閱讀

為什么要顯示密碼明文？

密碼輸入方面的可用性問題被詬病已久。復(fù)雜的安保要求（最少 xx 個字符、必需包含標點符號和大寫字符...）以及難用的輸入方式等等時常會使用戶產(chǎn)生強烈的挫敗感，甚至蒙受損失。

數(shù)據(jù)顯示，約 82% 的用戶曾經(jīng)忘記過密碼；找回密碼是使用頻率最高的功能之一；如果人們在網(wǎng)購過程中忘記密碼并嘗試找回，那么其中約有 75% 的用戶不會完成最終購買。可以說，密碼這種機制的弊端是越發(fā)明顯的；而在移動設(shè)備上，受到使用情境及設(shè)備自身在顯示和操作等方面的局限，情況則變得更加糟糕。

密碼遮罩使本就復(fù)雜的輸入變得更加困難，而且對安全方面的貢獻著實有限，尤其是在移動設(shè)備上 - 鍵盤就位于輸入框下方，你輸入字符時，對應(yīng)的按鍵還會突出顯示，其中的字號比輸入框里的更大。所以在現(xiàn)實中，如果真的有人想在你身旁偷窺，密碼遮罩其實起不到什么保護作用；這種情況下，倒是把手機拿到一個更隱蔽的地方進行輸入來的更安全。

切換隱藏與顯示

出于所有這些原因，我們決定在 Polar 的登錄界面將密碼明文呈現(xiàn)給用戶，并在密碼欄右側(cè)提供一個隱藏按鈕，如果你確實需要，便可以點擊該按鈕將密碼切換為遮罩符。

雖然我相信這是有利于可用性及可訪問行的正確做法，但還是有些擔心用戶看到密碼明文后會產(chǎn)生負面感受，畢竟長久以來的遮罩設(shè)計模式已經(jīng)使人們產(chǎn)生了“安全”的認知習慣。

所以，當我聽說有人不僅發(fā)布了以明文呈現(xiàn)密碼的產(chǎn)品，而且還取得了成功的事情之后，覺得很是驚喜。在這篇推中，Steven Hoober 告訴我們，兩千萬的 Sprint 用戶已經(jīng)在使用著移除了密碼遮罩的產(chǎn)品，沒有遇到任何問題；Mike Lee 也說，當時 Yahoo!的改版當中包含了移除密碼遮罩等一系列改進，并帶來了兩位數(shù)的增長幅度，并且沒有發(fā)現(xiàn)任何安全方面的問題。

在我看來，密碼遮罩突然間就變成了舊事物，一個存在了很長時間的設(shè)計模式開始被逐漸的質(zhì)疑和唾棄。回頭看看，我們曾經(jīng)那么理所當然的把密碼遮罩當作默認模式來使用，而對可用性甚至是業(yè)務(wù)的損害也隨之而來。

解決方案

最近一段時間，很多公司開始認真對待密碼遮罩的問題了，并帶來了很多不同的解決方案。PayPal 和 Foursquare 采用的就是前面提到的我們在 Polar 當中使用的模式：

LinkedIn、Adobe 和 Twitter 也是類似，不過將文字按鈕改為了睜一眼閉一眼的圖標。圖標形式有利有弊，一方面可能不如文字形式那么顯而易見，但另外一方面，對于有國際化需求的產(chǎn)品來說，可以避免譯文長度難以控制的問題。

微軟采用的實踐方式略有不同。在 Windows 8 中，密碼默認仍以遮罩形式顯示，按住右側(cè)的眼睛圖標可以查看密碼明文，移開手指后再次恢復(fù)遮罩狀態(tài)。

Amazon 一直在反復(fù)迭代著登錄表單的設(shè)計模式：最初是無法查看密碼明文，就像大家一直以來那樣；后來允許用戶勾選是否顯示密碼明文，但默認仍是顯示遮罩；接下來就是默認顯示密碼明文，但允許用戶勾選使用遮罩模式。

雖然這些方案各有利弊，但最重要的一點是，微軟、Adobe、Twitter、LinkedIn、PayPal、Amazon 以及其他很多公司都已經(jīng)意識到了長久以來存在于登錄表單當中的可用性問題，并大膽的進行了改變。

設(shè)計在細節(jié)中

雖然越來越多的公司開始嘗試讓用戶在輸入密碼時看到明文，但這并不意味著你可以隨便拿來某種模式扔到自家產(chǎn)品中。實際上，正是這種人云亦云的思維模式讓我們長久以來一直在使用那些其實不那么合理的設(shè)計模式，包括密碼遮罩。更加可取的是，試著花些時間結(jié)合自己產(chǎn)品的具體情況真正研究一下各種方案的利弊，要知道這些細節(jié)當中的變化是有可能對產(chǎn)品產(chǎn)生很大影響的。我們不妨來看看 Jack Holmes 做的關(guān)于移除密碼遮罩研究。

Jack 的測試表明，對于電商類產(chǎn)品，當?shù)卿浢艽a默認以明文形式顯示的時候，60%的被測用戶感到不安，他們覺得這可能是網(wǎng)站中的 bug 或某種嚴重的安全隱患，只有 45%的用戶認為這種方式相比以往更加好用；而在默認顯示明文并提供復(fù)選框來恢復(fù)遮罩的模式下，100%的被測用戶意識到這是一個正常的功能改進，而且不會影響到他們對這個電商網(wǎng)站的信賴感。

從 60%的疑慮，到 100%的認可 - 細節(jié)中的設(shè)計真的事關(guān)重大。從這個研究結(jié)果來看，Amazon 決定采用“默認顯示密碼明文，允許用戶手動隱藏”的模式不是沒有道理的。

Web v.s. App

前面提到的都是應(yīng)用或系統(tǒng)中的案例，但目前在頁面端采用這類模式的還不多見。都是一樣的服務(wù)，為什么要讓通過瀏覽器訪問的用戶不得不面對比較難用的界面呢？

不外乎是安全方面的顧慮，尤其是這樣一種情況：

1. 我的設(shè)備有可能被你使用
2. 你解鎖了我的設(shè)備
3. 你打開了一個網(wǎng)站
4. 我正好在瀏覽器中保存了登錄這個網(wǎng)站所用到的密碼
5. 這個網(wǎng)站正好提供了查看密碼明文的功能
6. 于是你知道了我的密碼

Web 瀏覽器將密碼保存及自動輸入功能與查看密碼明文功能搭配在一起使用，確實是一件非常危險的事，可能帶來嚴重的安全問題。降低危險系數(shù)的一個做法是，如果探測到瀏覽器已經(jīng)自動填入了之前保存的密碼，那么就在頁面中把密碼框直接隱藏起來；如果有人想查看密碼，那么密碼框會清空，用戶需要重新輸入密碼；此時輸入的密碼為明文，并允許切換為遮罩模式。

遺憾的是，在網(wǎng)頁端實現(xiàn)這套方案所需付出的設(shè)計和開發(fā)成本似乎已經(jīng)超出它能帶來的潛在價值。

超越密碼

在移動端登錄的問題上，Amazon 從未停止過迭代。在最近的 iOS 版本中，他們甚至移除了密碼登錄，讓用戶可以直接通過 Touch ID 驗證身份。

Uber 走的更遠些。要通過他們的服務(wù)來叫車和支付，你甚至無需創(chuàng)建賬戶、輸入密碼、填寫復(fù)雜的支付信息 - 所有的身份認證工作都可以通過 Touch ID 完成(使用 Apple Pay)。

雖然 Touch ID 僅限于 iOS 設(shè)備，但這確實是一種極大降低身份驗證操作成本的新標準。如果人們能自主選擇登錄或支付的方式，你覺得大家會選擇復(fù)雜的表單、亂七八糟的密碼規(guī)則及不可見的密碼遮罩，還是一個簡單的觸摸？

從這個角度看問題的話，登錄表單和密碼機制的未來就變得清晰起來；這些甚至不會再成為問題。