Restic: 允许空密码

Restic 应该允许空密码。

你能详细说明你的用例是什么吗？ 为什么restic应该允许空密码？

这是一个设计决定。

它的确是。 但我很好奇你想达到什么目的。

一个相关的问题可能是#1018

我只是想在我的本地系统上临时备份一些目录，作为更改目录中文件时的快速安全网。 我不想记住密码，也不想每次想创建备份时都费心输入密码。 由于我只是使用a作为密码，与根本不使用密码相比，使用此密码并没有真正的安全优势。 因此，任何记住或输入无用密码的低开销都会使该工具变得不那么完美。

感谢您的解释。 我想保留这个检查，所以我现在关闭这个问题。 请随时添加更多评论。 谢谢！

不久前我们谈到这个时，你说会有一个讨论......
你能解释一下为什么你认为这个检查有用吗？ 存储库仍应加密，以便之后可以添加密码。

我认为此检查很有用，因为根据我的经验，大多数用户都希望设置密码。 接受空密码，甚至具有允许接受空密码的代码路径，可能会导致用户在没有适当加密的情况下意外将备份保存到远程位置。 可能发生这种情况的一种情况是环境变量RESTIC_PASSWORD未导出或意外设置为空字符串。

所以，在这种情况下，我觉得保护用户免受错误比消除必须设置密码的轻微不便要好:)

不过，有一些简单的解决方法：使用密码管理器，使用字符串test ，通过文件静态导出RESTIC_PASSWORD例如在/etc/profile.d ，使用您的目录的名称'正在保存（或存储库）作为密码...

请注意，访问存储库需要知道密码。
丢失密码意味着您的数据不可恢复地丢失。

如果我不想永远丢失我的数据，我该如何防止这种情况发生？

@LexSong使用密码管理器。

2018 年 7 月 3 日，星期二 09:56:56AM -0700，Chenfeng Bao 写道：

@LexSong使用密码管理器。

您建议如何备份密码管理器数据库？ 你
在这里建议使用带有数据库的密码管理器，而不需要
密码？ 哪个密码管理器不支持获取密码
密码来自？

密码管理是一个很大的话题，我不想在这个线程中涉及太多细节。 只是指出，如果做得好，密码不应该是一个令人头疼的问题。 网上有很多资源。

密码管理器的数据库应该已经被正确加密，所以你可以把它放在任何你喜欢的地方，而无需另一层加密。 还有许多基于云的密码管理器服务，因此您不必自己担心备份。

至于 restic 的支持，您可以将密码放在本地的纯文本文件中并使用--password-file选项。 那么你就不需要手动输入密码了。 密码本身也应该放在密码管理器中进行记录。

归根结底，您必须记住一个复杂的密码/密码，以确保事情真正安全。

实际上，如果您真的不想在 restic 存储库上设置密码，为什么不使用一个字符的虚拟密码呢？

使用“a”作为密码实际上是我的解决方法，但感觉不合适，因为我无法确定我是否记得在几年后出于某种原因再次看到此存储库时使用它，以防万一我忘记删除它我不再需要它了。 因此，我可能不得不实施某种蛮力来解决这个问题。 这是所有可以避免的工作。

过去，当我使用密码临时保护外部 HD 以使其以后更容易删除时，我已经在这种情况下使用了简单的临时密码。 但是我没有删除它，所以当我下次想使用它时，我想确保驱动器上没有任何重要的东西。 不幸的是，我的密码管理器中的密码不再起作用，因为我忘记从那里更新/删除它。 因此，当我想到我未来的自己时，通过不创建我无法解密的静态存储库来让他更轻松似乎是个好主意。

我有另一个想法，当没有密码访问存储库并返回到错误消息时，restic 会尝试使用“restic”作为默认密码如何？ 然后用户可以使用这个密码来表明他们不需要加密，而 restic 会在没有额外魔法的情况下打开它。

我同意之前的评论，以保持检查以防止用户错误。

由于已经说明的原因，Restic 需要支持空密码。 一世
特别不想加密我的本地备份，因为我不想
失去对它们的访问。 我不想冒险忘记密码和
无法恢复数据。 这是一个真正的风险，因为用户通常
恢复很少，并且经常运行无人值守的备份，他们不这样做
需要输入密码，更容易忘记。

将密码存储在文件或脚本中是一种容易出错的解决方法
不应该存在的问题。

我同意应注意防止意外上传
未加密的数据到远程存储库。

似乎一个简单的解决方案是有一个命令行选项，
--allow-empty-password 。 用户可以在他们的脚本中设置该开关并
默认情况下可能仍然需要密码。

这是一个真正的风险，因为用户通常很少进行恢复，并且经常运行无需输入密码的无人值守备份，因此更容易忘记密码。

此类备份密码不应被记住。 您需要记住的唯一复杂的加密密码是密码管理器的密码，您会经常使用它。 你_真的_应该使用密码管理器。

将密码存储在文件或脚本中是解决不应该存在的问题的一种容易出错的解决方法。

抱歉，我只是不明白这是一个如何容易出错的解决方法。 对我来说，这似乎是一种完全有效的自动加密方式。 再次使用密码管理器解决了该问题。

