免登入的實現?

來源:互聯網
上載者:User
可能是幾個問題的組成。
1.單系統如何?比較安全的免登入。
這個問題來源是,看到很多的系統,都有兩周內免登入的選項,實際肯定是話了cookie,點擊登入的時候,在登入介面,通過cookie還原登入表單的值,從而實現,直接點擊登入就可以了,更有甚者,就是訪問便預設實現登入,當然,肯定還是讀取cookie的方式。

但是,看到很多都是在用戶端儲存了,登入表單的值,使用者名稱,密碼。這樣是不是不安全?好的做法是什嗎?

2.第二個就是兩個不同的系統間。
公司同一個產品,可以有不同的項目,不同的終端組成,假設帳號統一管理。那麼,使用者想進帳號中心,用什麼方式可以在b,c,系統點擊進行帳號中心的某個功能,就直接登入後進入呢?其實也就是免登入,因為他們可能在b,c裡面都做過登入操作。

回複內容:

可能是幾個問題的組成。
1.單系統如何?比較安全的免登入。
這個問題來源是,看到很多的系統,都有兩周內免登入的選項,實際肯定是話了cookie,點擊登入的時候,在登入介面,通過cookie還原登入表單的值,從而實現,直接點擊登入就可以了,更有甚者,就是訪問便預設實現登入,當然,肯定還是讀取cookie的方式。

但是,看到很多都是在用戶端儲存了,登入表單的值,使用者名稱,密碼。這樣是不是不安全?好的做法是什嗎?

2.第二個就是兩個不同的系統間。
公司同一個產品,可以有不同的項目,不同的終端組成,假設帳號統一管理。那麼,使用者想進帳號中心,用什麼方式可以在b,c,系統點擊進行帳號中心的某個功能,就直接登入後進入呢?其實也就是免登入,因為他們可能在b,c裡面都做過登入操作。

http://segmentfault.com/q/1010000000641642#a-1020000000641757
簡單來說思路是cookie記住使用者id和一個產生的憑證,當使用者訪問的時候查詢服務器上時候兩者統一,統一就直接登入了。

一切免登錄的核心都是在客戶端儲存登錄憑據。

由於 TCP 協議面向連接而非會話,想保持會話必須使用額外的功能,在服務器端與客戶端儲存憑據。

最簡單的思想是用 cookies 儲存用戶名和密碼,服務器每次連接進行用數據庫中的原始內容比對驗證。

然而由於 cookies 中的內容明文傳遞,且可能從瀏覽器、檔案系統泄漏。所以有人想到了將用戶名密碼加密的方案。

a. 儲存密鑰加密的用戶名密碼,傳到服務器端解密驗證。
b. 儲存雜湊演算法得到散列值,傳到服務器與原始數據的雜湊結果比對。

以上兩種方案實質上都只是將登錄憑據從用戶名密碼變爲從用戶名密碼導出的數據,而對登錄憑據的保護並沒有增加,cookies 中的內容泄漏依舊可被用於任意登錄。

僅僅加密憑據只會使得憑據變爲加密後的結果。

必須在此基礎上增加難以僞造或複製的憑據。

UserAgent、IP Address 等都是常見的輔助登錄憑據。

將輔助登錄憑據與用戶名密碼一起加密/雜湊可彌補上述方案的缺點,且服務器端不用爲特定會話儲存額外數據。

然即便如此,假若此憑據被盜用依舊如密碼被盜般永久,如設備被盜,所以服務器端必須具備銷毀登錄憑據的能力。

方案:在登錄憑據中增加一項僞隨機數,儲存於服務器端,如此只需更改服務器端儲存的結果即可銷毀原有的登錄憑據。

此方案還可實現重新登錄則原有會話失效。

若需登錄狀態指定時間後超時,只需在憑據中增加首次登錄時間項。

有一個完善的登錄憑據管理機制則其它一切均輕而易舉。

好比 google.com 和 gmail,共用 cookies;google.com 和 youtube.com,使用跳轉、架構、img、腳本等方式將憑據傳遞過去,並儲存 cookies 即可。

總之,一切免登錄的核心都是在客戶端儲存登錄憑據。

將cookie的到期時間設得長一些

關於第一個問題,用戶端記住帳號密碼很顯然是一種非常外行的表現 =_,=

如果只能用 cookie 的話,那麼用戶端也應該是記住 cookie 而不是記住帳號密碼

你提的第二個需求,我們一般叫做“單點登入”。

我剛剛 Google 了一下,找到篇文章,裡面的圖應該還算是比較形象:

http://www.cnblogs.com/yupeng/archive/2012/05/24/2517317.html

針對第一點回答一下

一般來講使用者名稱和密碼都不會儲存在cookie裡面,以session舉例 是在cookie裡面設定一個服務端唯一sid(一般叫做sessionid),在第二次登入的時候檢查sid與remember me的存在,兩者都存在,並且sid能夠在伺服器獲得資料 則設定session 直接登入

第一個問題。
你的描述中包含兩種方式。第一種是服務端直接讀cookie驗證使用者資訊,這個是傳統的方式。第二種是使用者開啟登入頁面時,裡面的指令碼從cookie中讀取資料,然後進行登入操作。對於第一種來說,不要明文在cookie裡儲存使用者名稱和密碼就是安全的。比如discuz裡面的authcode,你可以參考一下。但是第二種由於解密的演算法在用戶端,即使不能夠讀懂,也可以把js指令碼複製下來複用,有一定危險性。

另外,儲存表單是瀏覽器的事情,只能由使用者開啟或者關閉,應用是管不了的。

  • 聯繫我們

    該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

    如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

    A Free Trial That Lets You Build Big!

    Start building with 50+ products and up to 12 months usage for Elastic Compute Service

    • Sales Support

      1 on 1 presale consultation

    • After-Sales Support

      24/7 Technical Support 6 Free Tickets per Quarter Faster Response

    • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.