記住密碼功能如何設計？

01-28

cookie裡面需要保存哪些東西？如何確保安全（或者如何給cookie加密）？
我是新手，希望介紹得詳細些、簡單些（夠用即可，太複雜偶看不懂）。
謝謝！

@Alexander的回答已經是基本的實現了

我就從測試的角度來詳細說明一下怎樣才是合格的"記住密碼"實現

1. 首先用戶基本能夠完成自動登陸流程

重新啟動客戶端/瀏覽器, 不需要輸入密碼可以登陸

重啟設備後依舊可以自動登陸

2. 用戶更換網路環境自動登陸有效

同一設備採用有線網路,無線網路,臨時中斷網路不影響規則1的邏輯

*安全係數較高的業務可能對ip有自動進化的白名單, 此時規則2呈受限狀態

3. 用戶更改密碼後原有的自動登陸失效(包括且不限於本機的自動登錄)

保證被盜用後/在其他機器上登陸過的信息可以遠程"掛失"

4. 可取消

用戶的登出(明確的Logout)操作使原有的自動登陸失效(包括且不限於本機的自動登錄)

並且可以關閉自動登陸/記住密碼

重新安裝軟體/客戶端必須是失效的(否則你手機卸載了陌陌,回家老婆重裝一次居然可以自動登陸,後果就....)

接下來的就是純安全層面的了

5. 不可逆(針對本地的token/票據/認證)
token(理論級)不可逆向出除用戶id以外的信息,包括不限於賬號,密碼,登陸ip

6. 不可猜測/碰撞
簡單測試:當存在100w有效token時,token值域內隨機生成1w個新token不能出現碰撞

為什麼是1w個? 因為token的驗證是需要有網路開銷的. 當短時間內出現1w個密集請求的時候如果你還不能發現攻擊, 只能說明你的系統監控太差了(連流量圖上都該出突尖了)

7. 有時效性
token不可以長期不變可用, 否則規則6將會在可預見的時間內失效

推薦不超過1個月(現在已經大都是1周). 具體可以參考各個站點的設計

如果需要長期保留可以採用換票(重新簽發新的token)的方式來延續自動登陸

8. 不可被攔截盜用*
假設當前網路為非安全信道, 消息可被監聽. 監聽者盜用token不能使用.或者監聽者無法盜用token(不能從網路包中分析出具體的token). 簡單說就是採用https協議可以快速透明的解決問題.

以下提供幾個簡化的版本, 建立在黑客沒有刻意針對服務進行攻擊的前提下, 做到基本的保護. 這樣盜用的門檻則提高到,加密代碼被獲取進而解密的門檻高度.

標準版:常用ip白名單

其中規則2的高級情況也可以起到一定程度的限制作用, 但無法抵禦對大型區域網路(公司網路, 學校網路, 小區網路)內的攻擊.

廉價版(https是要錢的): token擁有時間戳信息加密.即通信層面上的token是每次都在變化的

可達到屏蔽公共wifi這類實時全面截包進行攻擊的情況

極簡版:token每5min換票一次.

可達到非全面截包(區域網出現臨時的arp攻擊這類)情況下, token被發送到攻擊者郵箱後, 未來某一時刻被利用來攻擊的情況.

建議

規則1~4是最基本的, 完成不了的根本就不達標

對於尚未擁有可觀收益的服務, 只要完成1~6就夠了. 屬於及格狀態. 能攻擊的人不來攻擊, 這個服務就可以說是"絕對安全"了

反之則連規則8也得完成. 屬於良好狀態

最後提供終極規則9
社會工程學層面的安全防禦.(應對所有已知的即將知道的軟體/框架/協議漏洞 )

到達此級別的必須得是可以上市級別的公司(或者有實力巨額出售自己)提供的服務了. 當網路上出現高手通過特殊手段(比如最近的Heartbleed漏洞)直接獲取到token信息甚至是密碼時, 可以第一時間的得到白帽(烏雲/圈子裡)的幫助與支持.甚至是收買說服將要攻擊的黑客. 達到這個標準的才可以成為真正優秀的狀態.

PS.

再奉上一個究極規則10

推卸責任(應對出現撞庫攻擊的情況如最近的iCloud,Gmail)

當服務出現安全問題, 並已經產生嚴重後果/損失時. 找到公關部門,發布安全公告, 發表聲明, 嚴厲譴責漏洞利用者. 並一定要說明,同行現在差不多都是這個樣子,不會好只會更差.最好能說成是全世界的廠商都有這個問題. 可以的話說明一下人類的智慧暫時不能解決這個問題也是可以的. 順帶附上一個很小的數字, 說他們是受到影響的. 我們已經通知他們改密碼了. 至於損失的賠償么, 遊戲公司的運營可以考慮一下. 其他企業不建議給, 否則有認錯被抓把柄的風險.

當達到這個狀態時, 差不多可以說"Everything Is Under Control"了. 完美狀態.

說下在kohanframework auth moduel中的記住密碼思路吧。

通常記住密碼之後的作用就是用戶此次會話失效後，下次登錄網站用戶直接處於會話活動狀態，不必輸入用戶名密碼重新登錄，一個很好的用戶體驗但是處理不好也會存在用戶信息泄露的問題。

1、建一張表用來存儲md5(username+md5(user_agent))，這個值也就是存儲在客戶端cookie中的。

表結構

CREATE TABLE `j_user_tokens` (

`id` int(10) unsigned NOT NULL AUTO_INCREMENT,

`user_id` int(10) unsigned NOT NULL,

`user_agent` varchar(40) NOT NULL, --user_agent MD5值

`token` varchar(40) DEFAULT NULL, --md5(username+md5(user_agent))

`type` varchar(100) DEFAULT NULL,

`created` int(10) unsigned DEFAULT NULL,

`expires` int(10) unsigned NOT NULL, --過期時間，也就是記住密碼多久

PRIMARY KEY (`id`),

UNIQUE KEY `uniq_token` (`token`),

KEY `fk_user_id` (`user_id`)

) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8

2、用戶在某次選擇」記住密碼「登錄時，在登錄成功後將目前的信息作為一條新紀錄都寫入到j_user_tokens中，同時也要將token值寫入到cookie名為autologin中。

3、用戶關閉瀏覽器或此次session會話失效後；用戶再次訪問網站時，網站檢測獲取當前用戶對象時首先在session中找尋，其次會進入記住密碼機制查找；那麼伺服器獲取到autologin值以及user_agent的值在j_user_tokens中檢索匹配，如找到記錄則檢測是否已過期，過期則提示登錄，未過期則獲取user_id從而得到user對象，如未匹配到記錄則直接提示登錄。

這樣的處理好處就是，避免將用戶個人信息寫入到不安全的cookie中去，不必採用username+password進行驗證的方式。

說下discuz中的實現：將uid和密碼通過加密保存到cookie中（可逆）；

具體代碼discuz裡面找下（開源的）

php實現瀏覽器記住密碼功能 - CSDN博客