似乎一个简单的解决方案是使用命令行选项--allow-empty-password 。 用户可以在他们的脚本中设置该开关，默认设置可以保留为需要密码。

这似乎是避免用户错误的合理方法。 但是，仍然存在对增加的攻击面的担忧，需要非常小心地解决。

此类备份密码不应被记住。 您需要记住的唯一复杂的加密密码是密码管理器的密码，您会经常使用它。 你真的应该使用密码管理器。

密码管理器绝对不是解决此问题的有效方法。 进行备份的重点是备份您的文件，其中包括密码管理器的数据库！ 那么，当密码存储在加密备份集中时，您将如何恢复备份集的密码？

在设计备份系统时，您必须为最坏的情况做好计划，包括在除了备份之外没有任何可用内容时进行恢复。 您显然所做的是将您的密码管理器数据库与您的 Restic 备份您来说没问题，但您不能将该系统强加给其他用户。 说密码管理器是使用 Restic 所必需的是荒谬的，尤其是当它甚至没有被设计为与一个集成时。 如果是，请向我展示相关文档。

与许多软件一样，Restic 旨在使用户能够满足他们的需求。 您的需求不包括裸机、仅是您的 Restic 备份还原方案。 其他用户的需求做。 请不要将他人的需求强加于他们。

这似乎是避免用户错误的合理方法。 但是，仍然存在对增加的攻击面的担忧，需要非常小心地解决。

对于由提议的--allow-empty-password选项引起的攻击面增加，您有什么具体的担忧？

这似乎是避免用户错误的合理方法。 但是，仍然存在对增加的攻击面的担忧，需要非常小心地解决。

我的另一个想法是让 restic 在没有指定密码时使用默认密码来访问存储库，例如restic 。 那么创建新仓库的 UI 不会改变，只有当用户使用默认密码 restic 才能自动访问仓库，用户不需要记住密码。

抱歉，我只是不明白这是一个如何容易出错的解决方法。 对我来说，这似乎是一种完全有效的自动加密方式。 再次使用密码管理器解决了该问题。

只要没有与密码管理器集成，仍然存在密码管理器中的值错误、过时或意外删除的危险，因为密码管理器之外会有密码的副本。

我还希望看到一个允许空密码的选项（通过使用--allow-empty-password标志，或者更详细/独特的东西来突出风险，例如 NRPE 的--dont-blame-nrpe标志）。

我的用例：

• 业务：我们有一个包含在受信任环境中的存储库，我们需要“任何人”才能在紧急情况/灾难中恢复，而无需具备特殊知识（即存储库密码）。
• 主页：我想创建家庭照片等内容的静态备份。 这些都不是特别机密，在我英年早逝的情况下，我的家人需要能够以最小的阻力访问这些个人重要数据（例如，不必在保险箱中找到密码，这可能是过时的-日期或与另一个混合_）。

我理解需要密码来确保数据完整性和加密。 我看到keys目录中的文件似乎是一个 JSON 对象。 也许可以生成一个伪随机密钥（而不是没有密钥）并存储在那里？ 但是，这对出于性能原因而试图避免加密开销的用户没有帮助。

@fd0您如何看待建议的--allow-empty-password命令行选项？ 默认情况下它需要密码，但允许用户在必要时覆盖它。

请考虑重新打开这个问题。 许多用户的需求包括备份非机密文件，而不会因忘记或放错密码短语而失去访问权限。

这里是全新的 restic 用户——甚至还没有创建我的第一个存储库——但多年使用其他工具的经验——我最喜欢的是旧的“转储”。 尊重，这是一个明智的选择——当然应该允许空密码。 无论如何，添加一个标志以最大程度地减少无意错误的风险，但请不要将用例规定给明确指出其他需求的有经验的（潜在）用户。
为了安全起见，我要做的就是进行本地备份； 安全性不是问题，与需要备份相比，我丢失密码的可能性要大得多。 我讨厌密码管理器...

有密码要求使得自动备份变得困难，并且需要在 env 或脚本文件中提供密码首先会使整个安全问题变得毫无用处。

需要在 env 或脚本文件中提供密码首先会使整个安全问题变得毫无用处。

这不一定是真的。 有很好的方法可以做到这一点。

这不一定是真的。 有很好的方法可以做到这一点。

请不要在这里重复这个论点。 许多用户需要进行未加密或空密码备份。 如果你不是他们中的一员，那对你有好处。

@mholt ，有什么建议吗？ 我非常乐意在零干扰、最大安全性的情况下备份我的服务器。

许多用户需要进行未加密或空密码备份。

这通常是XY 问题。

@mholt ，有什么建议吗？ 我非常乐意在零干扰、最大安全性的情况下备份我的服务器。

这在很大程度上取决于您的具体情况、威胁模型、环境、可接受的风险以及技术和可用性目标。 所以不，我没有给任何人的一整套建议。

这通常是 XY 问题。

所以不，我没有给任何人的一整套建议。

这种居高临下的态度于事无补。 更糟糕的是，在告诉我们我们的需求是错误的之后，您拒绝提供任何建议。 这是一个 FOSS 项目，而不是 Apple, Inc.

