security - 我的基本用户身份验证方法有什么问题吗？

Question

当涉及到安全性和身份验证以及大多数其他客户端-服务器通信内容时，我有点新手。我想做的很简单，如果可能的话，避免引入第三方框架和类来完成这项工作。 (我使用 Google App Engine 和 Python)

用户通过移动应用程序 (iOS) 登录一次服务。登录后，用户将发出许多请求，以获取消息、好友、状态等信息。因此，每次应用程序与服务器通信时，我们不会发送该用户的电子邮件和密码进行身份验证，而是发送一个 session ID。到目前为止，这只是我对系统的理解。

我想出了一个非常简单的方法，对我来说似乎效果很好，但由于缺乏经验，我可能看不到很多东西。这样做会有什么问题:

1. 在设备上，用户输入电子邮件/密码，凭据将发送到服务器并进行验证，经过身份验证后，会生成一个随机数。该随机数作为 IntegerProperty 存储在用户模型上，名称为 session_number。

2. session_number 被发送到用户的设备并保存。现在，只要用户连接到服务器发出请求，session_number 就会连同用户的整数 ID 号一起发送到服务器。我们获取该 userId 的 User 实体，现在我们比较 user.session_number ==coming_session_number 的值。如果它们匹配，我们就很好，否则错误。

3. 如果用户注销，我们会从数据存储中清除 session_number。

这里唯一的问题是当用户从多个设备登录时如何处理？每个设备是否应该存储自己的 session_number？

Answer 1

除了我关于重新发明轮子的评论之外；我认为这个理论的主要问题是它完全受到重放攻击。

例如，给定一个 ID 为 99 且 session ID/cookie 为“MONKEY-1”的用户 — 如果该用户想要发送请求，他必须在某些情况下使用“from, 99, MONKEY-1”对其进行签名时尚。让我们假设它是这样的:

{ FROM: 99, TO: SERVER, COMMAND: GET-NEW-MAIL, SESSION: MONKEY-1 }

如果 MONKEY-1 是个 secret 的话那就太好了。 (无论您喜欢什么格式；它也可能是线路噪声的 4KiB 二进制 block 。)

但是现在，我们有一个窃听者，他看到了那个数据包经过……她现在发送了自己的数据包。也许她很聪明，欺骗了真实用户 99 使用的源 IP 地址 - 即使窃听者听不到您的回复，她仍然可以向您发送数据包。也许那个看起来像这样:

 { FROM: 99, TO: SERVER, COMMAND: DELETE-ALL-MAIL, SESSION: MONKEY-1 }

有很多方法可以防止此类事情发生，但效果各不相同。将连接封装在 SSL 中可以使这变得极其困难(但绝不是不可能)；这是许多网站所依赖的解决方案。更好的方法是使用散列或公钥/私钥加密技术，使用双向通信来以入侵者无法获取 secret 数据的方式对事物进行签名。例如，假设我们有一个这样的交换:

{ FROM: SERVER, TO: ??, COMMAND: PLEASE-LOGIN, NONCE: PIGEON }

{ FROM: BILL, TO: SERVER, COMMAND: LOGIN, AUTH: hash ( hash ( password ) . "PIGEON" ) }

…其中 hash() 表示 SHA-256 和，. “PIGEON”指的是串联；

{ FROM: SERVER, TO: BILL, COMMAND: LOGIN-OK, SESSION: hash ( password ) ^ "MONKEY-1" }

... 其中 ^ 可能指的是某种操作，例如按位异或。然后，随后，Bill 发送如下请求:

 { FROM: BILL, TO: SERVER, COMMAND: GET-NEW-MAIL, NONCE: "ARMADILLO", 
   AUTH: hash ( "GET-NEW-MAIL" . #\Newline . "ARMADILLO" . #\Newline . "MONKEY-1" ) }

现在，MONKEY-1 从来没有畅通无阻地旅行过；并且，每个请求上给出的 AUTH key 与所使用的动词或命令以及随机数相关联，该随机数应随每个请求而变化，并且服务器可以轻松验证其完整性，但窃听者无法再次重放相同的消息或更改动词并做一些不同的事情。

解释密码问题:

我有一个数据库表，它包含

User: BILL, Password: hash(DOLPHIN)

如果我通过网络收到

{ FROM: BILL, PASSWORD: hash(DOLPHIN), COMMAND: GET-ALL-MAIL }

...那么窃听者不太可能(但相当合理)知道密码是 DOLPHIN，但是，她不需要知道或关心:

 { FROM: BILL, PASSWORD: hash(DOLPHIN), COMMAND: DELETE-ALL-MAIL }

你提到对密码加盐……你会怎么做？

 User: BILL, PASSWORD: hash( SALT . DOLPHIN )

除非您将盐和海豚分开存放，否则没有简单的方法可以从哈希 (SALT . DOLPHIN) 到 哈希 (DOLPHIN)。因此，要么用户必须向您提交哈希 (SALT . DOLPHIN)(在客户端放置静态 SALT)，要么您必须再次存储明文密码。

解决方法可能是做类似的事情

 Database: ( BILL => hash ( SALT . DOLPHIN ) )

 Server sends: ( NONCE )

 Client sends: ( BILL => hash ( NONCE . hash ( SALT . DOLPHIN ) ) )