这个RESTful登录系统安全吗？

Question

因此，我一直在考虑如何为应用程序登录创建一个安全的restful。

这就是我和我老师想出的：

1. 客户端(快速程序)初始化与服务器的连接。
2. 服务器返回一个“共享秘密”(例如。+40)和随机字母和数字串的散列。
3. 然后，客户端散列用户名和密码(单独)，并使用散列+“共享秘密”的散列将其发回。
4. 服务器发送数据后(步骤2)，服务器哈希散列+“共享秘密”，然后在db中更新它
5. 然后，服务器从客户端接收哈希值，并检查数据库以确定它是否匹配。
6. db还将具有一个时间戳，如果更新不够频繁，将有一个函数在db中运行，并删除不再使用的项。
7. 对于登录后的每个请求，发送承载令牌。

持票人将遵循以下公式：

Request verification token = hash [ (original hash) + (shared secret) * (# of requests) ]

这是否足以防止中间人攻击和客户端欺骗，或者基本上可以让攻击者冒充用户？

Answer 1

不，您正在积极地损害可用性，却没有获得安全性。

这听起来像一个糟糕的安全剧院*！

我这么说是因为您目前所做的只是和通过HTTPS发送用户名和密码一样安全！您所添加的只是一些额外的设置通信。此实现的漏洞以及HTTPS发送密码和用户名的漏洞完全相同。

让我们详细分析一下这个例子：

设置和使用秘密

1. 建立安全连接
2. 发送要存储的有效载荷
3. 确认有效载荷，如果确认登录

设置并使用密码

1. 建立安全连接
2. 发送要存储的有效载荷
3. 确认有效载荷，如果确认登录

这些步骤完全相同，不提供额外的安全性。如果发生了完全接管(MITM/ system级)，与用户名和密码相同的事情将发生在您的系统上。攻击者在系统和服务器之间传输和访问数据时，仍会看到所有数据。这就是为什么完全收购是如此危险。基本上没有什么可以保护用户的。用户正在使用一个不再属于他们的通信系统，但是攻击者和那个攻击者可以看到并使用通信中的所有内容。

实际上，您所做的就是生成一个要存储的秘密(通常称为密码)，并生成一些元数据(通常称为用户名)来标识它。如果元数据和秘密匹配一个条目，则检索该信息。您获得的唯一优势是用户获得了一个超长的密码。但为了什么目的？Bcrypt有一个最大的字符长度，所以您限制了单个密码可以拥有的字符数。您现在也有了这个共享的秘密，可以担心每次获得相同的信息，或者您的用户，否则他们永远无法登录。

密码和用户名在HTTPS上的使用非常频繁，因为在某个点( HTTPS连接)之后，您无法提高安全性。如果有人可以访问所有的通信，或进入内存空间，你的所有技术都被击败了，因为他们只需要重新创建你的步骤，你甚至可能永远不知道，直到他们执行他们的攻击。

*：截至上周，这句话在我的键盘上被放大了.

*：安全剧场是一种将实践付诸实施的行为，这种做法无助于提高安全性，而且实际上可能会对其造成伤害！