例如，我既不需要也不想加密我已经未加密的数据的本地备份。 如果我的主磁盘出现故障并且我需要恢复我的备份，密码短语将与我的备份脚本和配置文件一起存储在备份存储库中。 我主要关心的是不要阻止其他人访问这些非敏感数据——我主要关心的是容易恢复并且不会被锁定在我的数据之外。

这是很多用户的通病，用户的需求不是你来决定的。

软件的存在是为了服务用户，而不是强迫用户默认它的要求。

感谢您解释您的用例，您再次担心。 为了记录，我认为它们是有效的，尤其是“丢失密码”一个。 我还认为像--allow-empty-password这样的restic init的特殊标志会起作用（我对极端情况有一些考虑，但我相信它们可以解决）。 因此，我将重新打开这个问题。

请注意，允许空密码将解决“丢失密码”的安全问题，但仍会像往常一样加密所有数据。

另一方面，我根本不喜欢这个线程的语气。 您可以自由地不使用 restic，这完全没问题。 我们大多数人在业余时间都在研究休息。 该线程中的一些评论非常有标题，解释为：“您必须实现此功能，有些用户需要它！”。 事实并非如此。 我们可以考虑并实施它，但我们也可以决定不做任何事情。

所以，请大家，即使您不同意，也让我们的讨论富有成效。 :)

@fd0 请原谅我不清楚。 我不要求或期望您或任何 Restic 开发人员。 这是你的项目和你的时间，你可以做任何你想做的事情。

我要问的是您是否考虑了此功能和用例。 如果您对自己实施它不感兴趣，那很好，我要求您将问题保持开放以便其他人可以讨论它，并且您考虑任何可能实施它的 PR。

我反对的是评论（不是你的），这些评论表明想要这个功能的用户不了解他们自己的需求，特别是当他们拒绝提出替代方案时。 那是粗鲁和无益的噪音。

对我来说，我正在使用带有 bup 特殊遥控器的 git-annex。 Annex 已经支持加密文件（我已经关闭了，以利用 bup 的重复数据删除功能）。 然后我将 bup 存储库（这只是一个花哨的 git 存储库）备份到远程服务器。 然后我可以删除 bup 存储库，因为它只是一个缓存，并根据需要通过 restic 进行恢复。

所以，基本上，我正在以 Unix Way(tm) 将一堆一次性工具拼接在一起，因为每个工具都做得很好。 Restic（我目前从口是心非的切换）不会滑动窗口块重复数据删除功能，在远程云，而这一切，我需要做的事。 加密和本地块重复数据删除发生在不同的层。 所以，我不想指定密码，也不想进行任何加密（这实际上节省了 CPU 使用）。

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

这只是我想要的一半，因为它仍在加密，但密码为空。 如果可以的话，我想恢复 CPU 使用率。

请注意，允许空密码将解决“丢失密码”的安全问题，但仍会像往常一样加密所有数据。

嗯，仍然使用空密码加密的动机是什么？

我的意思是，当在低功耗硬件上运行 restic 时，加密会增加一些明显的运行时开销。

编辑：好的， https: //github.com/restic/restic/issues/1018#issuecomment -307549863 - 特别是第二点回答了我的问题。

restic --password-file /dev/null -r s3:http://172.28.0.7:9000/bup2 init

此建议的主要问题是：它不起作用，restic 正在交互地要求输入密码，然后：

~# restic -r '/tmp/restic/' -p '/dev/null' init
enter password for new repository:

谢谢@fd0重新打开这个问题。 我同意@alphapapa 的观点，我的目的不是要强迫任何空闲时间的开发人员把时间花在他们不感兴趣的任何事情上。

我们只是不喜欢别人告诉我们我们不了解自己的需要。

在我看来，备份工具最重要的功能是在任何情况下都能进行恢复。 尽管安全具有非常非常高的重要性，但它取决于具体情况，数据安全（恢复能力）还是数据安全（防止未经授权的访问）具有更高的优先级。

当然，您可以自由决定仅针对安全性比安全性更重要的情况开发工具。

正如@mholt提到的“XY 问题”：请求是能够在没有任何知识的情况下进行灾难恢复，除了公共可用的通用静态文档，当然还有对存储库本身的访问权限。
“不知情”排除了密码管理器的需要或使用。

我发现这个问题的原因是：_我正在私下帮助一些人使用他们的电脑。 他们对密码的处理是一团糟，在 USB 驱动器上设置备份时试图教他们正确的密码处理只会导致根本不创建备份或在需要时无法使用密码。 当需要恢复时，他们可能会得到其他人的帮助，所以我想出的任何缓解这种情况的方法都可能无效。_

现在，我将密码保存在与 restic 备份存储库相同的 USB 驱动器上的文本文件中，这完全破坏了拥有密码的安全性。
我不喜欢这个解决方案，因为使用不提供任何额外安全层的密码会给安全带来非常错误的想象。

当然，我这里只讨论个人本地备份。 对于服务器，我建议将强密码复制到一些单独的离线存储中。

我认为这里的另一个问题是； 如果某些框架/API 允许空密码，而有些则不允许。 并且必须使用空密码解密由另一个 API 加密的输入。 这是目前我对https://github.com/RNCryptor/JNCryptor 的问题

所以，请大家，即使您不同意，也让我们的讨论富有成效。 :)

阅读此主题后，我发现对话富有成效，因为结果是积极的。

