我花了最长的时间考虑使用
Javascript书签来为我访问的不同网站生成密码,以避免“到处都有类似密码”的问题,但仍然是可移植的.然而,在阅读
this paper后,我清楚地知道使用这种方法意味着单个恶意页面可能会损害我的整个安全性.

现在我正在思考以下解决方案：一个bookmarklet,它只能做一件事：在新页面中打开一个带有原始URL的URL(例如http://example.com/password_man.html?url=slashdot.org).位于example.com页面上的脚本将生成实际的密码.

有没有人看到这种方法有任何安全问题？虽然它不如原来那么方便,但据我所知,即使是恶意页面也只能看到它获得的密码,并且无法访问敏感信息,如主密码.我假设这是正确的吗？

更多说明：

>密码的生成将完全由客户端完成.上面示例中提到的“password_man.html”将包含类似于bookmarklet中已包含的javascript代码,它将包含一个输入字段,供您指定主密码
>“url”参数的解释也将在客户端完成.我正在考虑将此文件作为我的谷歌代码帐户(即密码_man.html的v1234)上的特定修订托管,这将保证我不会更改用户下方的页面
>此外,HTTP / HTTPS不是问题,因为所有处理都是由客户端浏览器完成的,所以没有数据被发送回服务器.您可能会争辩说,MITM攻击可能会修改页面,以便在您使用明文协议(如HTTP)的情况下,它会发回生成的密码(或该主题的主密码),但如果您已经有MITM情况还有其他攻击途径更容易做到(例如：从提交它的请求中窥探密码,或者窥探会话ID等)

更新：在搜索并思考问题之后,我得出结论,在同一页面中无法安全地完成此操作.即使bookmarklet只捕获域并打开一个新窗口(通过window.open),恶意站点也总是覆盖window.open,这样它就会打开一个实际捕获主密码的页面副本(基本上执行网络攻击).

最佳答案
supergenpass听起来与你提出的非常相似.

如果实现为bookmarklet的要求是可移植性,则存在现有的多平台密码管理器.例如,我使用Lastpass,它支持所有主流浏览器,也适用于Opera Mini,也有书签形式.