企業級服務產品安全｜ToB產品的登錄安全

企業級服務產品安全｜ToB產品的登錄安全，企業級服務產品，產品安全是使用者選擇時的關鍵因素，在登錄安全，密碼安全，設備安全等三個方面都要做到周全且極致。

多設備同時登錄並不是不安全

目前市面上多數產品都是單設備登錄的，即一台手機終端+一台電腦終端，當使用其他設備登錄同一帳號時，需要將其他設備登出，保證同一帳號同一時間僅可在一台設備登錄；用慣微信QQ的使用者有時會與我回饋，說這樣使用起來產品多安全， 只能一個設備登錄，你的產品採用同樣的策略，使用者也不會有所不爽。

但實際上，即使產品支援多設備登錄，也非不安全，在使用上，既滿足了工作場景下的多設備的方便使用，在帳號安全上其實並沒有形成相對的劣勢。 只是在產品設計上，要更多的考慮很多功能設置項的全域統一性，對於服務端統一處理、終端與服務端請求的即時性和弱網下的請求處理的即時性要求並相對較高，因為使用者不會管你是不是本地操作還是服務端操作，他們要的是一樣的體驗。

設備授權一定要操作簡單且流程閉環

多設備登錄，需要對設備授權登錄及裝置管理進行閉環設計，比較常用的授權方式為短信驗證碼授權，也可以做設備之間的快速授權，但由於目前蘋果推出新規定，IOS設備的deviseID已不唯一， 因此設備之間已無法用deviseID做唯一設備標記，因此短信驗證碼為更平穩的做法，也是比較安全的做法。

單設備登錄提升安全性，也可以做設備登錄授權。

裝置管理中的授權記錄，授權取消可操作，及登錄日誌的記錄是閉環流程的方式

密碼安全要結合登錄框架設計，雙管齊下

技術角度上來看，要儘量少的將密碼暴露在登錄過程中，即像網頁端輸入帳號密碼的形式可以考慮在整個登錄框架中進行弱化處理，對這種形式的登錄方式也要儘量做好雙因數校驗，即密碼校驗+手機號校驗。

保證設備安全基礎之上，儘量通過設備授權其他端，比如網頁端或者桌面端去進行登錄，比較典型的列子是微信。

密碼修改有兩種流程設計方式：

驗證手機號後直接修改密碼（手機號驗證越來越常用，也相對安全）驗證舊密碼，設置新密碼（這種比較老套了）關於密碼的強度設計，不同安全等級會有不同設計

關於密碼的強度設計，不同安全等級會有不同設計，可以在服務端配置一套規則，隨時根據回饋和資料調整，不需要跟隨發版。

下面是我在設計整套密碼規則時在網上搜來的相對詳盡的打分規則，大家可以參考：

密碼長度：

0 分: 小於等於 6 個字元10 分: 6 到 10 字元25 分: 大於等於 10 個字元

字母:

0 分: 沒有字母10 分: 全都是小（大）寫字母20 分: 大小寫混合字母

數位:

0 分: 沒有數位10 分: 1 個數字或數位連續或數位連續20 分: 大於等於 3 個數字

符號:

0 分: 沒有符號10 分: 1 個符號25 分: 大於 1 個符號

獎勵:

0 分: 字母和數位2 分: 字母、數位和符號5 分: 大小寫字母、數位和符號

減分:

-10 分: 3位及以上連續數位字母或3位及以上重複數位字母-20 分: 字母、數位和符號5 分: 大小寫字母、數位和符號

最後的評分標準:

>= 90: 非常安全>= 80: 安全（Secure）>= 70: 非常強>= 60: 強（Strong）>= 50: 一般（Average）>= 25: 弱（Weak）>= 0: 非常弱

基於打分標準啟發，以下是我整理設計的密碼規則，重點是加入了弱密碼的檢校和提醒，以及密碼強度檢測，大部分對密碼安全有要求的需求，以下規則基本可滿足（轉載請標注出處，謝謝）：

| 目標

靈活化密碼規則

排除掉簡單密碼：123456a 123qwe 123abc 111aaa