我想提醒大家，这是 Github——如果你对某件事有强烈的感觉而项目维护者不接受，请随意创建一个 fork——这实际上需要几秒钟。 如果您缺乏自己做出改变的技能，请让他人帮助您。 您会发现维护人员可以更愿意接受一个补丁，该补丁实现了他们自己不会有动力实现的东西。

就个人而言，在这种情况下，我认为将安全“应该”的先入之见强加于每个人是错误的。 数据安全的第一条规则是数据必须可供有权拥有数据的人访问。 任何会影响规则#1 的规则都应该谨慎考虑。

安全是一个充满 FUD 和恐惧驱动的政策的话题，导致了天真、草率且往往虚伪的实现，因为我们当中很少有人真正喜欢考虑所有可能出错的事情。 当我们被视为允许事情出错时，更不想面对他人的批评。

我们每天都会看到的一些常见错误：

1) 坚持写入到静态加密的媒体的数据本身必须加密，即使在受信任的环境中也是如此。 对拦截的恐惧在哪里结束？ 我们从哪里开始相信用户可能有能力，而添加冗余层只会增加数据丢失的风险？

2）坚持特定格式的密码，即8个字符，至少有一个大写字母、一个数字和一个非字母数字——这是20年来的普遍做法，现在已经被揭穿，因为痛苦超过收益。 相反，我们应该坚持使用像xkcdpassword这样令人难忘的高熵密码，或者与密码管理器集成（这有效地使所有关键消费者依赖于可以被鱼叉式网络钓鱼的共享安全 SPOF 主密码——只需询问 COMMODO）或集成 2FA（可能更好）取决于第二个因素的物理安全性，包括 N+1 密钥冗余）。

3) 使用主密码 - 未能将其缓存在会话中，以至于用户在一天中被迫多次输入它，以至于他们输入它的行为本身就成为一个明显的攻击媒介。

4) 使用主密码 - 没有检查策略并盲目查询主密码，以至于用户习惯于在实际不需要时提供它，导致他们停止批判性地分析是否应该提供它这个实例。

5) 将最低权限政策强制执行到用户讨厌它并避免选择加入的程度，或者找到解决它的方法，让大门敞开的时间比有更宽松的计划要长得多。

6) 在没有 N+1 冗余的情况下执行最小特权策略，也就是缺乏“业务连续性/“关键人员策略”考虑因素。 即，不是将共享资源锁定在 2 个私钥之后，以便只有在双方同意（法定人数为 2）时才能访问它，而是将其锁定在 3 个私钥中的任意 2 个之后。 没有人永远活着。

每当我们作为程序员实施单密钥加密方案时，我们都需要考虑可访问性的重要性，并听取那些痛苦地意识到单密钥加密方案丢失密钥后果的人的担忧。

让我们也尽量记住，纯粹因为害怕误用而从用户那里拿走东西，从根本上是错误的 - 就像几乎所有的决定都是出于恐惧。 因为某人可能做错事而惩罚每个人，这会削弱整个社会。

如果此刻你觉得你不同意这个概念，那么深吸一口气，数到十，然后考虑这个：当有人把头放进垃圾袋里自杀时，我们作为一个社会应该怎么做？喷奶油并吸入一整罐一氧化二氮？ 我们应该让每个人都远离喷雾奶油吗？ 塑料袋？ 呼吸？ 所有这些东西都可能以导致用户死亡的方式被滥用。

与其像孩子玩火柴那样下意识地想拿走东西，不如在教育人们正确使用这些东西方面犯错。 或者提高进入门槛，只有那些 RTFM 的人才能找到它。

这就是这里最后发生的事情，直到所有的问题和意见都已经表达出来，才决定接受这个结果。 我建议在公共电视台观看议会辩论会议，以了解无效辩论的例子，哈哈。 相比之下，这里的参与者都格外尊重对方。

记住旧的好的存档实用程序，其中加密和密码保护仅作为显式选项可用，但默认情况下不可用。 这是正确的逻辑，因为安全性可能有很多超出此实用程序范围的外部解决方案，并且因为这种关心取决于用户。 您所做的只是提供用户选择的那些安全工具。 但是作者更愿意照顾用户不要求的内容以防止滥用。

再次关于语气。 这在开源世界中很常见。 并且它得到了某种心理机制的支持。 作者不同意的批评被视为声称要打发他们的业余时间。 每次我们不得不提醒：我们不会在这里讨论您的业余时间，而是探索您的天才生物，它的功能以及背后的逻辑。 我们永远不会忘记，您没有义务满足我们的要求，您完全有权什么都不做。 但如果你喜欢你所做的，那可能（也许）是因为其他人喜欢它。 因此，您可能有兴趣满足至少大多数人的需求。

PS 所有这些都只是抽象的咆哮，并没有练习动作的意思。

关于不允许存储库密码的讨论，我从未理解一件事（假设上下文@fd0之前写过，数据仍将被加密）； 为什么那些“不想要”密码的人不直接使用“1234”之类的虚拟密码？ 如果您不关心密码，您可以只使用虚拟密码，那么在 Restic 中编写代码来删除密码有什么意义呢？ 这是一个环境变量或密码文件，如果您认为在运行 restic 时在命令行上输入它很麻烦。

