正确的登录过程

时间:2011-03-05 17:48:45

标签: session cookies login sha1

我之前没有必要解决登录过程,所以这对我来说是一个新的领域,而我似乎在谷歌上发现的所有这些都是处理这个过程的相互矛盾的方法,所以我希望有人可以帮助澄清。

到目前为止,我有一个盐水SHA1哈希混合用户名,密码和我的盐变量。 当用户登录他们的凭据得到哈希,然后这个哈希被发送到sql,如果找到回来的用户ID(或其他东西)。所以我知道他们已经过身份验证。 有了这个,我可以使用会话变量来处理它们的会话。

到目前为止这是对的吗?

无论如何,我想要选择“记住我”并且正在考虑将某些内容存储在cookie中,但我不知道该放在哪里,因为我知道存储哈希会很漂亮与他们的用户名和放置相同密码以纯文本格式。

我很困惑,有人可以解释一下吗?

提前致谢

5 个答案:

答案 0 :(得分:2)

您通常最好使用平台提供的身份验证方法而不是自己创建身份验证方法。有许多非显而易见的问题,你可以很容易地让自己开放。你在哪个平台上使用?您使用的是Web框架吗?

像SHA1这样的通用哈希值不适合密码哈希,因为当你想要一些非常慢的东西时,它们被优化得非常快。有关此问题的讨论,请参阅How To Safely Store A Password

  

无论如何,我想要选择“记住我”并且正在考虑将某些内容存储在cookie中,但我不知道该放在哪里,因为我知道存储哈希会很漂亮与他们的用户名和放置相同密码以纯文本形式出现。

哈希被设计为单向函数,所以不,它与将其用户名和密码放在纯文本中不同。但是,如果你这样做,你将不得不创建一种方法让某人使用哈希而不是用户名和密码进行身份验证,并且 与将其用户名和密码存储在客户(就你而言,无论如何)。

答案 1 :(得分:1)

我喜欢你已经使用salt进行哈希的事实,但我认为没有必要使用用户名进行散列,只有密码+盐就足够了。特别是,如果您希望为系统选择可更改的用户名,则会造成重新散列的开销。

为了记住我的选项,我认为您不应该在客户端cookie存储任何凭据。只有会话ID就足够了。如果您想使其真正安全,您应该使用服务器发布的客户端证书。

http://it.toolbox.com/blogs/securitymonkey/howto-securing-a-website-with-client-ssl-certificates-11500

答案 2 :(得分:1)

您的首次登录过程是正确的,符合当今的安全标准,唯一的例外是您可能希望在sha1上选择另一个散列函数。

Sha1非常快,因此破解哈希的暴力攻击更快。因此,如果您的哈希(数据库)和令牌(源代码)泄露,密码可能会被破解。 一个对策是使用较慢的散列函数(参见Jims回答有关该文章的文章)

但最好的当然不是第一次泄漏你的哈希。

记住我功能的一种可能性是让用户将会话cookie保持更长时间。例如,Magento和Zend Auth就是这样做的。

然而,这非常难看,因为您可能会收到存储在服务器上的数千个会话的内容,即使对于那些永不返回的用户也是如此。

更优雅的方式是存储此信息客户端。

旁注:当然,您不应该在客户端上放置太多cookie,因为它们会随着每个页面请求一起传输。但登录cookie是一个非常有效的案例。一个好的做法是在客户端存储登录cookie,并使用在会话中标记的登录时保存在数据库中的数据填充服务器会话。这样,您可以消除连续的数据库请求并拥有良好的用户数据注册表。当然必须直接或者更好地对数据库和数据库进行写入,然后以某种方式刷新到应用程序(完全或递增)。

将哈希放在客​​户端cookie中并不像“明文”。然而,它在许多层面上都是丑陋,可怕和不安全的。

有一些不同的方法,但它们主要涉及一些哈希。

最常见也很简单的就是在客户端上放置一个user_id=johnuser_token=HASH($userid.$appsecret)的Cookie。或者将它们存储为一个一个cookie。

这有点安全,但我更喜欢以下方法:

生成一个包含以下内容的字符串:

userid ; user agent ; first two ip segments ; current timestamp ; your application secret token 

通过良好的散列函数运行它并将cookie存储在用户客户端,看起来像

auth=userid;timestamp;hash-of-the-above

当客户端通过cookie登录时,您从上面重新构造taht字符串,但从cookie中获取时间戳和用户ID。生成哈希并查看它是否匹配。然后,您已验证它是您在指定时间为该IP地址段和此用户代理生成的cookie

旁注:前两个ip段很少用动态isp改变。你也可以把它们留下来,这是为了更加安全。

这种方法的主要优点是什么?

客户端或您可以通过设置时间戳使所有登录cookie无效。只接受之后生成的烹饪。您还可以实现超时。

如果您希望从忘记退出的公共计算机“远程注销”或其他内容,这是很好的。

我认为功能非常重要,使用这种方法你不必跟踪单个登录cookie(比如google)。

希望这会对你有所帮助。

您可以将此方法扩展到您喜欢的任何安全级别,并根据您的需要进行调整。

答案 3 :(得分:0)

您的身份验证很好。如果您想让它更安全,您可以使用SSL加密连接传输登录信息,这样任何人都无法读取网络上的内容。

记忆令牌非常简单,假设你想要一个有效期为14天的记忆功能。

没有经过身份验证的会话的陌生人来到您的网站:

  1. 检查Cookie中是否有记住我的令牌
  2. 如果是,请检查您是否可以在数据库中找到此记住我的令牌并检查“有效直至”列是否仍然有效(日期比较)
  3. 如果找到有效的令牌,则可以设置用户ID并验证其会话
  4. 如果您没有找到有效的令牌,则必要时将用户重定向到登录页面
  5. 当用户填写登录表单并成功验证他时:

    使用适当的散列函数生成令牌。您散列的令牌可能看起来像“[Timestamp] --- [userpwd]”所以它(几乎)绝对是唯一的!保存令牌和日期,直到令牌有效(从现在起+14天为例)到与用户ID相关联的数据库。如果有过期的令牌,请替换它,因为您不需要存储过期的令牌。

    如果用户通过单击注销按钮或类似按钮注销,只需删除数据库中的令牌记录和用户的cookie。

    就是这样!

答案 4 :(得分:0)

如果您的平台(网络服务器等)支持HTTP digest authentication,我强烈建议您使用它。它是由比我们任何一个人都更了解安全性的人设计的。它不通过网络发送密码。所有现代Web浏览器都支持它,包括移动设备。如果浏览器存储了密码,它会在连接期间透明地发生,为您提供“记住我”功能,而无需去任何靠近cookie的地方。

它唯一不做的就是让你使用一个漂亮的表单 - 用户将从他们的浏览器中获取一个对话框来登录。