用户系统

• 1: 用户认证
• 1.1: 认证方法
• 1.2: Token 多平台认证
• 1.3: 基于密码
• 2: 用户授权

1 - 用户认证

Working In Progress

1.1 - 认证方法

身份验证与授权

身份验证（Authentication）是具备权限的系统验证尝试访问系统的用户或设备所用凭据的过程。相比之下，授权（Authorization）是给定系统验证是否允许用户或设备在系统上执行某些任务的过程。

简单地说：

1. 身份验证：你是谁？
2. 授权：你能做什么？

身份验证先于授权。也就是说，用户必须先处于合法状态，然后才能根据其授权级别被授予对资源的访问权限。验证用户身份的最常见方法是用户名和密码的组合。用户通过身份验证后，系统将为他们分配不同的角色，例如管理员、主持人等，从而为他们授予一些特殊的系统权限。

接下来，我们来看一下用于用户身份验证的各种方法。

HTTP 基本验证

HTTP 协议中内置的基本身份验证（Basic auth）是最基本的身份验证形式。使用它时，登录凭据随每个请求一起发送到请求标头中：

"Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" your-website.com

这里的用户名和密码未加密，而是使用一个:符号将用户名和密码串联在一起，形成单个字符串：username:password，再使用 base64 编码这个字符串。

>>> import base64
>>>
>>> auth = "username:password"
>>> auth_bytes = auth.encode('ascii') # convert to bytes
>>> auth_bytes
b'username:password'
>>>
>>> encoded = base64.b64encode(auth_bytes) # base64 encode
>>> encoded
b'dXNlcm5hbWU6cGFzc3dvcmQ='
>>> base64.b64decode(encoded) # base64 decode
b'username:password'

这种方法是无状态的，因此客户端必须为每个请求提供凭据。它适用于 API 调用以及不需要持久会话的简单身份验证工作流。

流程

1. 未经身份验证的客户端请求受限制的资源
2. 返回的 HTTP401Unauthorized 带有标头WWW-Authenticate，其值为 Basic。
3. WWW-Authenticate:Basic标头使浏览器显示用户名和密码输入框
4. 输入你的凭据后，它们随每个请求一起发送到标头中：Authorization: Basic dcdvcmQ=

优点

• 由于执行的操作不多，因此使用该方法可以快速完成身份验证。
• 易于实现。
• 所有主要浏览器均支持。

缺点

• Base64 不是加密。这只是表示数据的另一种方式。由于 base64 编码的字符串以纯文本格式发送，因此可以轻松解码。这么差的安全性很容易招致多种类型的攻击。因此，HTTPS/SSL 是绝对必要的。
• 凭据必须随每个请求一起发送。
• 只能使用无效的凭据重写凭据来注销用户。

代码

使用 Flask-HTTP 包，可以轻松地在 Flask 中完成基本的 HTTP 身份验证。

from flask import Flask
from flask_httpauth import HTTPBasicAuth
from werkzeug.security import generate_password_hash, check_password_hash

app = Flask(__name__)
auth = HTTPBasicAuth()

users = {
    "username": generate_password_hash("password"),
}


@auth.verify_password
def verify_password(username, password):
    if username in users and check_password_hash(users.get("username"), password):
        return username


@app.route("/")
@auth.login_required
def index():
    return f"You have successfully logged in, {auth.current_user()}"


if __name__ == "__main__":
    app.run()

HTTP 摘要验证

HTTP Digest Auth（或 Digest Access Auth）是 HTTP 基本验证的一种更安全的形式。主要区别在于 HTTP 摘要验证的密码是以 MD5 哈希形式代替纯文本形式发送的，因此它比基本身份验证更安全。

流程

