密钥管理
密钥管理是安全性中极其重要的一部分。不过需要注意的是，密钥管理的安全程度取决于平台。例如，能够访问本地 keystore/keychain 的移动应用通常会比 Web 浏览器安全得多。我们当前的客户端密钥管理主要运行在 Web 环境中。在这些限制条件下，我们已经在浏览器端采取了适当的安全措施。
临时 keypair 会被加密，并通过浏览器内数据库 IndexedDB 安全地存储在用户浏览器中。当用户发起操作，例如签名并发送交易时，会话令牌会使用这个临时 keypair 对交易签名。随后智能合约可以验证该交易，确认用户的钱包已经授权这个会话令牌。\
- 使用
web3.Keypair.generate()生成一个随机 keypair - 生成一个随机加密密钥
- 使用该加密密钥对生成的 keypair 进行加密
- 将加密后的密钥存储到 IndexedDB 中
安全模型
1. Session keys 类似于适配到 web3 场景中的 JWT Token 2. 这些密钥具备过期时间和作用范围 3. 一旦密钥过期，就不能再在目标程序中重复使用，必须重新生成新的会话令牌。 4. 它们也被设计为可撤销的，因此在最坏情况下如果出现问题，攻击面也会被限制在临时 keypair 及其中包含的资产范围内，也就是 0.01 SOL关于 IndexedDB 的说明
Web 浏览器是一个极具对抗性的环境，无论从 cookies、session 到浏览器扩展沙箱，单靠任何一种安全措施都不足以完全防御。 攻击者始终可能通过 XSS 或恶意扩展注入任意代码。这也是为什么我们不建议用户在浏览器钱包中存放大额资金，它更适合日常小额使用。这里必须明确一点：Session Keys 不是 burner wallet。 不过，今天大多数 web3 应用仍然运行在 Web 浏览器里，用户也主要通过浏览器与 dApp 交互。在当前约束下，我们必须围绕这些限制进行设计，并通过其他方式持续强化安全性。- 尽可能缩小临时签名者的能力范围，因为它们本身就高度依赖具体上下文和使用场景。
- 这和 web2 典型客户端-服务器架构中对 JWT 的处理方式很相似。
- 例如 Facebook、Twitter，甚至银行网站中的 session 或 JWT token 也可能面临类似问题。它们的做法是限制 token 可执行的操作范围，部署智能撤销机制，并在可疑活动中进一步引入 2FA。
- 我们采用了类似的模型来控制范围，并且也在开发智能撤销系统，一旦检测到超范围使用等恶意交易，就能尽快撤销受损 token。在资金损失方面的绝对最坏情况，是补充用于支付 gas 的那 0.01 SOL。
- 此外，开发者今天也可以通过将其与像 octane 这样的 gasless relay 结合使用，并把
topUp设为false来进一步规避风险。不过，我们目前还没有在 SDK 中提供无缝的一体化方式，但这已经在路线图上。