有如许一个场景——有个用户初访并登录了你的网站，但是第二天他又来了，却必需再次登录。因而就有了“记住我”如许的功能来便操纵户利用，但是有一件不言自明的工作，那就是这类认证状况的”空费光阴“早已超出了用户本来所需要的利用范围。这意味着，他们可以封锁浏览器，然后再封锁电脑，下周或下个月，乃至更久今后再回来，只要这距离时候不要太离谱，该网站总会知道谁是谁，并一如既往的为他们供给所有不异的功能和办事——与好久前他们分开的时辰别无二致。
我在谈论的就是这个“小家伙”：
看上往是不是是很巧很好用?那是当然，但你也将看到，即便利用恰当，它能激发的那一茶几悲剧也尽非偶尔，少说能有一车皮的人预备奉告你它是若何把工作弄糟的。那就让我们从标题问题标本源解缆吧。
反模式
这工作乍一看仿佛很较着，就是说“记住我”功能的利用其实是很是根基的，不是那种很玄乎的东西，可事实上呢?明显不是。
下面我会讲授两个反模式案例和标题问题标地点，和谈论若何做是准确的。第一个例子，如图所示，当你登录的时辰：
这一切都很是合适尺度，但有趣的工作产生在登录以后，让我们来看看cookies：
这个cookie相当的给力吧，特别是被选中的黄色高亮部门。假定你没勾选“记住我”的话，这些要命的信息是不会被cookie记实的，所以阿谁功能本来也只是纯真为了便操纵户再访的。在图中，我的邮箱地址是赤******的，但暗码并不是明文。但是不要兴奋得太早，对着那串仿佛坚不成摧的加密字符定睛一看……咦?等一下，这不是Base64编码吗!关于Base64编码，这是一种可以被完全解码的编码，这意味着你可以随便往哪个编码转换网站好比base64decode.org来做下面这件事：
其实不是所有人都把Base64当作“加密”(当然，有的人真会用它来加密首要信息)，虽然说它确切是一种合理代替ASCII的编制，但事实上这类编码的暗码仅仅在刚一进进浏览器后就会当即改变成明文。你可能会质疑道 - 这能有多大年夜标题问题?不管若何它只是存储在本身的浏览器里，它能如何?那到底黑客能不克不及获得它呢?
下面我会介绍两个很是简单的编制，起首说起的内容会和上面说的那种环境有关。Black&Decker透露了ELMAH日记，在这些日记中存在着完全未经建设的内部办事器弊端，而被解除的内容是被记实的内容的几万倍。可是当ELMAH记实了一个异常，在履行措置之前系统也会记实所有的要求头，这意味着这些内容全都进进了cookies。试想那数量复杂年夜的被过滤掉落的内容其实全被转存了起来，这的确就便是有了一个用户根据的数据库。当然他们应当已修补了这个标题问题，但它是一个很好的例子，若何垂手可得的操纵一个很是简单的建设掉误。
接下来是另外一个标题问题：
这个网站是Aussie Farmers Direct(以下统称为AFD网)，是一个相当典型的表单登岸。那就登录看看，并且让网站“记住我”，接着就来看cookies吧：
好家伙，仍是一样的状况，乃至连Base64编码都没加。要说这一点有多糟，来看你可以做这个：
XSS本身的JSON cookie?当然可以这么玩，如许一来，假定你的暗码改了但cookie还不变，等你再次登录的时辰，它就试图用旧暗码登录。嗯?
AFD网并没有透露他们的ELMAH日记(PHP好样的!)但他们还有其他风险，如XSS。有关上述网站的另外一件事是，这些存储在Cookie中的暗码并没有被标识表记标帜成HttpOnly，你可以在右边的cookie列表中看到。这意味着，客户端脚本可以拜候这些cookies，这就便是是只要你能让XSS成功，便可以经由过程让其他用户加载XSS payload，盗取包含暗码的cookie，(如许做的有效编制良多)。贫乏了HttpOnly属性或许是一时草率，但标题问题标核心在于存储在cookie中的暗码会很等闲地经由过程其他路子疏漏出往。
还有一个更底子的启事，为甚么这些网站会同时在这点上忽视大年夜意，虽然他们都在呵护本身客户在其网站上利用的根据。每当上述网站的客户勾选了“记住我”功能并向网站上发出要求时，当他们的用户名和暗码被网站发送到他们的邮箱时，当他们把持eBay或网银时。要么暗码是明文，要么可以经由过程客户端脚本获得，总之暗码总会一丝不挂的躺在浏览器里。大年夜量的人有暗码复用(通用)的习惯 ，但是为那些酷爱作死的用户承担责任的，倒是我们开辟者。我不克不及不说，当我们应对那些用户根据威胁的时辰，需要实施的呵护办法要远远超越网站本身。
是以，应当意想到对若何成立“记住我”功能上的真正曲解，下面我们再来看看良性实践。
样本基于实操
实例
在安然界混，有句话你应当会很熟谙，“不消你本身试 - 就用阿谁公认最给力的就行”。这类话在加密和认证打算中很是等闲听到，亦可利用在本文课题，借鉴过来深进研究细节。
在一个用Visual Studio 2012扶植的ASP.NET MVC 4网站中，你会看到这个：
其他框架有其他的尺度模式来实现此功能，但这个更等闲作为参考。当我们经由过程提交上面的表单进行登录时，并且不要求“记住我”，以下的cookie被成功验证，成果返回：
Set-Cookie:.ASPXAUTH=6891A5EAF17A9C35B51C4ED3C473FBA29418
7C97B758880F9A56E3D335E2F020B86A85E1D0074BDAB2E1C9DBE590A
F67895C0F989BA137E292035A3093A702DEC9D0D8089E1D007089F75
77D1B2A79CAA800E8F62D3D807CBB86779DB52F012; path=/; HttpOnly
这是一个简单的身份验证cookie，并***了所有HTTP的数据。这类我专属的cookie被发送后，网站就每次都能知道这是我并且我已被验证了。我们还能看得更清晰，好比当我们用Chrome’s Cookies collection的时辰：
别的，第二个cookie是一个防伪标识表记标帜，以避免CSRF报复打击，并且与我们的认证状况无关。除此以外，有没有其他的cookie。
此刻，让我们勾选上“记住我”然后再次登录看看cookie的响应：
Set-Cookie:.ASPXAUTH=3A92DAC7EFF4EE5B2027A13DD8ABEA8254
F0A16D8059FCAF60F5533F1B7D99462DDF57320D069A49348197875
0526DF952D5C9EA0371C84F5CF1BFC0CCA024C2052824D4BA09670A
42B85AEC7FFCB4088FC744C6C0A22749F07AF6E65E674A4A;
expires=Tue, 02-Jul-2013 00:27:05 GMT; path=/; HttpOnly
来了你看到没?来用Chrome解剖一下看看：
我们此刻有了一个有效期为48小时的cookie，假定当它过了刻日，它在浏览器封锁时，将被丢弃。让我们来细心看看。
寻觅身份验证Cookie的时限部门
其实，这是一个简单得略显荒诞的安然机关，我都乃至觉得它没有写出来的价值，来看一下这里：在这个例子中，“记住我”功能可以简单地回结为，它节制了cookie的时限并且决定某小我可以或许延续登录多久。
在上面的例子中，ASP.NET默许利用一个会话cookie，或换句话说，一个cookie，并且没有一个明白的截止日期，是以将在浏览器封锁时强行过时。这是一种编制，另外一种是直接置进短保质期，即便浏览器继续利用该cookie，用户也将被主动刊出。当然，你也能够在办事器上节制这类行动，你也可让身份验证cookie的时限不竭耽误，假定系统正在积极利用由办事器响应增加的时限。
只要保持这个验证cookie有效，特定的人就会被记住。那多久的时效才合适呢?上面的例子中默觉得2天，但这对合法的利用者明显有些太短。而Facebook的cookie却能延续一年。延续时候较短，意味着更少的风险，但更多的不便，延续时候较长，使得它更等闲为用户增加暗藏的风险。让我们更进一步的看看这个风险。
持久认证状况的操纵
当在被认证之前，你的会话没法被劫持。废话，这是当然的!但当真看的话，像在上面AFD网的那种环境下，该cookie将在6个月后到期，与此同时它没有HTTP only的标识表记标帜，如许一来他们网站的XSS缝隙可觉得报复打击者供给半年的时候往获得并利用用户的凭证。一样的环境，假定时限为1个月，他们仍会有一些严重的缝隙，但上述报复打击的机缘实其实在地获得了削减。
另外一方面，Black&Decker网有一个相对短的——一周的刻日。在他们透露着ELMAH日记的环境下，仍然有一系列的重大年夜疏漏，但除非有人在一周前已用“记住我”登录了网站，并且触发了阿谁默许建设的缝隙，不然根据不会被泄漏。假定你想找个网站本身尝尝看的话，就算是一个你已登录过的网站，也能够看到存在时限风险的cookie。
所以说一切有关身份验证的cookie假定想要呵护好用户根据的话，HttpOnly的安然属性是和严谨的安然立场必需的。当然所有经典的劫持威胁仍然存在，不外，解决这些cookie上的标题问题也是尽不容忽视的。
回根结底，这是一个衡量，需要考虑的身分如报复打击者要获得的数据的价值，在加强验证安然性时对用户利用的便捷性和网站安然建设所酿成的负面影响。例如，Facebook中存在着一些很是有效的社会性的用户数据，而用户又很是希看无延时般的响应速度，在此之上他们还对本身的账户安然长进行了大年夜笔的投资。而对AFD网，在持有效户小我身份数据和财务信息的同时，供给了用户所要求的安然验证办事，能看出用户本身也是有相干安然意识的。他们有着迥然不合的风险，这两个网站对身份验证cookie的时限策略应当是完全不合的。
强化
或许有些同窗会感觉AUTH cookie很无解，有关安然性的东西总会有一种更好的解决方案，但这是有代价的，安然性取决于你愿意支出的的时候、金钱、便当性，并且也总会有人奉告你，你做错了!让我们来看看关于利用AUTH cookie时限的一些可能的加强编制。
对一个持久有效的AUTH cookie，标题问题在于他们需要有效地保持用户身份的验证和面对如CSRF或clickjacking等报复打击风险。当然，还有良多需要操纵持久cookie的风险并没有列出，但这其实不影响环绕防备编制的会商。还有一点就是当一个专用cookie为用户在办事器上供给过有效认证以后，在返回时它还可以从头开启另外一个认证会话。当然最初的会话会敏捷到期，但关头是重启的新会话，它会因为用户勾选了“记住我”并再次登录而进行别的的验证。
一种验证编制包含操纵用户的IP地址/用户代办署理/其他较着特点来限制“记住我”的cookie。这能供给一些对cookie劫持的防御。当然，要在合法利用的环境下进行这些变动。出格是在移动收集中这类的环境其实良多见——用不合的IP回访一个网站。你的ISP不必然总会供给静态的IP地址。至于用户代办署理，还有浏览器差别，如Chrome和Firefox的更新的确仿佛隔日。但是除非你决心往遴选某些优良的代办署理，不然利用代办署理将是一个危险的做法。
还有一种法度化的手段，就是保持“记住我”cookie和身份验证cookie的分手，并利用前者从头验证用户的身份，但要额外施加一些限制。实际环境是，某个身份的主动认证状况的过程，必然会遵守安然模型。和缓办法的成果就是，它会在主动从头验证之前，向用户再次索要根据。这并不是立异之举，你或许会在进行例如网银汇款时碰着过此类功能。在这里，我们说身份验证的用户面对的风险很大年夜，因为这类编制很等闲被劫持和棍骗。
至于其他加强编制，我们可以在“记住我”cookie被利用掉队行复位。这也便是让它在办事器端无效，而需要一个奇特且持久的cookie值，例如存在于数据库和cookie间的一个随机数。如许有益于确保cookie不会被报复打击者用下面的编制获得。在这里的文章中，作者谈论了一些关于这类模式的减缓编制。但你需要支出一些额外的工作，并在某种程度上给正常的用户带来不便(例如用户没法超越多个电脑利用并“记住”本身的根据)。
最后一件值得提一句的是，统一帐户下的治理原则，它需要我们往存眷并且和“记住我”功能有关。例如，承诺单一用户的多个会话同时验证?或用户一旦更改了暗码要不要将会话断开?治理员可不成以结束验证会话?呈现了各类各样的标题问题，不外这里要会商的仅仅是关于若何答复复兴。
甚么时辰不该用“记住我”功能?(和一些替代功能)
有时辰，承诺一个颠末认证的用户保持认证状况很长一段时候是毫无意义的。例如银行，在常规的利用环境下，当你想图省事非要进行主动登录时，在你走人今后留在那边的是一个未登出的浏览器，风险多大年夜不消我说了吧。
但其实仍是有一些中间地带可以采纳下面这类做法：
这个登岸框其实不是看上往的那么弱，当你用“记住我”登录过后，再次回访的时辰，网站的会话就过时了，你会看到：
用户名这个模样可不是我起的，是因为它连同其他一些数据在cookie中存了三个月。率直地说，这么做没成心义，因为记住用户名不难啊!
可是，这类环境既不克不及全否也不克不及全数必定，这是个灰色的中间地带。例如，假定在经由过程“记住我”功能恢复会话时，从头认证是在主过程之前启动的。这或许是一个分身齐美的做法。
总结
这个也不例外，总会有些功能看上往仿佛是一个好主张，并且它凡是是很等闲做好的，起码可以合适大年夜大都的项目。坦白来讲，前面两个例子仍然莫名其妙的让人头疼，出格是当你考虑到它本来只是用于耽误cookie时限的。
别的，这篇文章的重点其实不局限于分化“记住我”功能的安然布局，你可能可以或许自行解决本身的cookie根据标题问题，但连络起ELMAH和贫乏HTTP only属性和XSS缝隙的环境考虑，时刻警戒一个不经意的行动，(行动)当然看似无害但却很可能造成一个严重的安然风险。