@rawtaz这已在此线程的先前评论中得到解答。

只是让我说restic init -r foo --no-password可能是比restic init -r foo --allow-empty-password更好的标志名称，仅仅是因为前者更重要，而后者过于冗长。

我没有看到任何好的论据，为什么只使用虚拟密码不是一种完全可行的方法，而不是增加基于此主题的静态代码。 我见过有人说他们可能会忘记密码“a”。 虽然这可能是真的，但肯定有可能发明一个简单的虚拟密码并记住它，或者至少在需要时重新找出它。 但无论如何，标志也可以正常工作，我只是惊讶于这似乎是一个多么大的问题：D

嗯，这是一个例子。 一年前做了一个静态备份。 编写了一个
虚拟密码，从文件中读取。 没有记下密码
其他任何地方。 一年不使用那台机器后，我完全
忘记了过程和密码——浪费了一个小时试图
在最终找到（和逆向工程）之前猜测密码
剧本。 完全是我的错，但仍然 - 我不需要安全，
并且不想被迫记住一个虚拟密码。 如果我
没有访问原始文件的权限，我会被锁定。

TD

这不是把它复杂化的问题吗？ 最常见的密码之一是 1234。使用它，您就不必尝试在某处找到它（假设您不认为您使用了更复杂的密码），因为当您需要输入一个虚拟密码时，您知道它是1234.不过，我明白你的意思。

我还希望看到一个允许空密码的选项（通过使用--allow-empty-password标志，或者更详细/独特的东西来突出风险，例如 NRPE 的--dont-blame-nrpe标志）。

我的用例：

* **Business:** we have a repository contained in a trusted environment that we need "anyone" to be able restore from in an emergency/disaster without having to have special knowledge (ie, a repository password).

* **Home:** I would like to create a restic backup of things like family photos. These are not particularly confidential, and in the case of my untimely demise, my family need to be able to access this personally important data with minimum resistance (_for example, without having to find a passphrase in a safe, that's possibly out-of-date or mixed up with another_).

我理解需要密码来确保数据完整性和加密。 我看到keys目录中的文件似乎是一个 JSON 对象。 也许可以生成一个伪随机密钥（而不是没有密钥）并存储在那里？ 但是，这对出于性能原因而试图避免加密开销的用户没有帮助。

• 业务：我们有一个包含在受信任环境中的存储库，我们需要“任何人”才能在紧急情况/灾难中恢复，而无需具备特殊知识（即存储库密码）。

但是那些“任何人”已经需要特殊的知识/说明。 他们需要知道如何运行 restic 来恢复数据，包括使用哪个存储库和其他东西，然后在这些说明中包含一个虚拟密码会非常容易。 或者他们会使用脚本或类似的自动化来为他们进行恢复（在这种情况下，他们仍然需要知道/获取去哪里使用该工具的说明），在这种情况下，虚拟密码将由脚本处理. 无论您怎么看，虚拟密码都不是问题。 而且严重的是，如果每个人都突然忘记它，人们将可以简单地猜测1234或暴力破解它。 这不是问题:P

• 主页：我想创建家庭照片等内容的静态备份。 这些都不是特别机密，在我英年早逝的情况下，我的家人需要能够以最小的阻力访问这些个人重要数据（例如，不必在保险箱中找到密码，这可能是过时的-日期或与另一个混合_）。

等等，什么？ 你到底为什么想要没有密码，如果不可能（目前至少）使用一个超级简单的虚拟密码（例如 1234），然后把这个超级简单的虚拟密码放在保险箱里？ 那将是完全没有意义的。 把它放在其他地方，为了它的价值，你可能已经有了一大堆其他信息，你的家人在你去世时需要知道这些信息，所以只需将你的虚拟密码放在一起。

最后，虚拟密码应该简单明了，不会过时，而且不需要多个虚拟密码。 所以它不应该过时或与另一个混合。

是的，这些建议已经提出，所以我们现在在循环。 就我个人而言，它们不是我对我的环境和用例感到满意的合适解决方案。

你不需要这个功能，没关系。 这并不意味着其他所有人的用例都是无效的。 我没有使用 Amazon S3 后端，但我没有声明它不需要，我只是不使用它。 如果实现了此功能，则不使用它不会产生任何费用。

是的，这些建议已经提出，所以我们现在在循环。

是的，老实说，我还没有看到对为什么虚拟密码如此难以处理的实际解释，我觉得我看到的大多是它过于复杂。

就我个人而言，它们不是我对我的环境和用例感到满意的合适解决方案。

这是我完全尊重的。 每个人的用例都是个人的，您有自己的工作流程:)

我想在某个时候我们会得到一个--no-password或类似的，希望这也能解决这个用例。 感谢您的输入！

劳塔兹写道

只是让我说restic init -r foo --no-password可能是比restic init -r foo --allow-empty-password更好的标志名称，仅仅是因为前者更重要，而后者过于冗长。

我没有看到任何好的论据，为什么只使用虚拟密码不是一种完全可行的方法，而不是增加基于此主题的静态代码。 我见过有人说他们可能会忘记密码“a”。 虽然这可能是真的，但肯定有可能发明一个简单的虚拟密码并记住它，或者至少在需要时重新找出它。 但无论如何，标志也可以正常工作，我只是惊讶于这似乎是一个多么大的问题：D