1. 未经身份验证的客户端请求受限制的资源
2. 服务器生成一个随机值（称为随机数，nonce），并发回一个 HTTP 401 未验证状态，带有一个WWW-Authenticate标头（其值为Digest）以及随机数：WWW-Authenticate:Digestnonce="44f0437004157342f50f935906ad46fc"
3. WWW-Authenticate:Basic标头使浏览器显示用户名和密码输入框
4. 输入你的凭据后，系统将对密码进行哈希处理，然后与每个请求的随机数一起在标头中发送：Authorization: Digest username="username", nonce="16e30069e45a7f47b4e2606aeeb7ab62", response="89549b93e13d438cd0946c6d93321c52"
5. 服务器使用用户名获取密码，将其与随机数一起哈希，然后验证哈希是否相同

优点

• 由于密码不是以纯文本形式发送的，因此比基本身份验证更安全。
• 易于实现。
• 所有主要浏览器均支持。

缺点

• 凭据必须随每个请求一起发送。
• 只能使用无效的凭据重写凭据来注销用户。
• 与基本身份验证相比，由于无法使用 bcrypt，因此密码在服务器上的安全性较低。
• 容易受到中间人攻击。

代码

Flask-HTTP 包也支持摘要 HTTP 验证。

from flask import Flask
from flask_httpauth import HTTPDigestAuth

app = Flask(__name__)
app.config["SECRET_KEY"] = "change me"
auth = HTTPDigestAuth()

users = {
    "username": "password"
}


@auth.get_password
def get_user(username):
    if username in users:
        return users.get(username)


@app.route("/")
@auth.login_required
def index():
    return f"You have successfully logged in, {auth.current_user()}"


if __name__ == "__main__":
    app.run()

基于会话的验证

使用基于会话的身份验证（或称会话 cookie 验证、基于 cookie 的验证）时，用户状态存储在服务器上。它不需要用户在每个请求中提供用户名或密码，而是在登录后由服务器验证凭据。如果凭据有效，它将生成一个会话，并将其存储在一个会话存储中，然后将其会话 ID 发送回浏览器。浏览器将这个会话 ID 存储为 cookie，该 cookie 可以在向服务器发出请求时随时发送。

基于会话的身份验证是有状态的。每次客户端请求服务器时，服务器必须将会话放在内存中，以便将会话 ID 绑定到关联的用户。

流程

优点

• 后续登录速度更快，因为不需要凭据。
• 改善用户体验。
• 相当容易实现。许多框架（例如 Django）都是开箱即用的。

缺点

• 它是有状态的。服务器要在服务端跟踪每个会话。用于存储用户会话信息的会话存储需要在多个服务之间共享以启用身份验证。因此，由于 REST 是无状态协议，它不适用于 RESTful 服务。
• 即使不需要验证，Cookie 也会随每个请求一起发送
• 易受 CSRF 攻击。在这里阅读更多关于 CSRF 以及如何在 Flask 中防御它的信息。

代码

Flask-Login 非常适合基于会话的身份验证。这个包负责登录和注销，并可以在一段时间内记住用户。

from flask import Flask, request
from flask_login import (
    LoginManager,
    UserMixin,
    current_user,
    login_required,
    login_user,
)
from werkzeug.security import generate_password_hash, check_password_hash


app = Flask(__name__)
app.config.update(
    SECRET_KEY="change_this_key",
)

login_manager = LoginManager()
login_manager.init_app(app)


users = {
    "username": generate_password_hash("password"),
}


class User(UserMixin):
    ...


@login_manager.user_loader
def user_loader(username: str):
    if username in users:
        user_model = User()
        user_model.id = username
        return user_model
    return None


@app.route("/login", methods=["POST"])
def login_page():
    data = request.get_json()
    username = data.get("username")
    password = data.get("password")

    if username in users:
        if check_password_hash(users.get(username), password):
            user_model = User()
            user_model.id = username
            login_user(user_model)
        else:
            return "Wrong credentials"
    return "logged in"


@app.route("/")
@login_required
def protected():
    return f"Current user: {current_user.id}"


