PIN 的用途
支持案例通常进行到某个阶段，对方需要确认自己正在与真正的账号所有者沟通。GitLab Support PIN 正是为此而设。它是账号所有者按需生成的代码，供支持人员将请求与账号进行核对，其权限被刻意限制得比密码更窄。
这种窄范围正是关键所在。密码可以打开整个账号，恢复代码可以重置访问权限，公开用户 ID 或个人资料用户名任何人都能看到。PIN 只回答一个问题——这是不是所有者？——仅此而已。
生成任何内容之前：核实渠道
不要从一条向你索要代码的消息开始。从你可以独立确认的支持渠道开始，然后从那里打开案例。
- 确认你确实有一个正在处理的支持案例，并知道它是如何开启的。如果不是你开启的，在你能通过其他方式确认之前，应将此请求视为未核实。
- 通过你控制的途径联系支持——即你已经在使用的支持入口——而不是通过意外消息中提供的链接或地址。
- 核实提问者身份。未经请求就索要 PIN，或催促你尽快回复的请求，是让你放慢脚步的理由，而不是照做的理由。
- 将对话保持在已核实的渠道中。应他人要求转移到新地址或新对话线程，会破坏你刚刚完成的核实。
没有哪条消息因为看起来正式就自动可信。核实步骤需要你自己完成，而正是这一步让 PIN 的使用变得安全。
生成 PIN
一旦你确信案例真实，请以所有者身份登录后自行生成 PIN。
所有者可以打开 Edit profile、Account，然后点击 Generate New PIN。来源
PIN 由你在自己的账号设置中创建。你不是从支持人员那里收到它，支持人员也无法替你生成。如果有人提出替你生成 PIN，这种矛盾值得注意。
了解有效期
Support PIN 在创建七天后过期，可在同一账号设置中查看。来源
过期是内置限制，不是建议。在支持对话真正需要时再生成 PIN，不要提前几天生成；如果不确定之前的 PIN 是否仍然有效，请查看同一设置页面。
支持人员可能会要求什么
GitLab 支持人员可以要求提供 Support PIN 以验证账号所有者身份。来源
注意这个请求的方向：支持人员询问，你提供，目的是验证你持有该账号。这是对身份的核查，而不是控制权的转移。
将 PIN 与其他一切分开
| 项目 | 它能做什么 | 在支持案例中如何处理 |
|---|---|---|
| 密码 | 登录账号 | 绝不要发送给支持人员，任何渠道都不行 |
| 恢复代码 | 可以恢复账号访问权限 | 保持私密；它不是支持验证令牌 |
| 公开用户 ID 或用户名 | 向任何人标识个人资料 | 可以提及，但本身不能证明任何事 |
| Support PIN | 让支持人员验证账号所有者 | 仅在已核实的支持对话中分享，且仅在有效期内 |
PIN 即使分享给了错误的一方，仍然属于泄露，尽管它的权限比密码小。在其仍然有效的这几天里，请将其视为敏感信息。
需要预先考虑的错误路径
- PIN 已过期。 在同一账号设置中生成新的 PIN，并在已核实的对话线程中继续。不要重复使用旧值，也不要将其粘贴到其他对话中。
- 请求来自意外消息。 停下来。通过你选择的渠道核实案例，并将原始消息视为未确认。
- 有人索要你的密码、恢复代码，或由他们生成的 PIN。 拒绝。这些都不属于合法的身份核查。
- 你不确定案例是否真实。 在不确定时不要发送 PIN。先解决渠道问题；PIN 可以等。
- 你已经在未核实的对话之外分享了 PIN。 返回账号设置，查看 PIN，并让它过期，而不是假设这次暴露无害。
简短检查清单
- 我确认了支持案例存在，并且知道它是如何开始的。
- 我通过自己选择的途径联系了支持，而不是意外消息中提供的途径。
- 我以账号所有者身份登录，并自行生成了 PIN。
- 我检查了 PIN 的创建时间，以及它是否仍在有效期内。
- 我只在已核实的对话中分享 PIN，并且没有发送密码或恢复代码。
- 我知道如果 PIN 在案例处理中途过期，我该怎么做。
如果联系方式本身存疑，下一步
只有在你信任对话之后，PIN 才有帮助。如果对方是通过社交媒体或私信联系你的，而你仍在判断此人是否真实，请先通过我们的指南解决渠道问题：核查虚假客户支持社交账号。一旦确认支持渠道，再回到 PIN 的问题上。
用户名搜索可以通过呈现使用相似用户名的公开个人资料来支持这类渠道核查，但匹配结果只是线索，不能证明账号背后是谁。决定仍然取决于已核实的支持途径，而不是一个看起来正确的个人资料。