> For the complete documentation index, see [llms.txt](https://docs.docbits.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.docbits.com/chinese/gai-shu-yu-ji-chu/secure-storage-of-credentials.md).

# 凭据的安全存储

DocBits 中密码哈希、API 密钥存储、TLS、凭据可见性和账户恢复的说明。

DocBits 根据用途处理登录密码、DocBits API 密钥、账户信息以及已连接系统的凭据。本页说明各类信息的保护和恢复方式。

## 登录密码

DocBits 将登录密码存储为**加盐的单向密码哈希**。用户登录时，系统会将其输入的密码与存储的哈希进行比对。原始密码不会以可解密并还原的形式存储。

因此，管理员和 DocBits 支持人员都无法从存储的密码哈希中取回现有的明文登录密码。如果用户忘记密码，必须重置密码才能继续使用密码登录。

### 重置密码

1. 在登录界面选择**忘记密码？**。
2. 输入与账户关联的电子邮件地址。
3. 打开发送至该地址的密码重置链接。
4. 设置新密码，并使用新密码登录。

重置链接会过期。如果链接已过期，请重新申请。此流程会设置新密码，不会显示之前的密码。完整说明请参阅[获取访问权限并登录](/chinese/zui-zhong-yong-hu-yu-he-zuo-huo-ban/end-user-section/getting-access-and-signing-in.md#forgot-password)。

已配置 SSO 或通行密钥登录方式的账户可以使用相应的替代登录方式。对于 SSO，密码恢复由身份提供商处理。请参阅[双因素身份验证](/chinese/gai-shu-yu-ji-chu/two-factor-authentication.md)。

## DocBits API 密钥

通过**API 密钥管理**创建的 API 密钥仅会在创建时完整显示一次。DocBits 会存储该密钥的单向哈希和一个简短的标识前缀。管理列表中会保留并显示此前缀和密钥元数据；无法从哈希中取回原始完整密钥。

管理员和 DocBits 支持人员都无法在创建后查询完整密钥。如果密钥丢失，请撤销该密钥并创建替代密钥。每个密钥都可以单独设置过期日期并单独撤销。请参阅[API 密钥管理](/chinese/guan-li-yu-she-zhi/settings/global-settings/integration/api-key-management.md)。

## 账户详细信息和已连接系统的凭据

姓名、电子邮件地址、角色和账户状态属于账户信息，获得授权的组织管理员可以查看和管理这些信息。它们与用于身份验证的秘密凭据相互独立。请参阅[用户](/chinese/guan-li-yu-she-zhi/settings/global-settings/groups-users-and-permissions/users.md)。

为已连接系统提供的凭据（例如 ERP 服务账户、邮箱或 SFTP 服务器的凭据）也不同于 DocBits 登录密码或 DocBits 签发的 API 密钥。连接器可能需要使用可用的秘密凭据向外部系统进行身份验证。因此，必须针对相应连接器评估其存储方式和访问控制。

无法取回登录密码或哈希后的 DocBits API 密钥，**并不意味着**供应商无法访问所有账户信息或所有集成秘密凭据。要保证人员无法访问集成凭据，必须确认相关的运营访问控制措施。

## 传输中的加密 <a href="#encryption-in-transit" id="encryption-in-transit"></a>

以下 DocBits 公共端点支持通过 HTTPS 使用 **TLS 1.2 和 TLS 1.3**。**2026 年 10 月 16 日**的检查确认，这些端点拒绝 TLS 1.0 和 TLS 1.1。

| 端点                 | 用途       | 已验证支持的 TLS 版本     |
| ------------------ | -------- | ----------------- |
| `app.docbits.com`  | Web 应用程序 | TLS 1.2 和 TLS 1.3 |
| `auth.docbits.com` | 身份验证服务   | TLS 1.2 和 TLS 1.3 |
| `api.docbits.com`  | API      | TLS 1.2 和 TLS 1.3 |

### 支持哪些类型的传输加密？

| 问卷项目          | 上述公共端点的回答                     |
| ------------- | ----------------------------- |
| 是否支持 TLS 1.1？ | \*\*否。\*\*使用 TLS 1.1 的连接会被拒绝。 |
| 是否支持 TLS 1.2？ | **是。**                        |
| 是否支持 TLS 1.3？ | **是。**                        |

在 2026 年 10 月 16 日进行的证书验证测试中，以下加密方法均在**全部三个端点**上成功协商：

| 加密方法              | 对称加密密钥长度 | 已验证的 TLS 版本       |
| ----------------- | -------- | ----------------- |
| AES-128-GCM       | 128 位    | TLS 1.2 和 TLS 1.3 |
| AES-256-GCM       | 256 位    | TLS 1.2 和 TLS 1.3 |
| ChaCha20-Poly1305 | 256 位    | TLS 1.3           |

这些方法提供经身份验证的加密，以保护传输中数据的机密性和完整性。协商使用的方法取决于客户端和服务器的能力及配置。上述位数指对称数据加密密钥的长度，与证书密钥大小无关。经过测试的 TLS 1.2 密码套件使用 ECDHE 进行临时密钥交换。

此验证涵盖与这些公共端点的连接，包括客户端或其他服务器连接到这些端点的情形。它不能证明每个内部服务连接、数据库连接、区域端点或外部集成所使用的协议或加密设置。相关连接需要针对适用的部署和集成另行确认。

## 已存储账户信息的加密

DigitalOcean Managed Databases 使用 AES-256-XTS 进行全卷 LUKS 加密；其托管备份使用 AES-256-CTR。Spaces 在物理磁盘上使用 256 位 AES-XTS。有关加密方法、密钥管理、备份覆盖范围，请参阅[静态数据加密](/chinese/security/encryption-at-rest.md)。

密码哈希和 API 密钥哈希是与数据库、存储卷、对象及备份加密相互独立的控制措施。上述控制措施不能证明每个用户名、账户字段或集成秘密凭据都经过单独加密，也不能证明所有存储的数据都使用了特定加密算法。

如果要求涵盖所有客户账户信息，请向 FELLOWPRO AG 索取针对具体部署的说明，确认相关数据存储和备份、加密方法、密钥管理以及人员访问权限。仅凭云托管或无服务器托管模式，无法证明这些属性。

## 回答客户安全问卷

以下内容说明了已确认的范围：

> DocBits 登录密码以加盐的单向哈希形式存储。管理员和 DocBits 支持人员无法从存储的哈希中取回原始明文密码。忘记密码的用户必须通过电子邮件重置流程设置新密码，才能继续使用密码登录。已配置的 SSO 或通行密钥方式可作为替代登录选项。
>
> 通过 DocBits API 密钥管理创建的 API 密钥仅显示一次，并以单向哈希形式存储。管理员和 DocBits 支持人员都无法在创建后取回完整密钥。丢失的密钥必须先撤销，再创建替代密钥。
>
> 上述 DocBits 公共 Web 应用程序、身份验证和 API 端点支持通过 HTTPS 使用 TLS 1.2 和 TLS 1.3；2026 年 10 月 16 日的检查拒绝了 TLS 1.0 和 TLS 1.1。已验证的加密方法包括：在 TLS 1.2 和 TLS 1.3 下使用 128 位密钥的 AES-128-GCM，以及使用 256 位密钥的 AES-256-GCM；在 TLS 1.3 下使用 256 位密钥的 ChaCha20-Poly1305。此说明涵盖与这些端点的连接。所有已存储账户信息和备份的加密、每个内部服务器连接的保护，以及人员对第三方集成凭据的访问权限，都需要针对相关部署另行确认。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.docbits.com/chinese/gai-shu-yu-ji-chu/secure-storage-of-credentials.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.