免登录的实现？

Question

可能是几个问题的组成。
1.单系统如何实现比较安全的免登录。
这个问题来源是，看到很多的系统，都有两周内免登录的选项，实际肯定是话了cookie，点击登录的时候，在登录界面，通过cookie还原登录表单的值，从而实现，直接点击登录就可以了，更有甚者，就是访问便默认实现登录，当然，肯定还是读取cookie的方式。

但是，看到很多都是在客户端保存了，登录表单的值，用户名，密码。这样是不是不安全？好的做法是什么？

2.第二个就是两个不同的系统间。
公司同一个产品，可以有不同的项目，不同的终端组成，假设帐号统一管理。那么，用户想进帐号中心，用什么方式可以在b,c,系统点击进行帐号中心的某个功能，就直接登录后进入呢？其实也就是免登录，因为他们可能在b,c里面都做过登录操作。

Answer 1

http://segmentfault.com/q/1010000000641642#a-1020000000641757
简单来说思路是cookie记住用户id和一个生成的凭证，当用户访问的时候查询服务器上时候两者统一，统一就直接登录了。

Answer 2

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

一

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

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

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

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

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

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

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

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

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

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

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

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

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

二

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

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

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

Answer 3

将cookie的过期时间设得长一些

Answer 4

关于第一个问题，客户端记住账号密码很显然是一种非常外行的表现 =_,=

如果只能用 cookie 的话，那么客户端也应该是记住 cookie 而不是记住账号密码

你提的第二个需求，我们一般叫做“单点登录”。

我刚刚 Google 了一下，找到篇文章，里面的图应该还算是比较形象：

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

Answer 5

针对第一点回答一下

一般来讲用户名和密码都不会存储在cookie里面，以session举例 是在cookie里面设置一个服务端唯一sid（一般叫做sessionid），在第二次登录的时候检查sid与remember me的存在，两者都存在，并且sid能够在服务器获得数据 则设置session 直接登录

Answer 6

第一个问题。
你的描述中包含两种方式。第一种是服务端直接读cookie验证用户信息，这个是传统的方式。第二种是用户打开登录页面时，里面的脚本从cookie中读取数据，然后进行登录操作。对于第一种来说，不要明文在cookie里保存用户名和密码就是安全的。比如discuz里面的authcode，你可以参考一下。但是第二种由于解密的算法在客户端，即使不能够读懂，也可以把js脚本复制下来复用，有一定危险性。

另外，保存表单是浏览器的事情，只能由用户打开或者关闭，应用是管不了的。