if __name__ == "__main__":
    app.run()

基于令牌的身份验证

这种方法使用令牌而不是 cookie 来验证用户。用户使用有效的凭据验证身份，服务器返回签名的令牌。这个令牌可用于后续请求。

最常用的令牌是 JSON Web Token（JWT）。JWT 包含三个部分：

• 标头（包括令牌类型和使用的哈希算法）
• 负载（包括声明，是关于主题的陈述）
• 签名（用于验证消息在此过程中未被更改）

这三部分都是 base64 编码的，并使用一个.串联并做哈希。由于它们已编码，因此任何人都可以解码和读取消息。但是，只有验证的用户才能生成有效的签名令牌。令牌使用签名来验证，签名用的是一个私钥。

JSON Web Token（JWT）是一种紧凑的、URL 安全的方法，用于表示要在两方之间转移的声明。JWT 中的声明被编码为一个 JSON 对象，用作一个 JSON Web Signature（JWS）结构的负载，或一个 JSON Web Encryption（JWE）结构的纯文本，从而使声明可以进行数字签名，或使用一个消息验证码 Message Authentication Code（MAC）来做完整性保护和/或加密。——IETF

令牌不必保存在服务端。只需使用它们的签名即可验证它们。近年来，由于 RESTfulAPI 和单页应用（SPA）的出现，令牌的使用量有所增加。

流程

优点

• 它是无状态的。服务器不需要存储令牌，因为可以使用签名对其进行验证。由于不需要数据库查找，因此可以让请求更快。
• 适用于微服务架构，其中有多个服务需要验证。我们只需在每一端配置如何处理令牌和令牌密钥即可。

缺点

• 根据令牌在客户端上的保存方式，它可能导致 XSS（通过 localStorage）或 CSRF（通过 cookie）攻击。
• 令牌无法被删除。它们只能过期。这意味着如果令牌泄漏，则攻击者可以滥用令牌直到其到期。因此，将令牌过期时间设置为非常小的值（例如 15 分钟）是非常重要的。
• 需要设置令牌刷新以在到期时自动发行令牌。
• 删除令牌的一种方法是创建一个将令牌列入黑名单的数据库。这为微服务架构增加了额外的开销并引入了状态。

代码

Flask-JWT-Extended 包为处理 JWT 提供了很多可能性。

from flask import Flask, request, jsonify
from flask_jwt_extended import (
    JWTManager,
    jwt_required,
    create_access_token,
    get_jwt_identity,
)
from werkzeug.security import check_password_hash, generate_password_hash

app = Flask(__name__)
app.config.update(
    JWT_SECRET_KEY="please_change_this",
)

jwt = JWTManager(app)

users = {
    "username": generate_password_hash("password"),
}


@app.route("/login", methods=["POST"])
def login_page():
    username = request.json.get("username")
    password = request.json.get("password")

    if username in users:
        if check_password_hash(users.get(username), password):
            access_token = create_access_token(identity=username)
            return jsonify(access_token=access_token), 200

    return "Wrong credentials", 400


@app.route("/")
@jwt_required
def protected():
    return jsonify(logged_in_as=get_jwt_identity()), 200


if __name__ == "__main__":
    app.run()

一次性密码

一次性密码（One Time Password，OTP）通常用作身份验证的确认。OTP 是随机生成的代码，可用于验证用户是否是他们声称的身份。它通常用在启用双因素身份验证的应用中，在用户凭据确认后使用。

要使用 OTP，必须存在一个受信任的系统。这个受信任的系统可以是经过验证的电子邮件或手机号码。

现代 OTP 是无状态的。可以使用多种方法来验证它们。尽管有几种不同类型的 OTP，但基于时间的 OTP（TOTP）可以说是最常见的类型。它们生成后会在一段时间后过期。

由于 OTP 让你获得了额外的一层安全保护，因此建议将 OTP 用于涉及高度敏感数据的应用，例如在线银行和其他金融服务。

