
走进与逃离Arc:我的浏览器选择之路
作者回顾了自己从使用IE到Chrome、Edge,再到Arc浏览器的经历,强调Arc的创新设计和功能,但因性能问题决定寻找替代品,最终选择了Vivaldi浏览器,并通过配置还原Arc的部分体验。
本文介绍了个人密码管理方案,选择了开源的KeePass作为主要工具,强调了其便捷的多端同步、自动填充和安全性。作者分享了KeePass的配置过程、插件使用、自动填充优化以及移动端的配置,最后讨论了双因素认证和TOTP的管理方法,提供了实用的参考资料和使用体验的改进建议。
大约高中的时候我就接触了一些密码管理软件,如1Password这些,但最终由于上手还是有些难度(那个时候也没有心思折腾)而回归了传统的 passwords.txt 方案。
早些年(大概在大一暑假)的时候,我在偶然的一次多端密码同步需求下开始重新了解密码管理方案,最终选择了 Keepass 这一开源方案,当初潦草配置了一下 Keepass 满足了我的基本需求(密码存储+多端同步+自动填充),但仍有很多小bug或者其他让我用得不是很舒心的地方困扰我。
于是,在另一个契机下 于是,在另一个契机下 (指公司电脑里需要登录一个东西但是我用keepass生成的16位强密码记不住又不能粘贴密码这样一个非常麻烦的事情)(指公司电脑里需要登录一个东西但是我用keepass生成的16位强密码记不住又不能粘贴密码这样一个非常麻烦的事情),我开始在另一台电脑重新配置我的 Keepass,并借此机会改善我的Keepass解决方案。,我开始在另一台电脑重新配置我的 Keepass,并借此机会改善我的Keepass解决方案。
最初的情况是这样的,我开开心心的用我的OneDrive同步我心爱的Password.txt,并每日使用Ctrl+F寻找密码;但是,这并不是事情的全部,由于我并不是每次都能记住要在Password里记上一笔(特别是在网页里),但大部分Chromium浏览器又自带一个密码管理器,因此大部分网页密码就存在了浏览器里。
彼时我已经从Chrome投奔了Edge阵营 彼时我已经从Chrome投奔了Edge阵营 (现在又想投奔回来因为我的Edge太卡了)(现在又想投奔回来因为我的Edge太卡了),在Edge里也已经有了几百条密码记录,得益于微软账户的同步,我在手机和其他设备上也可以访问这些密码(浏览器中)。,在Edge里也已经有了几百条密码记录,得益于微软账户的同步,我在手机和其他设备上也可以访问这些密码(浏览器中)。
这时,有一天我突发奇想,想要大统一密码方案,比如我的QQ在网页上、在应用里、在各种地方,都应该可以使用同一个密码和同一个服务进行填充(是的,我最初的需求就是因为我不记得我电脑上重置QQ密码是存在哪个网页上了,然后就经常找不到密码)。
正好,我发现了Edge也提供了类似的填充服务(在手机中设置),但我发现它并不好用,比如经常找不到或者无法调出,也无法方便地管理密码。也对,毕竟它本职就是一个浏览器,这只是一个附加功能罢了。
遂放弃Edge,开始寻找其他解决方案。
首先我肯定先看了1Password,LastPass等方案,但它和别的方案(如BitWarden)一样有一个我不能接收的地方:贵。
首先对于我这种轻度需求的人来说,它没有免费订阅,而且订阅费都是刀乐,实在有点难顶。
所以,选择Keepass的原因其实是没钱,它是开源的,缺了什么功能也可以自定义,何乐而不为呢?遂一拍即合,开整!
最初的Keepass方案的参考资料已经不可考了 最初的Keepass方案的参考资料已经不可考了 ,我记得甚至有小红书的资料~~,我记得甚至有小红书的资料~~,这里我就简述一下方案思路和现状。,这里我就简述一下方案思路和现状。
由于我个人本来就是一个明文TXT存密码的人,生在这个地方也明白自己的隐私其实没什么好保护的,甚至都没什么人关心,只要保护好财产相关的隐私就可以了。因此,我对于互联网密码的安全性其实没有特别高的要求。
综上,我提出了以下几点需求,优先级依次递减:
最初的方案使用了官方的Keepass客户端,但是官方客户端UI比较简陋,功能也不完全,需要安装很多对应的插件才能满足需求。
采用了单密码认证数据库+OneDrive同步的方案,这方面不在赘述。
KeePass使用树状目录组织密码,树的层级间会继承父级的规则,如自动填充、模板等,因此只需要在根目录配置好自动填充规则,所有条目都会共享这个规则,当然你也可以对特定条目/层级作自定义规则。
在根目录处打开该层配置选项。
{USERNAME}{TAB}{PASSWORD}{DELAY 100}{ENTER}
(这里是一个模拟键盘输入的过程,意思是先输入USERNAME,按下TAB然后输入PASSWORD,最后等待100ms后按下回车),你也可以按照自己的喜好进行配置这是最重要的一步,毕竟自带的自动填充真的甚至不能说差强人意,连浏览器场景都不好应对。
首先是应用程序场景,我选择 AutoTypeSearch 插件来实现快捷键搜索Entry+选择后运行自动填充过程。
在浏览器场景下有以下几种方案可选:
Kee Vault的在线服务是商业服务(虽然起步是免费的),而连接本地Keepass是免费服务
Vault的使用非常简单,只需要三步:
而它的优点有:
没有模板的界面是这样的:
有模板的界面(配置好后)是这样的:
个人有一台Android设备和一台iPad OS设备,但主战场其实在Windows端,手机端基本只起到读取的作用,因此就简单配置了一下:
Android:KeePass4Android
iPadOS:奇密(FantasyPass)
这次在新电脑上重新配置Keepass,改进主要从以下几个方面入手:
在新的客户端上我选择使用 KeepassXC,其是一个Keepass的开源客户端,支持Windows、Mac和Linux主流发行版(也可以自己编译)。
它最大的优点就是界面好看,且开箱即用。它虽然没有KeePass那么丰富的插件,但好处就是插件有的功能它自己都已经覆盖了,包括:
使用它甚至都不需要教程,直接上手即可。
在个人习惯方面,我对其作了如下设置,尤其是最小化那一块非常重要(经常手滑关掉导致浏览器连不上)
除了客户端换用了更现代的 KeepassDX 外没有什么改变。
BitWarden有内建的单条目对应多URL方案,但KeePass并不支持。我简单搜索了一下有以下几种解决方案:
2FA(双因素认证,2-Factor Authentication)是一种安全认证方案。
一般有三种因素可以作为认证一个人身份的凭据,如果用到了其中两种就是2FA:
生活中常见的2FA有银行卡(银行卡+密码),网上支付(U盾+密码)等。但在手机普及的现代社会,手机就成为了2FA中除密码外个人物品中重要的一个认证物件。常见的实验方案有短信认证、发送认证通知等
但短信可以被伪基站等劫持,因此有一定的安全风险,这里就需要引入更安全的TOTP算法。
TOTP 的全称是"基于时间的一次性密码"(Time-based One-time Password)。它是公认的可靠解决方案,已经写入国际标准 RFC6238。
TOTP的认证过程其实相当简单:
注意,密钥必须跟手机绑定。一旦用户更换手机,就必须生成全新的密钥
那么它的代码实现是不是也一样简单呢?答案是,是的。
TC = floor((unixtime(now) − unixtime(T0)) / TS) # TS: 有效时长,默认30s T0: 起始时间戳,默认为0
TOTP = HASH(SecretKey, TC) # HASH 为约定的哈希函数,默认是 SHA-1
了解了上述原理后相信大家也就知道了,不必绑定某一家的Authenticator,直接使用KeePass或某些软件就能管理基于TOTP的2FA;而能集成到KeePass中统一管理自然是最好的。
在 KeePassXC 中可以 直接右键条目(或者菜单中的编辑条目)-> 添加TOTP -> 将SecretKey(二维码的值)复制进来 就将TOTP导入到了对应条目中。
在设置成功后就可以在条目旁边看到一个时钟小图标,在下方条目预览中也可以直接看到TOTP的值。
在官方KeePass客户端中可能需要借助第三方插件如KeeTOTP来实现。
作者: ChlorineC
创建于: 2023-05-23 15:35:00
更新于: 2025-02-12 15:41:00
版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。
作者回顾了自己从使用IE到Chrome、Edge,再到Arc浏览器的经历,强调Arc的创新设计和功能,但因性能问题决定寻找替代品,最终选择了Vivaldi浏览器,并通过配置还原Arc的部分体验。
本文记录了重新构建Python编程环境的过程,主要包括从零开始构建面向PyQt5的环境和整理混乱的Python环境。使用miniconda管理多个Python环境,强调了conda的包管理和虚拟环境管理功能,介绍了mamba作为conda的替代品以提高依赖解析和下载速度,并详细说明了安装CUDA和PyTorch的步骤。
本文探讨了在React中使用react-use-websocket库来实现WebSocket功能的最佳实践,包括如何封装WebSocket逻辑、处理连接状态、发送和接收消息,以及使用ArrayBuffer传输文件。此外,文中还介绍了Socket.IO的工作原理及其与WebSocket的区别,提供了Node.js后端服务器的示例代码,展示了如何实现低延迟的双向通信和进度反馈。
本文探讨了软件架构中的微服务和微前端概念,强调了微服务作为SOA架构的细化,解决了系统复杂性和效率问题。微前端则将微服务的思想应用于前端开发,允许将前端应用拆分为独立的小模块,提升可维护性和灵活性。文章还讨论了微服务和微前端的实现方案、优缺点,以及在特定场景下是否需要采用微前端架构。