我不关心虚拟密码的使用/处理 - 相反，我有时担心 CPU 使用在低端硬件上运行时通过强制加密减慢备份过程。

解决#1018（未加密的备份）也可以解决这个问题——即使用--unencrypted开关代替--no-password开关。

我实际上在 CPU 绝对没有 AES-NI（或类似的扩展）并且备份受 CPU 限制的低端硬件上使用了 restic。 在另一种情况下，CPU 更强大一些，但唯一可用的外部硬盘驱动器已经被 LUKS 加密，因此它受 CPU 限制，因为它不够强大，无法并行处理两个加密过程。

另见： https :

如果您忘记了如何使用 restic，您可以阅读文档。 如果您忘记了存储库位置，您可以找到它。 或者你可以偶然遇到孤儿存储库，想知道里面有什么备份。 但是，如果您忘记了密码，您将永远失去您的数据。 而在现实生活中，您可以忘记任何最简单的虚拟密码。 你可以忘记你不经常使用的一切。

如果您丢失 root 密码您可以使用 init=/bin/bash 选项启动并获得完全访问权限。 虽然这个洞可以关闭，但它仍然存在于大多数系统中。 为什么？ 因为在这些情况下，不可用造成的损失不仅仅是不安全造成的。 因此，这是安全性和可用性之间的权衡。 对于具有更高要求的系统，存在特殊的解决方案，如冗余密钥，提供安全性和可用性。

resitc 不是安全工具。 它是一个备份工具。 因此，它应该首先提供备份功能本身，然后才是安全性。 所以密码保护和加密只能作为选项提供，默认情况下不应该到位。

顺便说一句：默认值是软件质量的标志。

@vstavrinov在说它不是安全工具之前，请先阅读对 restic 的介绍。 它是一种备份工具，其主要功能之一是尝试使您的备份安全。 因此，当您说它不关心安全性时，您就差得很远了。

但是，如果您忘记了密码，您将永远失去您的数据。

是的，这就是为什么您（在这种情况下有一个简单的选择）使用虚拟密码，这样即使您忘记了密码，您也始终能够知道密码。

而在现实生活中，您可以忘记任何最简单的虚拟密码。

如果你这样做，你选择了一个太复杂的虚拟密码，它不再是一个简单的虚拟密码。

坦率地说，整个讨论变得非常可笑。 我不敢相信人们会说像 1234 这样的密码，这是最常见和最明显的密码之一，他们可能会忘记，然后无法真正快速找出密码（例如，只需尝试一些明显的虚拟密码）密码）。 我想说的是，当您处于这种情况时，您必须非常努力地尝试无法“猜测”1234，即使如此，您也很可能无法不猜测它。

但是，如果您忘记了密码，您将永远失去您的数据。

维基百科可能会帮助您：只需尝试https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List 中最常用的密码

可能发生这种情况的一种情况是环境变量 RESTIC_PASSWORD 未导出或意外设置为空字符串。

代码可以检查密码是明确设置为空字符串还是未设置（未指定命令行选项，未设置环境变量 -> 与空字符串不同）。

我认为应该让用户选择想要选择的密码。

解决 #1018（未加密的备份）也将解决此问题 - 即使用 --unencrypted 开关而不是 --no-password 开关。

加密仍然是强制性的，以防止托管提供商的二进制搜索独立于格式、使用 MITM 通过未加密通道传输等。 虽然这确实为您提供了与空密码对有针对性的攻击（零）一样多的保护，但它仍然避免了非针对性攻击的附带损害。

@rawtaz

它是一种备份工具，其主要功能之一是尝试使您的备份安全。 因此，当您说它不关心安全性时，您就差得很远了。

不远了。 指出我说“它不关心安全”的地方。 我不。 你说同样的话：“这是一个备份工具”。 备份不安全吧？ 所以restic不是一个安全工具。 和“......主要特征之一......”。 你又是对的：这是一个功能。 即安全是一个特性，而备份是一个功能（目标）名称。

@rawtaz

坦率地说，整个讨论变得非常可笑。 我不敢相信人们会说像 1234 这样的密码......

我无能为力，但在这种情况下你也是对的。 愚蠢的是讨论虚拟密码。 但我认为更重要的是理解密码保护和加密应该是可选的。 以及不要强加给用户额外不需要的功能，让他们选择使用或不使用它。 这也是软件质量的标志。

但我认为更重要的是理解密码保护和加密应该是可选的。

为什么？ 为什么“应该”备份工具没有默认加密？ 仅仅因为它是一个“备份”工具？ 你只是这么说，但没有任何理由。

没有任何设计决定可以取悦所有人。 Restic _选择_高度重视安全性，像我这样的用户_喜欢_强加密是默认设置。

• 如果您不关心安全性，则_不能_滥用默认安全的系统。 最坏的情况是，您会看到一些错误，然后使用调整后的命令重试。
• 如果您关心安全性，有很多方法可以滥用不安全的默认系统来造成灾难性后果。 一个丢失的标志，你的敏感数据被泄露，也许_不可逆转地_。

要求一个可以省略密码的标志是一回事，但是对于所有依赖 restic 加密的现有用户来说，默认情况下不加密是一个危险的“骗你”。 发生灾难性用户错误的可能性是巨大的。