流程

实现 OTP 的传统方式：

• 客户端发送用户名和密码
• 经过凭据验证后，服务器会生成一个随机代码，将其存储在服务端，然后将代码发送到受信任的系统
• 用户在受信任的系统上获取代码，然后在 Web 应用上重新输入它
• 服务器对照存储的代码验证输入的代码，并相应地授予访问权限

TOTP 如何工作：

• 客户端发送用户名和密码
• 经过凭据验证后，服务器会使用随机生成的种子生成随机代码，并将种子存储在服务端，然后将代码发送到受信任的系统
• 用户在受信任的系统上获取代码，然后将其输入回 Web 应用
• 服务器使用存储的种子验证代码，确保其未过期，并相应地授予访问权限

谷歌身份验证器、微软身份验证器和 FreeOTP 等 OTP 代理如何工作：

• 注册双因素身份验证（2FA）后，服务器会生成一个随机种子值，并将该种子以唯一 QR 码的形式发送给用户
• 用户使用其 2FA 应用程序扫描 QR 码以验证受信任的设备
• 每当需要 OTP 时，用户都会在其设备上检查代码，然后在 Web 应用中输入该代码
• 服务器验证代码并相应地授予访问权限

优点

• 添加了一层额外的保护
• 不会有被盗密码在实现 OTP 的多个站点或服务上通过验证的危险

缺点

• 你需要存储用于生成 OTP 的种子。
• 像谷歌验证器这样的 OTP 代理中，如果你丢失了恢复代码，则很难再次设置 OTP 代理
• 当受信任的设备不可用时（电池耗尽，网络错误等）会出现问题。因此通常需要一个备用设备，这个设备会引入一个额外的攻击媒介。

代码

PyOTP 包提供了基于时间和基于计数器的 OTP。

from time import sleep

import pyotp

if __name__ == "__main__":
    otp = pyotp.TOTP(pyotp.random_base32())
    code = otp.now()
    print(f"OTP generated: {code}")
    print(f"Verify OTP: {otp.verify(code)}")
    sleep(30)
    print(f"Verify after 30s: {otp.verify(code)}")

示例：

OTP generated: 474771
Verify OTP: True
Verify after 30s: False

OAuth 和 OpenID

OAuth/OAuth2 和 OpenID 分别是授权和身份验证的流行形式。它们用于实现社交登录，一种单点登录（SSO）形式。社交登录使用来自诸如 Facebook、Twitter 或谷歌等社交网络服务的现有信息登录到第三方网站，而不是创建一个专用于该网站的新登录帐户。

当你需要高度安全的身份验证时，可以使用这种身份验证和授权方法。这些提供者中有一些拥有足够的资源来增强身份验证能力。利用经过反复考验的身份验证系统，可以让你的应用程序更加安全。

这种方法通常与基于会话的身份验证结合使用。

流程

你访问的网站需要登录。你转到登录页面，然后看到一个名为“使用谷歌登录”的按钮。单击该按钮，它将带你到谷歌登录页面。通过身份验证后，你将被重定向回自动登录的网站。这是使用 OpenID 进行身份验证的示例。它让你可以使用现有帐户（通过一个 OpenID 提供程序）进行身份验证，而无需创建新帐户。

最著名的 OpenID 提供方有谷歌、Facebook、Twitter 和 GitHub。

登录后，你可以转到网站上的下载服务，该服务可让你直接将大文件下载到谷歌云端硬盘。网站如何访问你的 Google 云端硬盘？这里就会用到 OAuth。你可以授予访问另一个网站上资源的权限。在这里，你授予的就是写入谷歌云端硬盘的访问权限。

优点

• 提高安全性。
• 由于无需创建和记住用户名或密码，因此登录流程更加轻松快捷。
• 如果发生安全漏洞，由于身份验证是无密码的，因此不会对第三方造成损害。

