有時候想安全，就得犧牲掉一些使用者體驗，而一些更好的使用者體驗會犧牲掉一定的安全性，所以安全性與使用者體驗有時候是一對矛盾體，得想辦法做tradeoff。
比如說驗證碼，captcha，現在很多**在登陸或者提供的其它服務會讓使用者輸入驗證碼來驗證操作是由人發出的，而不是robot發出的，前提是robot無法破解你所採用的驗證碼。而這樣所有的登陸操作，不管是人還是robot都會面臨驗證碼，也就是說為了防止robot，讓真正的人去輸入驗證碼，給人增加了一定的負擔。
而如果不讓輸入驗證碼，那麼所有的robot又都等順利的模擬操作，那麼最後的結果是採用驗證碼。
這是0和1的思維，其實可以換一種思路，我們現在的目的就是為了防止robot，所以如果我們能判定是robot，那麼我們就給他展示captcha，如果不是robot，就不展示captcha，當然這是理想情況。所以說關鍵是怎麼檢測出robot，一般會放一些robot detection service來處理所有的請求，然後進行分析，動態調整引數，比如可以根據ip位址，fingerprint，如ubid等。然後來乙個請求，判定是否是robot，如果是robot就展示captcha。
所以大家看到，如果我們的robot detection service將所有的請求都判定為robot，那就是對所有的請求都採用驗證碼。是0和1思維中的1. 如果將所有對請求都判定為非robot，那麼就不展示robot，是0和1思維的0.
而怎麼調整判定的引數就看需求來定了，越小，使用者體驗越好，但是安全性降低，越大安全性越好，使用者體驗越差。所以就可以根據需求動態的進行調整了。
還有很多其他的例子，比如你在一台裝置上登陸，可能只需要使用者名稱密碼就可以了，但是在另一台裝置上登陸，它可能還會給你一些dynamic challenge questions，比如給你手機發pin碼等。這就是很好的在產品易用性和安全性折衷的例子。
好了，希望可以給你一些啟發。
原文:hongchangfirst
hongchangfirst的主頁:
系統安全性設計
系統安全性設計可以劃分為如下幾個層次 程式設計安全性 程式部署及作業系統安全性 資料庫安全性 網路安全性 物理安全性 就程設計的安全性,針對現在大多系統的分布式結構,因為同時要面向不同地理位置，不同網路位址，不同級別，不同許可權的使用者提供服務，稍不留神就可能產生潛在的安全隱患，如下是最常見的由設計...
paip 提公升使用者體驗與安全性 註冊流程總結
paip.提公升使用者體驗與安全性 註冊流程總結 限制使用者輸入國內top100的口令 1 限制使用者輸入國外top500的口令黑名單 1 限制輸入常用字典黑名單口令 1 口令長度7 20位 1 口令為純小寫字母，長度應為12位及以上 2 口令為純數字式,長度應為17位及以上 2 增加口令強度檢測u...
paip 提公升使用者體驗與提公升安全性 記住密碼
paip.提公升使用者體驗與提公升安全性 記住密碼 前幾天使用金山快盤.是使用記住密碼功能的 結果電腦硬碟因其它原因，被其它人取走。這成了乙個很大的安全隱患。需要我在網上及時修改密碼才可以確保別人不可以操作我的文件。但是修改密碼增加了記憶負擔.需要可以不修改密碼的情況下，就可以達 到此目的，以提公升...