验证用户(REST-API)

Question

我想要构建的

• 使用Express和SQLite的REST-API
• 5到10位作者应该能够在/articles上发表文章
• 除了他们，任何人都不允许发布任何东西。

我的方法来构建它

• 作者存储在数据库中。
• 密码与regex匹配，散列与盐分匹配。
• 为作者提供登录路径
• 登录后，将向作者发送一个JWT。

我曾经为学校构建过几次这样的API，但从未在生产中使用过。

如果这样做不安全，我真的很担心。我考虑过使用Auth0或其他IdaaS提供商，但我宁愿自己使用，特别是因为我不确定这些提供者的免费计划是否涵盖了我所需要的所有功能。

总之，自己构建身份验证的安全风险是什么？我能让我的方法更安全吗？是否有更好的“工作流”来为我的问题实现一种形式的身份验证？

Answer 1

你担心是对的。一个常见的建议是永远不要起草您自己的身份验证机制，因为您会弄错它。选择一个现有的；理解它是如何工作的；在您的项目中使用它。

这也适用于密码学。不要发明你自己的模式。例如，我不太清楚您所说的“密码与regex匹配、散列”是什么意思，但听起来是错误的。在检查密码时，不应该使用正则表达式，也不应该在散列密码之前对密码做任何操作。使用像PBKDF2这样的东西，透明地为您处理所有的散列和盐渍(替代品确实存在)。

更好的是，根本不要费心验证密码。即使您使用PBKDF2 2--这将有力地保证如果您的数据库泄漏，黑客就无法找到原始密码--如果服务器本身受到破坏，它也不会提供任何保护。如果黑客可以从根目录访问您的服务器，他可以从HTTP获取普通密码到登录页面。就这么简单。相反，可以通过OpenID或OAuth 2.0将身份验证委托给第三方，比如Google或Facebook。它的工作方式如下：

1. 该人到达您的网站，并希望登录。
2. 他被重定向到谷歌登录页面，并在那里做所有的事情。对于你来说，这是一个黑匣子:如果他已经登录，就可以点击他的名字，也可以像输入密码和用智能手机确认他的身份一样复杂--如果你自己实现的话，每发一条短信，你都会为此付出代价。
3. Google将用户重定向回您的站点，告诉您登录成功。

现在，即使您的服务器被破坏，您也可以确保您不需要向您的用户透露黑客获得了他们所有的密码。有了许多不同语言和生态系统的库，在您的web应用程序中集成OpenID或OAuth 2.0就相对容易了。

为回应以下意见：

如果你不喜欢或不信任谷歌或Facebook呢？

虽然谷歌和Facebook的提供商最受欢迎，但他们远不是唯一的供应商。一份更完整的清单显示，即使是那些不信任每一家美国供应商的人，也可以为俄罗斯的网站找到一个选项，比如VK和Yandex。

此外，如果只有您授权的用户才可以登录呢？

OpenID和OAuth都只告诉您，给定的用户已经过身份验证，并且拥有一组特定的元数据(电子邮件地址、化身等)。以及一组特定的角色。现在，决定如何处理这些信息属于您的应用程序。你可以把人登记进去。或者，您可以决定只有具有特定OpenID ID的用户才能登录，其他每个人都应该被拒绝。

例如，我正在使用Google的OAuth来处理敏感web应用程序的身份验证，比如启用/禁用我家警报的应用程序。如果有Google帐户的任何人都可以禁用警报，那么这个应用程序就会有一个硬编码if列表(我的if和我家人的if)，这是不太现实的。如果ID匹配，您可以看到web应用程序。如果没有-对不起，HTTP 403。

这些ID是应用程序从Google那里得到的。换句话说，谷歌告诉我们，“身份认证的人，他的ID是5900731.685，他的电子邮件地址是john@example.com，BTW，这是他的全名和化身。”从安全性的角度来看，人的全名和其他元素并不有趣:如果使用多个提供程序，您感兴趣的是ID，或者更准确地说，是对对(身份提供者，ID)感兴趣，以避免ID冲突。考虑到同一个人可以自然拥有多个ID (例如，如果他有时通过谷歌登录，而另一些时候则通过LinkedIn登录)，这对用户实际上成为站点用户的标识符。

基于这个ID，您可以做出各种决定，例如，显示用户的个人空间。或者，如果系统的设计仅限于非常狭窄的用户集，例如家庭自动化系统或公司构建服务器，您可以简单地对这些is进行硬编码，只允许特定用户访问应用程序。

如果有人创建一个谷歌帐户，并使用它登录到你的网站，他的ID将不会在白名单中。因此，他将不被允许进入。

Answer 2

一个简单的身份验证机制并不那么可怕。我建议采用一种基于会话的方法，而不是JWT，因为它更简单，而且更少地将其搞砸。

你自己不想做的部分是密码的散列。只需为您的生态系统使用一个流行的库，该库被专门设计为散列密码并遵循说明。

我不知道你把密码和regexp匹配起来是什么意思，但我很确定你不想这么做。只需再次散列接收到的密码，并将其与存储的哈希进行比较。

当用户通过登录路径登录时，比较密码散列，如果他们匹配，则生成随机会话ID并将其存储在数据库中。将会话ID返回给您的客户。当客户端现在想发布一篇文章时，检查它们是否提供了有效的会话ID (在头或cookie中)。

您应该知道什么是CSRF和XSS攻击，但如果您自己不进行身份验证，情况也是如此。

有很多方法可以在应用程序中创建安全问题，核心身份验证代码就是其中之一。有充分的理由永远不实现您自己的加密，但我不认为创建您自己的身份验证和授权代码是件坏事。其优点是简单性，如果您不太了解第三方解决方案的工作原理，则还可以在集成第三方解决方案时创建安全问题。