缺点

• 现在，你的应用程序依赖于你无法控制的另一个应用。如果 OpenID 系统关闭，则用户将无法登录。
• 人们通常倾向于忽略 OAuth 应用程序请求的权限。
• 在你配置的 OpenID 提供方上没有帐户的用户将无法访问你的应用程序。最好的方法是同时实现多种途径。例如用户名和密码以及 OpenID，并让用户自行选择。

代码

你可以使用 Flask-Dance 实现 GitHub 社交身份验证。

from flask import Flask, url_for, redirect
from flask_dance.contrib.github import make_github_blueprint, github

app = Flask(__name__)
app.secret_key = "change me"
app.config["GITHUB_OAUTH_CLIENT_ID"] = "1aaf1bf583d5e425dc8b"
app.config["GITHUB_OAUTH_CLIENT_SECRET"] = "dee0c5bc7e0acfb71791b21ca459c008be992d7c"

github_blueprint = make_github_blueprint()
app.register_blueprint(github_blueprint, url_prefix="/login")


@app.route("/")
def index():
    if not github.authorized:
        return redirect(url_for("github.login"))
    resp = github.get("/user")
    assert resp.ok
    return f"You have successfully logged in, {resp.json()['login']}"


if __name__ == "__main__":
    app.run()

总结

在本文中，我们研究了许多不同的 Web 身份验证方法，它们都有各自的优缺点。

你什么时候应该使用哪种方法？具体情况要具体分析。一些基本的经验法则：

1. 对于利用服务端模板的 Web 应用程序，通过用户名和密码进行基于会话的身份验证通常是最合适的。你也可以添加 OAuth 和 OpenID。
2. 对于 RESTful API，建议使用基于令牌的身份验证，因为它是无状态的。
3. 如果必须处理高度敏感的数据，则你可能需要将 OTP 添加到身份验证流中。

最后请记住，本文的示例仅仅是简单的演示。生产环境需要进一步的配置。

1.2 - Token 多平台认证

概述

在存在账号体系的信息系统中，对身份的鉴定是非常重要的事情。随着移动互联网时代到来，客户端的类型越来越多， 逐渐出现了 一个服务器，N 个客户端的格局 。

不同的客户端产生了不同的用户使用场景，这些场景：

• 有不同的环境安全威胁
• 不同的会话生存周期
• 不同的用户权限控制体系
• 不同级别的接口调用方式

综上所述，它们的身份认证方式也存在一定的区别。

应用场景

下面是一些在 IT 服务常见的一些使用场景:

• 用户在web浏览器端登录系统,使用系统服务
• 用户在手机端（Android/iOS）登录系统,使用系统服务
• 用户使用开放接口登录系统,调用系统服务
• 用户在PC处理登录状态时通过手机扫码授权手机登录（使用得比较少）
• 用户在手机处理登录状态进通过手机扫码授权PC进行登录（比较常见）

通过对场景的细分,得到如下不同的认证token类别：

1. 原始账户密码
   1. 用户名和密码
   2. API 应用 ID/KEY
2. 会话 ID
   1. 浏览器端 token
   2. 移动端 token
   3. API 应用 token
3. 接口调用
   1. 接口访问 token
   2. 身份授权
   3. PC 和移动端相互授权的 token

Token 的类别

不同场景的 token 进行如下几个维度的对比：

天然属性对比

• 使用成本：本认证方式在使用的时候,造成的不便性。比如:

  • 账号密码需要用户打开页面然后逐个键入

  • 二维码需要用户掏出手机进行扫码操作

• 变化成本：本认证方式,token发生变化时,用户需要做出的相应更改的成本:

  • 用户名和密码发生变化时,用户需要额外记忆和重新键入新密码

  • API应用ID/KEY发生变化时,第三方应用需要重新在代码中修改并部署

  • 授权二维码发生变化时,需要用户重新打开手机应用进行扫码

