【问题标题】:Simple token-like authentication简单的类似令牌的身份验证
【发布时间】:2015-06-16 03:18:57
【问题描述】:

以下身份验证系统是否合理:

  1. 客户端使用用户名和密码向主服务器调用登录端点。主服务器将其发送到另一个身份验证服务器(不会收到进一步提及),如果这是有效的,它将返回是/否以及主服务器知道的用户 ID。如果是,则生成一个随机令牌(使用一些会吐出随机字符串的加密库),并存储其哈希值(使用 PHP 的 password_hash()),并在用户记录上保存 12 小时后的有效期。将令牌返回给客户端。

  2. 客户端现在将“授权:令牌 TOKEN+HERE+ABCD1234”添加到他们对其他端点的请求中。服务器确保 auth 标头中令牌的哈希值与数据库中的哈希值匹配(通过 PHP 的 password_verify() 使用盐),并且没有达到过期时间。如果不匹配,或者过期,则发回 401。

似乎至少与基本 HTTP 身份验证一样安全,后者只是在标头中包含 base-64 编码的 user:password?我考虑这个方案而不是基本的原因是主服务器不会存储身份验证服务器用于登录的用户名/密码。

我忘记了什么?这是非常不安全的吗?

【问题讨论】:

    标签: php authentication token


    【解决方案1】:

    您的方案与标准服务器端会话没有太大区别,其中 SESSION-ID 通常只是一个随机令牌并存储在客户端的 cookie 中,有 2 个改进:

    • 您可以使用授权标头来传递令牌,而不是 cookie。这起到了 CSRF 保护的作用。
    • 您将在服务器端散列一个令牌。这有助于防止会话劫持,以防有人在服务器端访问您的令牌存储。

    【讨论】:

    • 现在查看会话 ID。那么,您的回答似乎表明这是一个合理的解决方案?
    • 如果实施正确 - 我认为没有问题。但是,请注意,“加密安全的随机数生成器”并不是真正的“一些会产生随机字符串的加密库”。
    • 哈哈注意到了。文档似乎表明它是加密安全的,但我会确保。干杯!
    【解决方案2】:

    如果您看到 Google 的 oAuth 流程,您就会了解授权如何为他们工作。

    他们有不同的服务器用于授权和 API 调用。用户将身份验证详细信息发送到授权服务器并接收代码。 Google 正在征得用户同意以访问详细信息,但您可以跳过此过程以征得同意,并在成功的详细信息上返回代码。

    此代码可进一步用于从 API 服务器获取访问令牌。因此,您对 API 服务器的第一个请求是获取访问令牌。 Google 也可以刷新您的访问令牌。

    并且所有后续对 API 服务器的请求都必须包含 Access Token。因此,您似乎缺少此代码交换过程以使其更安全。

    更多信息:https://developers.google.com/identity/protocols/OAuth2

    【讨论】:

    • @Luke,它会添加两步验证。
    猜你喜欢
    • 1970-01-01
    • 2021-02-24
    • 2014-02-25
    • 2018-08-27
    • 1970-01-01
    • 2022-06-27
    • 1970-01-01
    • 2017-06-13
    • 1970-01-01
    相关资源
    最近更新 更多