Security zh CN
ASF 目前支持的加密方式定义为如下 ECryptoMethod：
| Value | 名称 |
|---|---|
| 0 | PlainText |
| 1 | AES |
| 2 | ProtectedDataForCurrentUser |
| 3 | EnvironmentVariable |
| 4 | File |
下文会详细解释与比较这些方式。
要生成加密过的密码，并在如 SteamPassword 等属性中使用，您可以执行 encrypt 命令，并带上您选择的适当加密方式与您的密码原文。 然后，将您获得的加密字符串填入 SteamPassword 机器人配置属性，并且对应修改 PasswordFormat 为符合加密方式的选项。 一些格式不需要 encrypt 命令，例如 EnvironmentVariable 或 File，而只需要设置合适的路径。
这是最简单但也最不安全的密码存储方式，指定 ECryptoMethod 为 0。 此时 ASF 需要字符串为纯文本——即密码的原文形式。 它是最容易使用的，并且与所有部署方式 100% 兼容，因此它是存储私密数据的默认值，但完全不安全。
按照当今的标准，AES 可以被视为安全的加密方式，指定 ECryptoMethod 为 1 即可启用这种方式。 ASF 需要相应字符串是一个由 AES 加密的字节数组转换成的 Base64 编码的字符序列，此数据需要其包含的初始向量和 ASF 内置加密密钥来解密。
此方法保证了安全性，只要攻击者不知道用于加密和解密的 ASF 密钥。 ASF 允许您通过 --cryptkey 命令行参数指定自定义密钥增强 ASF 的安全性。 如果您决定省略它，ASF 将使用自己提供的密钥，这个密钥是已知的并已硬编码到应用程序中，这意味着任何人都可以撤消 ASF 的加密并获取解密后的密码。 虽然这种攻击仍然需要一定时间而且并不容易，但是这是可以做到的。所以您总应该同时使用 AES 加密并用 --cryptkey 指定自定义密钥。 ASF 使用的 AES 方法提供了相对令人满意的安全性，并且它在 PlainText 的简单和 ProtectedDataForCurrentUser 的复杂之间取得了平衡，但强烈建议您将它与自定义密钥 --cryptkey 一起使用。 如果使用得当，就能保证安全存储的适当安全性。
这是目前 ASF 加密密码最安全的方式，比上述 AES 加密安全得多，您需要将 ECryptoMethod 指定为 2。 这种方法的主要优点同时也是它主要的缺点——它并不使用加密密钥（像 AES 那样），数据会使用当前计算机登录的用户凭据加密，这意味着数据仅能在这台机器上进行解密，事实上，仅仅触发加密的计算机用户才能解密。 如果您的 Bot.json 文件中的 SteamPassword 属性使用此方式加密，就可以保证即使您将整个文件发送给其他人，对方也无法在不直接接触您的计算机的情况下获得密码。 这是非常优秀的安全措施，但也有兼容性差的缺点，因为使用此方法加密的密码将不能兼容其他任何用户和计算机——假设您需要重新安装操作系统，这其中甚至包括您自己的计算机。 不过，这仍然是存储密码的最佳方法之一，如果您担心 PlainText 的安全性，也不想每次输入密码，那么只要您不会在其他机器上使用您的配置文件，这就是您最好的选择。
请注意，此选项目前仅适用于运行 Windows 操作系统的计算机。
基于内存的存储，ECryptoMethod 定义为 3。 ASF 会从环境变量中读取密码，环境变量的名字需要在密码字段（例如 SteamPassword）中指定。 例如，将 SteamPassword 设置为 ASF_PASSWORD_MYACCOUNT，并将 PasswordFormat 设置为 3，ASF 就会读取环境变量 ${ASF_PASSWORD_MYACCOUNT} 的内容作为帐户密码。
基于文件的存储（可以在 ASF 配置文件夹之外），ECryptoMethod 定义为 4。 ASF 会从文件中读取密码，文件的路径需要在密码字段（例如 SteamPassword）中指定。 指定的路径既可以是绝对路径，也可以相对于 ASF 根目录（也就是含有 config 文件夹的目录，同时遵循您设置的 --path 命令行参数）。 此方法可以配合 Docker secret 使用，它会自动创建对应的文件，但如果您自己创建所需的文件，也可以在 Docker 外使用。 例如，将 SteamPassword 设置为 /etc/secrets/MyAccount.pass，并将 PasswordFormat 设置为 4，ASF 就会读取 /etc/secrets/MyAccount.pass 文件，并将其内容作为帐户密码。
注意，请确保包含密码的文件不会被未授权用户读取到，因为这样就完全破坏了使用这种方法的目的。
如果兼容性对您来说不是问题，并且您可以接受 ProtectedDataForCurrentUser 方式，我们推荐您以这种方式存储密码，因为它有着最好的安全性。 对于还需要在其他计算机上使用配置文件的用户来说，AES 方法也是一个不错的选择。而 PlainText 是存储密码最简单的方法，只要您不介意其他人可能会查看您的 JSON 配置文件。
请注意，如果入侵者能够访问您的计算机，上述 3 种方法都不安全。 ASF 必须能够解密已加密的密码，如果在您的计算机上运行的某个程序能够做到这一点，那么在同一计算机上运行的其他程序也能做到这一点。 ProtectedDataForCurrentUser 是其中最安全的方法，即使使用同一台计算机的其他用户也无法解密，但如果有人窃取了您的登录凭据、计算机信息和 ASF 配置文件，他仍然有可能解密出您的密码。
对于复杂的安装方式，您可以利用 EnvironmentVariable 和 File。 它们的用途有限，如果您希望通过某种自定义方法获取密码并将其存储在内存中，则使用 EnvironmentVariable 较好，而使用 Docker secret 的情况则更适合使用 File。 但两者都没有加密，所以基本上是将风险从 ASF 配置文件转移到了您选择的另一个存储位置。
除了使用上述加密方式以外，您也可以完全不填写密码，例如，将 SteamPassword 设置为空字符串或者 null 值。 ASF 将会在需要时向您询问密码，并且不会将其保存在任何地方，仅仅临时存放在当前进程分配的内存中，一旦您关闭 ASF 就会消失。 随着这是处理密码的最安全的方法（密码没有被存储在任何地方），但也是最麻烦的，因为您需要在每次 ASF 运行时手动输入密码（如果需要）。 如果这对您来说不是问题，这就是您在安全方面的最佳选择。
ASF 不支持任何解密已加密密码的方法，因为解密方法仅在内部使用，用于访问进程内的数据。 如果您需要反转加密过程，例如，在使用 ProtectedDataForCurrentUser 加密的情况下，将 ASF 迁移到另一台机器，则在新环境中重新按上述流程操作即可。
ASF 目前支持的哈希方式定义为如下 EHashingMethod：
| 值 | 名称 |
|---|---|
| 0 | PlainText |
| 1 | SCrypt |
| 2 | Pbkdf2 |
下文会详细解释与比较这些方式。
要生成哈希值，并在如 IPCPassword 等属性中使用，您可以执行 hash 命令，并带上您选择的适当哈希方式与您的密码原文。 然后，将您获得的哈希字符串填入 IPCPassword 全局配置属性，并且对应修改 IPCPasswordFormat 为符合哈希方式的选项。
这是最简单但也最不安全的密码哈希方式，指定 EHashingMethod 为 0。 ASF 会生成与原文相同的哈希值。 它是最容易使用的，并且与所有部署方式 100% 兼容，因此它是存储私密数据的默认值，但完全不安全。
按照当今的标准，SCrypt 可以被视为安全的哈希方式，指定 EHashingMethod 为 1 即可使用这种方式。 ASF 的 SCrypt 实现采用 8 个块、8192 次迭代、32 位哈希长度，并使用加密密钥作为盐以生成字节数组。 其结果字节将会以 Base64 编码为字符串。
ASF 允许您通过 --cryptkey 命令行参数指定盐增强 ASF 的安全性。 如果您决定省略它，ASF 将使用自己提供的密钥，这个密钥是已知的并已硬编码到应用程序中，这意味着哈希过程会更不安全。 如果使用得当，就能保证安全存储的适当安全性。
按照当今的标准，Pbkdf2 是一种安全性较弱的哈希方式，指定 EHashingMethod 为 2 即可使用这种方式。 ASF 的 Pbkdf2 实现采用 10000 次迭代、32 位哈希长度，并使用加密密钥作为盐，SHA-256 作为 HMAC 算法以生成字节数组。 其结果字节将会以 Base64 编码为字符串。
ASF 允许您通过 --cryptkey 命令行参数指定盐增强 ASF 的安全性。 如果您决定省略它，ASF 将使用自己提供的密钥，这个密钥是已知的并已硬编码到应用程序中，这意味着哈希过程会更不安全。
如果您打算以哈希方式存储一些私密数据，例如 IPCPassword，我们建议您加盐使用 SCrypt，这可以提供足够的安全性对抗暴力破解尝试。 Pbkdf2 仅出于兼容性考虑才提供，主要是因为我们已有一种可用实现用于 Steam 平台相关用途（例如处理家庭监护代码）。 它仍然被认为是安全的，但与其替代品相比较弱（例如 SCrypt）。