• 环境风险

  • 被偷窥的风险

  • 被抓包的风险

  • 被伪造的风险

可控属性对比

• 使用频率
  • 在网路中传送的频率。
• 有效时间
  • 此token从创建到终结的生存时间

最终目标：安全和影响

安全和隐私性主要体现在:

• token 不容易被窃取和盗用（通过对传送频率控制）
• token 即使被窃取,产生的影响也是可控的（通过对有效时间控制）

关于隐私及隐私破坏后的后果,有如下的基本结论:

• 曝光频率高的容易被截获
• 生存周期长的在被截获后产生的影响更严重和深远

遵守如下原则:

• 变化成本高的token不要轻易变化
• 不轻易变化的token要减少曝光频率（网络传输次数）
• 曝光频率高的token的生存周期要尽量短

将各类token的固有特点及可控属性进行调控后, 对每个指标进行量化评分（1~5分），我们可以得到如下的对比表：

备注：user_name/passwd 和 app_id/app_key 是等价的效果

Token 的层级关系

参考上一节的对比表，可以很容易对这些不同用途的token进行分层，主要可以分为4层：

• 密码层：最传统的用户和系统之间约定的数字身份认证方式
• 会话层：用户登录后的会话生命周期的会话认证
• 调用层：用户在会话期间对应用程序接口的调用认证
• 应用层：用户获取了接口访问调用权限后的一些场景或者身份认证应用

Token 的分层图如下：

在一个多客户端的信息系统里面,这些token的产生及应用的内在联系如下:

• 用户输入用户名和用户口令进行一次性认证
• 在 不同 的终端里面生成拥有 不同 生命周期的会话token
• 客户端会话token从服务端交换生命周期短但曝光 频繁 的接口访问token
• 会话token可以生成和刷新延长 access_token 的生存时间
• access_token可以生成生存周期最短的用于授权的二维码的token

使用如上的架构有如下的好处：

• 良好的统一性：可以解决不同平台上认证token的生存周期的 归一化 问题
• 良好的解耦性：核心接口调用服务器的认证 access_token 可以完成独立的实现和部署
• 良好的层次性：不同平台的可以有完全不同的用户权限控制系统，这个控制可以在 会话层 中各平台解决掉

账户密码

广义的 账号/密码 有如下的呈现方式:

• 传统的注册用户名和密码
• 应用程序的app_id/app_key

它们的特点如下：

• 会有特别的意义
  • 比如：用户自己为了方便记忆，会设置有一定含义的账号和密码。
• 不常修改
  • 账号密码对用户有特别含义，一般没有特殊情况不会愿意修改。而app_id/app_key则会写在应用程序中，修改会意味着重新发布上线的成本。
• 一旦泄露影响深远
  • 正因为不常修改，只要泄露了基本相当于用户的网络身份被泄露，而且只要没被察觉这种身份盗用就会一直存在。
  • 所以在认证系统中应该尽量减少传输的机会，避免泄露。

客户端会话 Token

功能：充当着session的角色，不同的客户端有不同的生命周期。

使用步骤：用户使用账号密码，换取会话token。

不同的平台的 token 有不同的特点：

• Web 平台生存周期短，主要原因是：
  • 环境安全性：由于web登录环境一般很可能是公共环境，被他人盗取的风险值较大。
  • 输入便捷性：在PC上使用键盘输入会比较便捷。
• 移动端生存周期长，主要原因是：
  • 环境安全性：移动端平台是个人用户极其私密的平台，它人接触的机会不大。
  • 输入便捷性：在移动端上使用手指在小屏幕上触摸输入体验差，输入成本高。

access_token

**功能：**服务端应用程序api接口访问和调用的凭证。

**使用步骤：**使用具有较长生命周期的会话token来换取此接口访问token。

其曝光频率直接和接口调用频率有关，属于高频使用的凭证。为了照顾到隐私性，尽量减少其生命周期，即使被截取了，也不至于产生严重的后果。

