一、“記住我”的功能不安全的地方

登錄之后，讓我們來看看cookies

如果你沒勾選“記住我”的話，這些要命的信息是不會被cookie記錄的，所以那個功能原本也只是單純為了方便用戶再訪的。在圖中，我的郵箱地址是赤裸裸的，但密碼并非明文。然而不要高興得太早，對著那串似乎堅不可摧的加密字符定睛一看……咦？等一下，這不是Base64編碼嗎！關于Base64編碼，這是一種可以被完整解碼的編碼，這意味著你可以隨便去哪個編碼轉換網站比如base64。

并不是所有人都把Base64當做“加密”，雖說它確實是一種合理代替ASCII的方法，但事實上這種編碼的密碼僅僅在剛一進入瀏覽器后就會立即轉變為明文。你可能會質疑道 - 這能有多大問題？無論如何它只是存儲在自己的瀏覽器里，它能怎樣？那到底黑客能不能得到它呢？

這些存儲在Cookie中的密碼并沒有被標記成HttpOnly，你可以在右邊的cookie列表中看到。這意味著，客戶端腳本可以訪問這些cookies。缺少了HttpOnly屬性或許是一時馬虎，但問題的核心在于存儲在cookie中的密碼會很容易地通過其他途徑疏漏出去。

還有一個更根本的原因，為什么這些網站會同時在這點上疏忽大意，盡管他們都在保護自己客戶在其網站上使用的憑據。每當上述網站的客戶勾選了“記住我”功能并向網站上發出請求時，當他們的用戶名和密碼被網站發送到他們的郵箱時，當他們操作eBay或網銀時。要么密碼是明文，要么可以通過客戶端腳本獲取，總之密碼總會一絲不掛的躺在瀏覽器里。大量的人有密碼復用（通用）的習慣 。我不得不說，當我們應對那些用戶憑據威脅的時候，需要實施的保護措施要遠遠超過網站本身。

二、如何安全實現“記住我”的功能

1、尋找身份驗證Cookie的時限部分

“記住我”功能可以簡單地歸結為，它控制了cookie的時限并且決定某個人能夠持續登錄多久。

asp.net默認使用一個會話cookie，或者換句話說，一個cookie，而且沒有一個明確的截止日期，因此將在瀏覽器關閉時強行過期。這是一種方法，另一種是直接置入短保質期，即使瀏覽器繼續使用該cookie，用戶也將被自動注銷。當然，你也可以在服務器上控制這種行為，你也可以讓身份驗證cookie的時限不斷延長，如果系統正在積極使用由服務器響應增加的時限。

只要保持這個驗證cookie有效，特定的人就會被記住。那多久的時效才合適呢？上面的例子中默認為2天，但這對于合法的使用者顯然有些過短。持續時間較短，意味著更少的風險，但更多的不便，持續時間較長，使得它更容易為用戶增加潛在的風險。讓我們更進一步的看看這個風險。

2、長期認證狀態的利用

當在被認證之前，你的會話無法被劫持。例如有的網站的cookie將在6個月后到期，與此同時它沒有HTTP only的標記，這樣一來他們網站的XSS漏洞可以為攻擊者提供半年的時間去獲取并使用用戶的憑證。同樣的情況，如果時限為1個月，他們仍會有一些嚴重的漏洞，但上述攻擊的機會實實在在地得到了削減。

另一方面，在他們暴露著ELMAH日志的情況下，依然有一系列的重大疏漏，但除非有人在一周前已經用“記住我”登錄了網站，并且觸發了那個默認配置的漏洞，否則憑據不會被泄露。如果你想找個網站自己試試看的話，就算是一個你已經登錄過的網站，也可以看到存在時限風險的cookie。

所以說一切有關身份驗證的cookie如果想要保護好用戶憑據的話，HttpOnly的安全屬性是和嚴謹的安全態度必須的。雖然所有經典的劫持威脅仍然存在，不過，解決這些cookie上的問題也是絕不容忽視的。