@cfbao

但我认为更重要的是理解密码保护和加密应该是可选的。

为什么？ 为什么“应该”备份工具没有默认加密？ 仅仅因为它是一个“备份”工具？ 你只是这么说，但没有任何理由。

“可选”与“默认”不同。 这样的默认值可能是有争议的。 但有选择更重要。 虽然我们别无选择，但与默认值无关。 这才是重点。 首先提供选项，然后讨论默认值才有意义。

在这种情况下（问题）它非常简单 - 可能会有一个--no-password或类似的标志到restic init （默认情况下仍然是 restic 在初始化时请求密码），但这只是我对@fd0的最后回复的看法。 目前还没有预计到达时间，无需询问:)

同时，使用虚拟密码 :) 我猜想正确的实现包括删除/取消设置以前用于初始化存储库的密码/密钥的能力，因此不必重新创建整个存储库。

然而，加密是另一回事，并在其他问题中进行跟踪。

我不太关心无密码选项，但您在争论默认无加密：

所以密码保护和加密只能作为选项提供，默认情况下不应该到位。

顺便说一句：默认值是软件质量的标志。

我觉得很危险。

虽然我大体上同意@rawtaz的观点，但如果讨论严格是关于无密码选项（不更改默认值），我并没有太大的

@cfbao

我不太关心无密码选项，但您在争论默认无加密：

所以密码保护和加密只能作为选项提供，默认情况下不应该到位。

您甚至可以在此引用中看到“选项”在前，“默认”在下。 这又是重点。

在这种情况下（问题）它非常简单 - 可能会有一个--no-password或类似的标志到restic init （默认情况下仍然是 restic 在初始化时请求密码），但这只是我对@fd0的最后回复的看法。 目前还没有预计到达时间，无需询问:)

同时，使用虚拟密码 :) 我猜想正确的实现包括删除/取消设置以前用于初始化存储库的密码/密钥的能力，因此不必重新创建整个存储库。

一个可能更简单的解决方案是让 restic 支持一个虚拟密码，如果用户没有指定密码，它将尝试打开现有的存储库。

关于处理虚拟密码：没有明确的最佳虚拟密码适用于所有人。 1234 是一个烦人的虚拟密码，因为它需要四个手指向上移动和输入。 例如，“asdf”的输入速度要快得多。 此外，某些服务会限制密码选择，因此可能无法仅使用数字或仅使用四位数字。 因此，restic 内部的解决方案将是最用户友好的。 然后用户只需输入一次虚拟密码。

从设计安全的角度来看，提供任何类型的虚拟密码都是一个坏主意。

如果有人真的想绕过加密或不需要加密，只需提供一致的密码即可。 您不必键入它，您可以编写一个脚本来将静态代码和硬代码包装在那里。 真的，这比提供存储库地址或其他配置选项更重要吗？

让 restic 尝试一组假的或虚拟的硬编码密码只是自找麻烦。 如果某个可怜的人碰巧选择了您提议的“魔法”密码之一怎么办？ 我们是否警告他们不要选择我们特殊的虚拟、伪造的加密密码？ “不，泰德，你不能选择 SPACECHICKEN 作为你的仓库密码，它是 _special_。” ;)

我很好地为用户提供了一个选项来用（“--no-repository-password”）来射击自己，但我认为 restic 不应该比这更进一步来安抚一小部分用户渴望降低安全性。

从设计安全的角度来看，提供任何类型的虚拟密码都是一个坏主意。

为什么比不允许密码更糟糕？

如果有人真的想绕过加密或不需要加密，只需提供一致的密码即可。 您不必键入它，您可以编写一个脚本来将静态代码和硬代码包装在那里。 真的，这比提供存储库地址或其他配置选项更重要吗？

是的，这是更多的工作。 Restic 将是备份解决方案，其输出是存储库。 因此，理想情况下，存储库将包含恢复备份的所有内容。 但是，当使用硬编码虚拟密码的包装脚本时，意味着该脚本需要由其他东西备份，否则存储库将毫无用处。

让 restic 尝试一组假的或虚拟的硬编码密码只是自找麻烦。 如果某个可怜的人碰巧选择了您提议的“魔法”密码之一怎么办？ 我们是否警告他们不要选择我们特殊的虚拟、伪造的加密密码？ “不，泰德，你不能选择 SPACECHICKEN 作为你的仓库密码，它是 _special_。” ;)

究竟是什么问题？ Ted 仍然可以选择这个密码。 这只是意味着如果他们不指定它，restic 将方便地使用它。 Restic 仍然会像不是特殊密码一样加密/解密存储库。

我很好地为用户提供了一个选项来用（“--no-repository-password”）来射击自己，但我认为 restic 不应该比这更进一步来安抚一小部分用户渴望降低安全性。

称其为“用脚射击自己”是不必要的判断，也不意味着安全性降低。 针对勒索软件的可用性和弹性应该是安全概念的一部分。 由于无法访问加密密码而无法恢复备份会降低安全性。 在这里，将备份安全地存储到仅附加存储系统不会降低安全级别。

Why is it worse than allowing no password?

