Question

以下是身份验证流程的细分：

用户注册（电子邮件，密码）
用户登录

如果他们的登录有效，则在服务器端使用以下代码生成令牌：

require('crypto').randomBytes(48, function(ex, buf) {
    var token = buf.toString('hex');
    // generates a token, such as....
    //  9b50ea46e80804bfe2ae01d0d1bb099c26887a65c92f61e47677c28ed40dbd4ef4c14f0dc58688ab4ec0df6b766ec90f
});

该令牌将返回客户端，并保存为cookie
他们登录的用户 IP地址与令牌一起存储到数据库中

该令牌存储在数据库 hashed 中，其代码如下：

var salt = bcrypt.genSaltSync(10);
bcrypt.hash(token, salt, null, function(err, hash) {
    token = hash;
    token.save();
    // salts and hashes a token and saves that hashed token to the database
    // resulting hashed token will look like...
    // $2a$10$rGjMO6bWb/R4/yAAEV8Nx.7Fr6bS.AmMS0vRYB7p5umTpfpjMOfAC
});

对于从客户端到服务器的所有未来请求，“auth_token”标头会自动附加到所有类型的所有请求，包含之前提供给客户端的未散列令牌，该令牌已保存到cookie < / p>
当请求进入服务器时，它会检查是否附加了“auth_token”标头
如果“auth_token”标题不存在，则会拒绝其对API数据的请求
如果“auth_token”标题 DOES 存在，它......
- 检查令牌是否有效（通过对数据库中的令牌执行bcrypt.compare存在于数据库中，直到找到匹配项）并且属于与应用程序交互的当前用户（用户ID）发送请求与DB）中附加到该令牌的用户ID匹配
- 检查请求数据的IP地址是否与数据库中该标记附加的IP地址匹配
- 检查令牌是否已过期（在服务器端，而不是客户端cookie）
如果上述所有测试都通过，它会向用户提供他们正在寻找的数据......如果它们中的任何一个失败，它会给予他们403禁止的。

这是我第一个为了学习目的从头开始制作的令牌认证系统。

欢迎思考/批评/问题！如果我错过了解释这个设置的任何关键部分，请回答，我会澄清。

我能看到有人滥用此功能的唯一方法是：

访问某人计算机
从Cookie中获取令牌
向API发送请求，欺骗用户IP，使用其令牌，并在令牌过期前的时间范围内
授予数据

但是为了做到这一点，他们必须基本上可以访问那些人的计算机以获取cookie，如果他们可以访问那些人的计算机，他们已经基本上可以无限制地访问数据ANYWAY因为赔率是该人仍然登录该网站和/或该人在网站上自动填写了他们的密码和用户名等。

Answer 1

我身上有两件事：

永远不要在实际代码中使用同步方法。（genSaltSync）加密方法计算量很大;在JS线程上执行它们是灾难的一个方法。极少数的并发登录尝试会使服务器停止运行。
您将用户的IP地址视为常量，但这不是有效的断言。在DHCP，频繁更改网络的移动设备，VPN和代理服务器之间，您无法知道用户的下一个请求是否来自同一IP。

来自被随机拒绝访问的用户的支持噩梦是（IMO）不值得投机安全获益。只要您已正确配置SSL并设置Cookie Secure and HttpOnly，令牌被盗的风险就会很小。

这是一个从头开始制作的足够安全的令牌认证系统吗？

1 个答案: