Fatal编程技术网

Language agnostic 解密Web身份验证

language-agnostic authentication cookies passwords security

Language agnostic 解密Web身份验证,language-agnostic,authentication,cookies,passwords,security,Language Agnostic,Authentication,Cookies,Passwords,Security,我目前正在为我正在开发的网站研究用户身份验证协议。我想创建一个身份验证cookie，以便用户可以在页面之间保持登录状态 这是我的第一次狂欢： cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k) 其中k是HMAC（用户id |到期日，sk），sk是仅服务器知道的256位密钥。HMAC是一个SHA-256散列。请注意，“|”是分隔符，而不仅仅是串联 这在PHP中是这样的： $key = hash_hmac('sha256', $use

我目前正在为我正在开发的网站研究用户身份验证协议。我想创建一个身份验证cookie，以便用户可以在页面之间保持登录状态

这是我的第一次狂欢：

cookie = user_id|expiry_date|HMAC(user_id|expiry_date, k)
其中k是
HMAC（用户id |到期日，sk）
，sk是仅服务器知道的256位密钥。HMAC是一个SHA-256散列。请注意，“|”是分隔符，而不仅仅是串联

这在PHP中是这样的：

$key = hash_hmac('sha256', $user_id . '|' . $expiry_time, SECRET_KEY);
$digest = hash_hmac('sha256', $user_id . '|' . $expiry_time, $key);
$cookie = $user_id . '|' . $expiry_time . '|' . $digest;
我可以看出，它很容易受到安全Cookie协议中所述的重播攻击，但应该能够抵抗卷攻击和加密拼接

问题是：我是站在正确的路线上，还是我错过了一个巨大的漏洞？有没有一种方法可以抵御使用动态分配的IP地址而不使用会话的重播攻击

注释

我读过的最新材料：
Web上客户端身份验证的应做事项和不应做事项 aka Fu等人。
（）

安全Cookie协议 aka Liu等人。
（）
它扩展了前面的方法

强化无状态会话cookie
（）
这也扩展了前面的方法

由于主题极其复杂，我只想从在创建和破坏身份验证方案方面具有实际经验的安全专家那里寻找答案。

一般来说，这很好，我在多个应用程序中也做过类似的事情。它不比会话ID更容易受到重播攻击。您可以使用SSL保护令牌不被泄漏，以便重播，这与会话ID相同

次要建议：

  • 在用户数据中放置一个字段，该字段在更改密码时更新（可能是密码生成计数器，甚至只是随机salt），并将该字段包含在令牌和签名部分中。然后，当用户更改密码时，他们也会使任何其他被盗代币失效。如果没有这一点，您将受限于您可以合理地允许代币在到期前存活的时间

  • 在令牌和签名部分中放置一个方案标识符，以便（a）您可以为不同的目的使用不同类型的令牌（例如一个用于auth，一个用于XSRF保护），以及（b）您可以使用新版本更新机制，而不必使所有旧令牌失效

  • 确保从不重复使用
    user\u id
    ，以防止令牌被用于访问具有相同id的不同资源

  • 管道定界假定
    |
    永远不会出现在任何字段值中。这可能适用于您（大概）正在处理的数值，但您可能在某些时候需要更复杂的格式，例如URL编码的名称/值对

  • 双HMAC似乎对你没有多大帮助。根据目前的理解，针对HMAC-SHA256的暴力和密码分析已经非常困难

  • 除非你的事务/秒会对你的硬件征税，否则我只会在cookie中传递一个散列（即，省略用户id和到期日期——没有必要向坏人提供比你绝对必须提供的更多的信息）

  • 考虑到之前的动态IP地址，您可以对下一个动态IP地址应该是什么做一些假设（唉，我手头没有详细信息）。仅对动态IP地址的不变部分进行哈希运算将有助于验证用户，即使他们的IP地址发生变化。考虑到IP地址分配方案的多样性，这可能有效，也可能无效

  • 您还可以获得有关系统的信息和散列，在Linux中，您可以
    uname-a
    （但其他操作系统也有类似的功能）。足够的系统信息，您可以完全跳过使用（部分）IP地址。这项技术需要一些实验。仅使用通常由浏览器提供的系统信息将使操作更简单

  • 你需要考虑你的饼干应该保持新鲜多久。如果您可以与每天必须进行一次身份验证的人一起生活，那么在您的系统身份验证编码中，这将比只允许人们每月进行一次身份验证（等等）更容易

    • 我认为这个协议很弱小！
  • 您的会话cookie不是具有高熵的随机源
  • 服务器必须在每个页面上执行非对称加密以验证用户
  • 任何用户的安全性仅依赖于服务器密钥sk的安全性
    • 服务器密钥SK是此处最易受攻击的部分。 如果有人能猜到或偷走它，他可以作为一个特定的用户登录

    那么，如果为每个会话和用户生成sk，那么为什么要使用hmac呢？ 我想你无论如何都会使用TLS，如果没有，考虑你的协议因为重放攻击和窃听一般被破坏了。p> 如果为每个用户生成sk，但不是为每个会话生成sk，则它类似于256位密码

    如果sk对于所有用户都是相同的，那么某人只需破解256位，就可以作为任何用户登录。他只要猜一下身份证和出境日期就行了

    看一看。 这是rfc2617指定的每请求身份验证。 它对于在每次请求时使用nonce发送的攻击是安全的。 使用哈希进行窃听是安全的。
    它集成在http./p>这是一个很好的问题，我想知道你是否会考虑启动一个赏金来复活这个问题并得到更多的关注。甚至可以通过电子邮件将该问题的链接发送给各个安全专家。在Good idea中，您可能会得到更多答案。1） 这完全无关。2） 不涉及非对称加密，只涉及两个或四个哈希。3） 这就是密码学的全部意义，使系统依赖于密钥的安全性，而不是协议的安全性。“某人只需要破解256位”是荒谬的。这大约是2^256次尝试。好