讓用戶在輸入密碼時看到明文吧
在 2012 年時，我(英文原文作者)曾解釋過為什么應該 讓人們在輸入密碼時看到明文 ，尤其是在移動設備上。兩年過去了，相關的實踐模式越來越多的進入我們的視野。
為什么要顯示密碼明文？
密碼輸入方面的可用性問題被詬病已久。復雜的安保要求(最少 xx 個字符、必需包含標點符號和大寫字符...)以及難用的輸入方式等等時常會使用戶產生強烈的挫敗感，甚至蒙受損失。
數據顯示， 約 82% 的用戶曾經忘記過密碼；找回密碼是使用頻率最高的功能之一；如果人們在網購過程中忘記密碼并嘗試找回，那么其中約有 75% 的用戶不會完成最終購買。可以說，密碼這種機制的弊端是越發明顯的；而在移動設備上，受到使用情境及設備自身在顯示和操作等方面的局限，情況則變得更加糟 糕。
密碼遮罩使本就復雜的輸入變得更加困難，而且對安全方面的貢獻著實有限，尤其是在移動設備上 - 鍵盤就位于輸入框下方，你輸入字符時，對應的按鍵還會突出顯示，其中的字號比輸入框里的更大。所以在現實中，如果真的有人想在你身旁偷窺，密碼遮罩其實起 不到什么保護作用；這種情況下，倒是把手機拿到一個更隱蔽的地方進行輸入來的更安全。
切換隱藏與顯示
出于所有這些原因，我們決定在 Polar 的登錄界面將密碼明文呈現給用戶，并在密碼欄右側提供一個隱藏按鈕，如果你確實需要，便可以點擊該按鈕將密碼切換為遮罩符。
雖然我相信這是有利于可用性及可訪問行的正確做法，但還是有些擔心用戶看到密碼明文后會產生負面感受，畢竟長久以來的遮罩設計模式已經使人們產生了“安全”的認知習慣。
所以，當我聽說有人不僅發布了以明文呈現密碼的產品，而且還取得了成功的事情之后，覺得很是驚喜。在這篇推中，Steven Hoober 告訴我們，兩千萬的 Sprint 用戶已經在使用著移除了密碼遮罩的產品，沒有遇到任何問題；Mike Lee 也說，當時 Yahoo!的改版當中包含了移除密碼遮罩等一系列改進，并帶來了兩位數的增長幅度，并且沒有發現任何安全方面的問題。
在我看來，密碼遮罩突然間就變成了舊事物，一個存在了很長時間的設計模式開始被逐漸的質疑和唾棄。回頭看看，我們曾經那么理所當然的把密碼遮罩當作默認模式來使用，而對可用性甚至是業務的損害也隨之而來。
解決方案
最近一段時間，很多公司開始認真對待密碼遮罩的問題了，并帶來了很多不同的解決方案。PayPal 和 Foursquare 采用的就是前面提到的我們在 Polar 當中使用的模式：
LinkedIn、Adobe 和 推ter 也是類似，不過將文字按鈕改為了睜一眼閉一眼的圖標。圖標形式有利有弊，一方面可能不如文字形式那么顯而易見，但另外一方面，對于有國際化需求的產品來說，可以避免譯文長度難以控制的問題。
微軟采用的實踐方式略有不同。在 Windows 8 中，密碼默認仍以遮罩形式顯示，按住右側的眼睛圖標可以查看密碼明文，移開手指后再次恢復遮罩狀態。
Amazon 一直在反復迭代著登錄表單的設計模式：最初是無法查看密碼明文，就像大家一直以來那樣；后來允許用戶勾選是否顯示密碼明文，但默認仍是顯示遮罩；接下來就是默認顯示密碼明文，但允許用戶勾選使用遮罩模式。
雖然這些方案各有利弊，但最重要的一點是，微軟、Adobe、推ter、LinkedIn、PayPal、Amazon 以及其他很多公司都已經意識到了長久以來存在于登錄表單當中的可用性問題，并大膽的進行了改變。
設計在細節中
雖然越來越多的公司開始嘗試讓用戶在輸入密碼時看到明文，但這并不意味著你可以隨便拿來某種模式扔到自家產品中。實際上，正是這種人云亦云的思維模式讓我們長久以來一直在使用那些其實不那么合理的設計模式，包括密碼遮罩。
更加可取的是，試著花些時間結合自己產品的具體情況真正研究一下各種方案的利弊，要知道這些細節當中的變化是有可能對產品產生很大影響的。我們不妨來看看 Jack Holmes 做的關于移除密碼遮罩研究。
Jack 的測試表明，對于電商類產品，當登錄密碼默認以明文形式顯示的時候，60% 的被測用戶感到不安，他們覺得這可能是網站中的 bug 或某種嚴重的安全隱患，只有 45% 的用戶認為這種方式相比以往更加好用；而在默認顯示明文并提供復選框來恢復遮罩的模式下，100% 的被測用戶意識到這是一個正常的功能改進，而且不會影響到他們對這個電商網站的信賴感。
從 60% 的疑慮，到 100% 的認可 - 細節中的設計真的事關重大。從這個研究結果來看，Amazon 決定采用“默認顯示密碼明文，允許用戶手動隱藏”的模式不是沒有道理的。
Web v.s. App
前面提到的都是應用或系統中的案例，但目前在頁面端采用這類模式的還不多見。都是一樣的服務，為什么要讓通過瀏覽器訪問的用戶不得不面對比較難用的界面呢？
不外乎是安全方面的顧慮，尤其是這樣一種情況：
- 我的設備有可能被你使用
- 你解鎖了我的設備
- 你打開了一個網站
- 我正好在瀏覽器中保存了登錄這個網站所用到的密碼
- 這個網站正好提供了查看密碼明文的功能
- 于是你知道了我的密碼
Web 瀏覽器將密碼保存及自動輸入功能與查看密碼明文功能搭配在一起使用確實是一件非常危險的事，可能帶來嚴重的安全問題。降低危險系數的一個做法是，如果探測 到瀏覽器已經自動填入了之前保存的密碼，那么就在頁面中把密碼框直接隱藏起來；如果有人想查看密碼，那么密碼框會清空，用戶需要重新輸入密碼；此時輸入的 密碼為明文，并允許切換為遮罩模式。
遺憾的是，在網頁端實現這套方案所需付出的設計和開發成本似乎已經超出它能帶來的潛在價值。
超越密碼
在移動端登錄的問題上，Amazon 從未停止過迭代。在最近的 iOS 版本中，他們甚至移除了密碼登錄，讓用戶可以直接通過 Touch ID 驗證身份。
Uber 走的更遠些。要通過他們的服務來叫車和支付，你甚至無需創建賬戶、輸入密碼、填寫復雜的支付信息 - 所有的身份認證工作都可以通過 Touch ID 完成(使用 Apple Pay)。
雖然 Touch ID 僅限于 iOS 設備，但這確實是一種極大降低身份驗證操作成本的新標準。如果人們能自主選擇登錄或支付的方式，你覺得大家會選擇復雜的表單、亂七八糟的密碼規則及不可見的密碼遮罩，還是一個簡單的觸摸？
從這個角度看問題的話，登錄表單和密碼機制的未來就變得清晰起來；這些甚至不會再成為問題。