你的浏览器启动时，后台在做什么？一位安全研究员的发现，让这个问题变得不那么轻松。
研究员的发现：密码在内存里"裸奔"
网络安全研究员汤姆·约兰·索恩斯泰比塞特·勒宁（Tom Jøran Sønstebyseter Rønning）最近在X平台披露：微软Edge浏览器启动时，会把所有已保存的密码加载进内存——而且是明文状态。
更关键的是，即使用户整个会话期间都没访问需要密码的网站，这些凭证依然会被解密并驻留在内存中。
「如果攻击者获得了终端服务器的管理员权限，他们就能访问所有已登录用户进程的内存，」勒宁写道。
这意味着什么？一旦系统被攻破，攻击者无需破解、无需诱导用户操作，直接读取内存就能拿到全部密码。
对比测试：Chrome选择了另一条路
Edge基于谷歌开源的Chromium项目开发。但勒宁测试后发现，其他Chromium内核浏览器并不存在这个问题。
「Edge是我测试过的唯一这样行为的Chromium浏览器，」勒宁表示。「相比之下，Chrome采用的设计让攻击者很难通过简单读取进程内存来提取已保存密码。」
德国科技网站Heise Online复现了这一漏洞。该网站援引网络安全最佳实践指出：「密码应该只在需要使用时解密，并在使用后立即从内存中清除。」
Edge的做法显然违背了这一原则。
微软的回应："by design"
勒宁称，他在公开披露前已联系微软。据他所述，微软的回应是：Edge的这种行为属于"by design"（设计如此）。
这个回应本身比技术细节更值得玩味。
密码管理器的核心 trade-off 一直在便利性与安全性之间摆动。Edge选择启动时预加载全部密码，可能是为了优化用户体验——减少用户访问网站时的等待延迟。但代价是扩大了攻击面。
Chrome的延迟解密策略则偏向安全侧，每次需要时才解密特定密码，用时间换空间。
两种设计哲学，没有绝对的对错。但"by design"的回应回避了一个问题：用户是否知情？是否有选择权？
对普通用户意味着什么
如果你是Edge内置密码管理器的重度用户，这个发现至少值得一次风险评估。
攻击场景需要两个前提：一是攻击者已获得目标系统的管理员权限，二是目标使用了Edge的密码管理器。对于普通个人用户，这个组合概率不算高；但对于企业环境中的终端服务器、共享工作站，风险系数显著上升。
勒宁的建议很直接：担忧此问题的用户应考虑替代密码管理方案。
第三方密码管理器如1Password、Bitwarden通常采用更严格的内存管理策略，主密码验证后才解密特定条目，且支持自动锁定。硬件安全密钥则更进一步，私钥永不离开物理设备。
当然，迁移成本客观存在：导出导入、双因素认证重配置、跨设备同步习惯重建。安全从来不是免费的。
浏览器密码管理的信任困境
这件事暴露了一个结构性张力。
浏览器厂商有动力把密码管理做深：它是用户粘性的重要锚点，是生态闭环的关键节点。但浏览器本身又是攻击的高频目标——渲染引擎复杂、扩展生态开放、钓鱼页面直接 targeting。
把密码管理器嵌入这样一个攻击面巨大的程序，本质上是把鸡蛋放进了一个相对脆弱的篮子。
微软的"by design"回应，某种程度上也反映了大厂的产品惯性。Edge需要与Chrome竞争性能指标，启动速度、页面加载时间都是可量化的战场。安全设计的优劣很难被终端用户感知，直到出事。
Heise Online的测试和勒宁的公开披露，至少把这个问题从"不可见"变成了"可见"。
行业回响：等待微软的下一步
Mashable已就此事联系微软寻求更多信息。截至发稿，尚未收到回复。
技术社区的关注点正在从"这是什么"转向"接下来会怎样"。微软是否会调整设计？是否会提供可选的安全模式？抑或坚持现有路线并加强文档披露？
对于每天打开Edge的数亿用户，这个技术细节可能永远不会进入他们的认知范围。但密码管理器的信任基础，恰恰建立在这些看不见的工程决策之上。
当一位独立研究员的X帖子与一家科技巨头的"设计如此"形成对峙，谁该拥有最终解释权？
热门跟贴