常規密碼標準：6到20位字母和數位的組合? 密碼強度達到一般即符合標準 **弱密碼標準下 30及以上

中等密碼標準：6到20位字母和數位的組合?密碼強度需達到強 ?**50分及以上

強式密碼標準：6到20位字母和數位的組合?密碼強度需達到非常強 ?**70分及以上

| 密碼規則

基本規則：6到20位字母和數位的組合

增加弱密碼庫：密碼庫基礎

在以上基礎上，密碼強度檢測：一般-強-非常強（調整文案思考：能降低使用者絞盡腦汁設置密碼的心理壓力，並能給使用者所設置密碼點信心，不出現弱字眼，弱密碼就不讓使用者成功設置）

【一般】密碼標準：基礎密碼規則即為一般密碼

【強】密碼標準： 大小寫混合字母 或 包含符號 或 密碼長度大於12個字元

【非常強】密碼標準：大小寫混合字母 且 包含符號

| 提示文案

密碼設置提示文案：

使用者設置的密碼為弱密碼庫中密碼，則提示「您設置的密碼太過常用，極易被破解，請更換設置」，不允許提交

強度檢測提示文案：

一般：大小寫混合字母或加入符號可提高密碼強度

強：大小寫混合字母或加入符號可提高密碼強度

非常強：密碼已很安全，請牢記

| 弱密碼庫（維護在服務端，可隨時擴展）

123qwe

qwe123

1234qwer

qwer1234

abc123

123abc

abcd1234

1234abcd

password

qq123456

123456qq

123456a

a123456

123qweasd

qweasd123

1q2w3e4r

q1w2e3r4

1q2w3e4r5t

q1w2e3r4t5

有些需求下，並不需要打分機制那麼複雜的設計，以下是簡化版的設計（轉載請標注出處，謝謝）：

| 基礎規則：

6-20位字母和數位的組合

| 補充條款：

不可以包含5個及以上重複數位/字母

不可以包含5個及以上連續數位（正序/倒序）

| 不能是以下10個常用密碼：

Top 10 most used password :

123qwe

1234qwer

abc123

abcd1234

password

qq123456

123qweasd

1q2w3e4r

q1w2e3r4

1q2w3e4r5t

服務端擴展規則後 使用者再次登錄時觸發判斷 終端web端跳轉至重置密碼頁面 希望服務端可給出補充提示

「不可包含5個及以上重複數位或字母」「不可包含5個及以上連續數位」「你設置的密碼太簡單了，為了公司資訊安全，請重新設置」對於企業級服務，擴展場景設計補充：管理員可設置安全等級

不同企業對於安全等級要求不同，管理員能力也參差不齊，因此在產品設計上會糾結，是不是為使用者想多了，是不是過度設計，一時陷入這個度的考慮糾結中，可以考慮將這些強度和規則整合成幾個等級的安全等級選擇，把這個選擇權還給企業本身， 如是管理員可開啟是否強制使用者掃碼登錄，管理員可以強制使用者將個人密碼全部設置為強度極強的密碼。

登錄續期如何設計

對於手機終端使用者是無感知票據續期這件事的，升級也多為覆蓋升級，使用者通常使用體驗為一直打開app就可以用，沒有提示過重新登錄或直接踢出。

對於終端基本都是無限續期的處理，網頁端則不盡相同，有7天票據過期，也有5天票據過期，最好的方式是進行登錄頻度的記錄和計算，按照使用者使用頻率，按照一定規律為其在網頁端登錄續期，儘量少的將使用者直接踢出。

另外，特殊身份，比如企業管理員可每次登錄都需要驗證身份，票據也可以設計的短一些；還可以根據使用者IP等計算使用者的常用地點，常用地點+-5公里等規則可以作為使用者是否異常登錄的依據， 也可以因為使用者一直在常用地點登錄作為自動續期的依據。

登錄過程的安全提醒不可缺少

即使在設備授權的基礎之上，也要補齊對於其他設備嘗試登錄的異常提醒，其他設備異常登錄的提醒等。

以下都屬於異常登錄：

密碼多次嘗試登錄失敗設備嘗試獲取授權失敗不再常用地點登錄。