歸根結底，這是一個權衡，需要考慮的因素如攻擊者要取得的數據的價值，在加強驗證安全性時對于用戶使用的便捷性和網站安全配置所造成的負面影響。例如，Facebook中存在著一些非常有用的社會性的用戶數據，而用戶又非常希望無延時般的響應速度，在此之上他們還對自己的賬戶安全上進行了大筆的投資。而對于AFD網，在持有用戶個人身份數據以及財務信息的同時，提供了用戶所要求的安全驗證服務，能看出用戶本身也是有相關安全意識的。他們有著迥然不同的風險，這兩個網站對于身份驗證cookie的時限策略應該是完全不同的。

3、強化

或許會覺得AUTH cookie很無解，有關安全性的東西總會有一種更好的解決方案，但這是有代價的，安全性取決于你愿意付出的的時間、金錢、便利性，而且也總會有人告訴你，你做錯了！讓我們來看看關于使用AUTH cookie時限的一些可能的加強方法。

對于一個長期有效的AUTH cookie，問題在于他們需要有效地保持用戶身份的驗證和面對如CSRF或clickjacking等攻擊風險。當然，還有很多需要利用長期cookie的風險并沒有列出，但這并不影響圍繞防范方法的討論。還有一點就是當一個專用cookie為用戶在服務器上提供過有效認證之后，在返回時它還可以重新開啟另一個認證會話。雖然最初的會話會迅速到期，但關鍵是重啟的新會話，它會因為用戶勾選了“記住我”并再次登錄而進行另外的驗證。

一種驗證方式包括利用用戶的IP地址/用戶代理/其他顯著特點來限制“記住我”的cookie。這能提供一些對cookie劫持的防御。當然，要在合法使用的情況下進行這些變更。特別是在移動網絡中這類的情況并不少見——用不同的IP回訪一個網站。你的ISP不一定總會提供靜態的IP地址。至于用戶代理，還有瀏覽器差異，如Chrome和Firefox的更新簡直恍如隔日。然而除非你刻意去挑選某些優質的代理，否則使用代理將是一個危險的做法。

還有一種程序化的手段，就是保持“記住我”cookie和身份驗證cookie的分離，并使用前者重新驗證用戶的身份，但要額外施加一些限制。實際情況是，某個身份的自動認證狀態的過程，一定會遵循安全模型。緩和措施的結果就是，它會在自動重新驗證之前，向用戶再次索要憑據。這并非創新之舉，你或許會在進行例如網銀匯款時遇到過此類功能。在這里，我們說身份驗證的用戶面臨的風險很大，因為這種方式很容易被劫持和欺騙。

至于其他加強方法，我們可以在“記住我”cookie被使用后進行復位。這也等于讓它在服務器端無效，而需要一個獨特且持久的cookie值，例如存在于數據庫和cookie間的一個隨機數。這樣有利于確保cookie不會被攻擊者用下面的方式獲得。在這里的文章中，作者談論了一些關于這類模式的緩解方法。但你需要付出一些額外的工作，并在某種程度上給正常的用戶帶來不便（例如用戶無法跨越多個電腦使用并“記住”自己的憑據）。

最后一件值得提一句的是，同一帳戶下的管理原則，它需要我們去關注并且和“記住我”功能有關。例如，允許單一用戶的多個會話同時驗證？或者用戶一旦更改了密碼要不要將會話斷開？管理員可不可以結束驗證會話？出現了各種各樣的問題，不過這里要討論的僅僅是關于如何復原。

三、什么時候不該用“記住我”功能？（以及一些替代功能）

有時候，允許一個經過認證的用戶保持認證狀態很長一段時間是毫無意義的。例如銀行，在常規的使用情況下，當你想圖省事非要進行自動登錄時，在你走人以后留在那里的是一個未登出的瀏覽器，風險多大不用我說了吧。