我不确定我将如何说服某人硬编码、隐藏、秘密尝试存储库密码将是一个坏主意。 如果您认为它们是，那么可能没有以安全为中心的论点可以说服您。

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

我选择了一个有趣的例子，也许我不应该这样做。 让我们假设您希望在解密失败时秘密自动尝试的虚拟密码是：“12345”。 一个天真的用户很可能会选择它作为他们的密码。 现在他们有一个他们认为是加密的存储库（并且有点加密），但 _anyones_ restic 可以解密。 此参数适用于您在硬编码集中选择的任何给定密码集。 这从根本上来说是糟糕的安全设计。

您提出的建议有一个术语。 它被称为加密后门 :) 在文档中隐藏该后门假设所有读者在使用 restic 之前都将完整阅读手册。 如果他们奇怪地希望这样做，让他们阅读文档以确定如何降低安全性，这不是满足更多人的需求吗？

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

如果您不认为静态加密是一项可靠的安全策略，并且会选择其他方式，那么您肯定是少数派。 这种不安全的默认设置对任何人都没有好处，在任何时候都应该劝阻。 在这种情况下，只需查看任何安全参考以获取建议。 我的观点不是有争议的——我是在争论行业标准做法。

即使您的仅附加存储介质的示例也将从静态加密中受益匪浅。 我强烈建议您阅读最近的一组 NIST、ISO 27002、NERC、IEC 62443 或任何全球公认的最佳实践指南标准。 我们不是在新的领域。

我还应该指出，我们实际上将这个线程中的两个问题混为一谈：密钥管理和加密。

也许这就是混淆的地方。

也许这个问题可以通过这样的文档来解决：

如果您不想使用密码保护您的存储库，只需使用字符串： password

这样就有了一种众所周知的方式来实现使用 restic 进行备份/恢复，而无需管理任何密钥。

Why is it worse than allowing no password?

我不确定我将如何说服某人硬编码、隐藏、秘密尝试存储库密码将是一个坏主意。 如果您认为它们是，那么可能没有以安全为中心的论点可以说服您。

我猜你在那里错过了一个“不”......

What exactly is the problem? Ted can still choose this password. It just means that restic conveniently will use it if they do not specify it. Restic would still encrypt/decrypt the repository the same way as if was not a special password.

我选择了一个有趣的例子，也许我不应该这样做。 让我们假设您希望在解密失败时秘密自动尝试的虚拟密码是：“12345”。 一个天真的用户很可能会选择它作为他们的密码。 现在他们有一个他们认为是加密的存储库（并且有点加密），但 _anyones_ restic 可以解密。 此参数适用于您在硬编码集中选择的任何给定密码集。 这从根本上来说是糟糕的安全设计。

我不建议在解密失败但未指定解密密码时尝试。 如果有人选择了一个不安全的密码，无论是直接被 restic 尝试还是被某人暴力破解密码，它都是不安全的。 “12345”现在也是一个不安全的密码，如果它成为restic的默认密码，它也不会改变。

您提出的建议有一个术语。 它被称为加密后门 :) 在文档中隐藏该后门假设所有读者在使用 restic 之前都将完整阅读手册。 如果他们奇怪地希望这样做，让他们阅读文档以确定如何降低安全性，这不是满足更多人的需求吗？

如果在加密数据时，除了用户提供的密码之外，restic 还使用了默认密码，则加密后门将是。 我的建议是在解密时尝试使用一个密码。 用户仍然会主动选择这个错误的密码。

Calling this "shoot themselves in the foot" is unnecessarily judgmental and also it does not imply reduced security. Availability and resilience against ransomware should be part of a security concept. The missing ability to restore a backup because of missing access to the encryption password would lessen the security. Storing the backup securely to an append-only storage system would not decrease the security level, here.

如果您不认为静态加密是一项可靠的安全策略，并且会选择其他方式，那么您肯定是少数派。 这种不安全的默认设置对任何人都没有好处，在任何时候都应该劝阻。 在这种情况下，只需查看任何安全参考以获取建议。 我的观点不是有争议的——我是在争论行业标准做法。

您认为不安全的默认设置是什么？

即使您的仅附加存储介质的示例也将从静态加密中受益匪浅。 我强烈建议您阅读最近的一组 NIST、ISO 27002、NERC、IEC 62443 或任何全球公认的最佳实践指南标准。 我们不是在新的领域。

At-rest-encryption 并不意味着 restic 需要这样做。 如有必要，仅附加存储仍然可以以其他方式加密。 尽管如此，仍然会有一些未加密的存储，即使它只是用于密码。 否则备份概念将依赖于一个总是记住密码的人。

退订此主题...

让我们就这样吧，很明显有些人想要init的--no-password选项，这就是这个问题的全部内容。 加密与否是一个单独的问题。

只是在这里快速评论：
我是一个不关心加密的用户。 我的数据没有任何敏感信息。 我确实关心那些不是我的人能够在 20-40 年内使用。 仅使用 rclone 是另一种较差的选择。

Restic 看起来是一个很好的工具，除了强制加密和密码意味着我需要考虑到这一点。 可能是备份存储库中的自述文件。 这是更多的工作，任何解决方案（从我这边）无论如何都会打败任何加密。

标记

感谢您的贡献，我想我们已经收集了足够的信息。