MeldID：从单一账户到数字访问管理系统

当我第一次了解MeldID时，主要把它看作是单一数字身份验证基础设施。用户创建一个账号，填写可管理的个人资料，然后可以在不同的应用中使用它——无需反复填写相同的表单进行登录和授权数据传输。

我曾预期后续的发展会集中在完善个人资料和连接的服务上。但项目很快开始从几乎不显眼的服务器基础设施转变为日常使用的访问管理工具。

下一步是为iPhone和Android推出的应用程序。在这里尤其令人 интересно的不是移动端客户端的出现本身，而是它整合的任务范围。

普通的TOTP——带来不同的用途

在应用中有一个一次性代码生成器，即TOTP，用于两因素认证中的动态数字。

这一标准不是自创的。用户添加账号后，会获得可以在第三方服务或网站中使用的代码。

大多数认证器的作用是在问“如何显示六位数字的代码？”时解决问题。而这里更广泛地处理：如何安全管理TOTP密钥的生命周期——从添加和存储，到在另一设备上的恢复和删除。

完全离线工作

乍一看，最大优势似乎只是本地代码生成。但在MeldID中，离线模式包含了更多内容。

已保存的记录依然可以离线使用。代码在手机端直接生成，因此临时没有网络也不会影响两因素验证。

新的TOTP记录也可以离线添加。它会在本地存储，并立即用于生成代码。当网络恢复后，添加的内容会自动上传到安全存储中，并同步到其他设备。

同步已存在的记录需连接到服务器。这确保不会在不同设备间出现不同版本的数据存储。

最终实现了平衡：核心操作不依赖网络；需要一致更新的变更在上线后同步完成。

换手机不意味着新一套代码

任何认证器都面临的最大困扰之一，是手机遗失、损坏或更换后。通常需要找备份码，手动迁移，或重新关联服务。

在此方案中，存储与你的MeldID账户关联，而非单一设备。登录新手机后，初始化安全存储，数据即可自动恢复。

无论原设备是Android还是iPhone，或是新设备不一样，都可以多台设备绑定，无需为每个平台创设不同的迁移流程。

假设旅行中手机意外损坏。用户只需在新设备上登录MeldID，即可重建访问权限，恢复存储中的记录。之后，他的TOTP记录会自动返回到应用中。

一台手机可以绑定多个不同的MeldID账户。它们的存储相互隔离：一个账户的记录不会与另一个混淆，也不会在未授权的情况下出现于设备上。

服务器上存放了什么

自动恢复意味着数据必须存储在某个地方。然而，TOTP密钥不会以明文存储在数据库中。

记录内容被存储在加密容器中。当前架构采用带验证的AES-256-GCM加密，加密密钥与数据库本身隔离保护。

因此，数据库泄露不会提供用于生成代码的明文秘密。一旦被攻击者获得，只能得到加密的数据块，而无法获取开放的TOTP密钥。

这里需要强调，不要盲目许诺：明文的TOTP秘密不存于数据库中，而单纯的数据库副本不足以用于秘密的生成。

通过MeldID确认登录

另一个重要功能是Login Approval，即登录确认机制。

如果网站或应用支持MeldID，用户可以一步操作使用自己的账户进行登录。当开启保护时，单凭成功验证是不够的：登录只有在受信任的移动设备确认后才算完成。

请求可以由用户认可（如果确实是本人操作），也可以拒绝（如果操作异常）。

与普通的push确认不同，Login Approval直接内置于MeldID架构，兼容所有接入该系统的服务。

这里的push仅作为通知，注明新操作，但不包含密码、TOTP代码、令牌或其他任何可用于验证的敏感信息。

TOTP与Login Approval的互补

TOTP依旧是通用标准，即使在不支持MeldID的服务中也能使用。记录加载后，代码在本地生成。

Login Approval则在通过MeldID进行登录的场合使用。它增加了用户的确认步骤，可以在会话创建前阻止不正常的登录。

这意味着，应用既可以作为外部网站的普通身份验证器，也可以成为连接系统的登录确认工具。

MeldID自身发生了哪些变化

我第一次了解这项目时，主要认为它是管理单一账户和可迁移个人资料的工具。如今，显然MeldID正逐步转变为个人数字访问控制中心。

可以实现以下功能：

• 无需互联网即可获得TOTP代码；

• 离线添加新记录；

• 自动在新设备上恢复；

• 多手机绑定；

• 在一台设备上管理多个账户；

• 确认或拒绝新登录请求。

因此，此应用的价值不在于单纯展示六位数代码，而在于：在换设备、断网情况下保证访问，避免数据丢失，并在新会话创建前提供最后的用户选择方案。

安全性不依赖单一手段，而是多方案结合：TOTP秘密不以明文存储，访问权限不永久绑定于一台设备，不同账户保持隔离，连接的服务只在用户确认后方才允许登录。