注意：在客户端token之下还加上一个access_token， 主要是为了让具有不同生命周期的客户端token最后在调用 API 的时候， 能够具有统一的认证方式。

pam_token

**功能：**由已经登录和认证的PC端生成的二维码的原始串号（Pc Auth Mobile）。

主要步骤如下：

1. PC上用户已经完成认证，登录了系统
2. PC端生成一组和此用户相关联的pam_token
3. PC端将此pam_token的使用链接生成二维码
4. 移动端扫码后，请求服务器，并和用户信息关联
5. 移动端获取refresh_token(长时效的会话)
6. 根据 refresh_token 获取 access_token
7. 完成正常的接口调用工作

备注:

• 生存周期为2分钟,2分钟后过期删除
• 没有被使用时,每1分钟变一次
• 被使用后,立刻删除掉
• 此种认证模式一般不会被使用到

map_token

**功能：**由已经登录的移动app来扫码认证PC端系统，并完成PC端系统的登录（Mobile Auth Pc）。

主要步骤：

1. 移动端完成用户身份的认证登录app
2. 未登录的PC生成匿名的 map_token
3. 移动端扫码后在db中生成 map_token 和用户关联（完成签名）
4. db同时针对此用户生成 web_token
5. PC端一直以 map_token 为参数查找此命名用户的 web_token
6. PC端根据 web_token 去获取 access_token
7. 后续正常的调用接口调用工作

备注:

• 生存周期为2分钟,2分钟后过期删除
• 没有被使用时,每1分钟变一次
• 被使用后,立刻删除掉

总结

本文所设计的基于token的身份认证系统，主要解决了如下的问题：

• token的分类问题
• token的隐私性参数设置问题
• token的使用场景问题
• 不同生命周期的token分层转化关系

本文中提到的设计方法，在 应用层 中可以适用于且不限于如下场景中：

• 用户登录
• 有时效的优惠券发放
• 有时效的邀请码发放
• 有时效的二维码授权
• 具有时效 手机/邮件 验证码
• 多个不同平台调用同一套API接口
• 多个平台使用同一个身份认证中心

1.3 - 基于密码

基于密码实现用户注册与登录。

错误做法

1. 以纯文本存储密码不是一个好主意，因为任何有内部访问权限的人都可以看到它们。
2. 直接存储密码哈希值是不够的，因为它会被预先计算的攻击修剪，例如彩虹表。

正确做法

确保密码在整个传输、保存、校验过程中，密码都是不可见的。

保存流程

1. [前端]用户输入密码，生成密码盐，连同用户 ID 一起保存到[后端]。
2. [前端]将密码盐拼接到密码中，对拼接结果执行哈希，连同用户 ID 和 HASH 值保存到[后端]。
3. [前端]密码保存完成。

校验流程

1. [前端]用户输入密码，基于用户 ID 查询密码盐，[后端]返回密码盐给[前端]。
2. [前端]将密码盐拼接到密码中，对拼接结果执行哈希，连同用户 ID 和 HASH 值提交给[后端]。
3. [后端]在接收到用户 ID 和 HASH 值后，基于用户 ID 查询已存储的 HASH 值，然后比较两个 HASH 值。
4. [后端]将比较结果返回该前端，密码校验完成。

相关逻辑

• 用户 ID：用户唯一标识，可以是邮箱，也可以是由后端生成的唯一 ID。
• 生成密码盐：根据 OWASP 指南，“密码盐是一个独特的、随机生成的字符串，作为散列过程的一部分被添加到每个密码中”。比如 UUID。
• 保存密码盐：盐本身并非秘密，它可以以纯文本形式存储在数据库中。它用于确保哈希结果对每个密码都是唯一的。
• 哈希函数：密码学文本摘要算法，如 SHA256 中的 Encrypt.hash。

2 - 用户授权

Working In Progress