Lib.rs

› 命令行实用程序
#password #ui #upm

bin+lib tupm

终端通用密码管理器

由 David Simmons 和 2 位贡献者 编写

1 个不稳定版本

使用旧的Rust 2015

0.1.0 2017年7月21日

#2575 在 命令行实用程序

MIT/Apache

160KB
3K SLoC

终端通用密码管理器

终端通用密码管理器（tupm）是一个基于终端的界面，用于访问由通用密码管理器（UPM）项目生成的密码管理器数据库。这是一个概念验证练习，不应在生产环境中用于保护真实机密。

重要免责声明

  1. 此程序可能不安全或不可靠。 它可能会损坏您的密码数据库，暴露您的机密，并使您的谷物在牛奶中保持脆性。在考虑使用它之前，您绝对应该阅读下面的“风险”部分。请自行注意。
  2. 此代码是UPM的独立重新实现，与原始UPM程序及其作者没有任何关系，除了其读取和写入UPM数据库以及使用基于HTTP的UPM同步协议的能力。
  3. 此程序被编写为一个学习练习，以获得从“你好，世界”到“cargo publish”的Rust crate开发过程的经验。提供的库可以访问UPM数据库，可能对希望导入和导出的开发者有所帮助，但整个程序应被视为一个概念验证，而不是生产就绪软件。

Tupm使用MIT或Apache 2.0双重许可，与Rust本身相同。

屏幕截图

Screenshot

安装

可以通过Rust cargo命令下载并安装Tupm。

$ cargo install tupm

用法

Terminal Universal Password Manager 0.1.0
Provides a terminal interface to Universal Password Manager (UPM) databases.

USAGE:
    tupm [FLAGS] [OPTIONS]

FLAGS:
    -e, --export      Export database to a flat text file.
    -h, --help        Prints help information
    -p, --password    Prompt for a password.
    -V, --version     Prints version information

OPTIONS:
    -d, --database <FILE>    Specify the path to the database.
    -l, --download <URL>     Download a remote database.

在没有参数的情况下运行tupm将加载位于$HOME/.tupm/primary的数据库，如果不存在则创建一个新的数据库。可以使用--database选项指定不同的数据库路径。

或者，可以使用--download选项从现有的UPM同步存储库导入数据库。仅支持基于HTTP/HTTPS的存储库。不支持使用Dropbox的选项。应提供存储库URL（不附加数据库名称），默认情况下，名为“primary”的数据库将被下载并安装到$HOME/.tupm/primary，除非使用--database指定了不同的数据库路径。您将被提示输入HTTP用户名和密码凭据。

$ tupm --download https://example.edu/repo/
Downloading remote database "primary" from repository "https://example.edu/repo/".
Repository username: username
Repository password:
23708 bytes downloaded from repository.
Database written to: /home/username/.tupm/primary.

数据库加载完成后，您将看到一个用户界面，显示可导航的账户列表、所选账户的详细信息、一个过滤器框（可以通过按 / 快速访问），以及可以通过按 \ 或 escape 访问的选项菜单。大多数菜单选项都有快捷键用于直接调用。

对于特别勇敢的您，--export 命令行参数会将数据库内容的完整纯文本报告写入标准输出。（不用说，这种导出的数据根本不受加密保护，因此非常容易受到攻击。）

风险

我编写 Tupm 是作为一个 Rust 学习练习。我在其他开发者可能在使用 UPM 数据库时发现其代码有用的情况下，将其提供出来。然而，出于几个原因，我希望阻止任何人直接使用它来管理密码。

UPM 格式的加密问题

UPM 的工作可以追溯到 2005 年，其加密的使用在 2017 年的标准下可能被认为不太理想。我不是密码学家，但我对 UPM 格式中使用的加密有一些担忧。

  1. PKCS#12 密钥派生的使用。UPM 使用 PKCS#12 v1.0 密钥派生函数（KDF）从主密码派生密钥。最新的 PKCS#12 标准宣布这个 KDF “不推荐使用，并已弃用”并建议使用 PBKDF2 代替。（见：[RFC 7292 附录 B] (https://tools.ietf.org/html/rfc7292#appendix-B）。PKCS#12 KDF 似乎并不常用于保护实际的 PKCS#12 数据结构之外。我不知道是否存在任何已发现的特定弱点，但其弃用状态并不令人信服。
  2. KDF 迭代次数不足。PKCS#12 中指定的 KDF 等提供的效果与执行的迭代次数有关。1996 年的原始 PKCS#12 v1.0 文档使用了 1024 作为示例迭代次数，但后来被认为是不够的。迭代次数应该尽可能高，以增加暴力破解攻击的成本，同时不会对用户造成明显的延迟。我那功能不足的华硕 C201P ARM 架构 Chromebook 可以每秒执行 1.5 百万次 PKCS#12 KDF 迭代，因此迭代次数可以相当高。UPM 格式使用 20 的迭代次数。
  3. 未认证的存储。UPM 加密系统不提供任何加密文本的认证，因此攻击者理论上可以修改加密文本的一部分，导致损坏，从解析程序中获取意外的行为，或者甚至可能产生不同的但看似有效的解密明文。任何未来的格式修订都应该在加密后计算 MAC，并将其包含在数据库格式中，或者最好简单地使用 GCM 等认证加密模式。

内存中处理敏感材料

在 Tupm 运行期间，敏感材料（如主密码、派生密钥和存储的账户密码）在内存中以明文形式存储，几乎没有在它们不再需要时删除它们的措施。这对于一个概念验证演示来说是可行的，但对于一个生产密码管理器来说肯定是不好的。

为跨平台应用程序处理此类材料的最佳实践集将是一个伟大的研究项目，可能包括以下步骤：

  1. 零丢弃数据结构，避免编译器优化删除的可能性。Rust 缺乏不可移动类型也可能是一个问题。
  2. 每个平台特定的 OS 功能，例如 mlock()/munlock() 以防止敏感数据被交换到磁盘，以及 mprotect() 以防止此类数据随核心转储一起保存。
  3. 或许最终可以在支持的情况下，利用某些特定硬件的保护功能，例如英特尔软件保护扩展（SGX）。

除了Tupm程序本身的内存外，敏感信息还可能通过相邻程序泄露。例如，在终端中显示的密码可能仍保留在滚动缓冲区中，而复制到系统剪贴板的密码将保留在那里，直到被覆盖。

感谢

感谢Adrian Smith开发原始UPM程序，Alexandre Bury为提供基于终端的用户界面使用的Cursive库，以及Rust社区。

依赖项

约11–21MB
约308K SLoC