Restic: Разрешить пустые пароли

Restic должен разрешать пустые пароли.

Можете ли вы уточнить, каков ваш вариант использования? Почему restic должен разрешать пустые пароли?

это дизайнерское решение.

Это действительно так. Но мне любопытно, чего вы пытаетесь достичь.

Связанная проблема, возможно, # 1018

Я просто хотел временно сделать резервную копию некоторых каталогов в моей локальной системе в качестве быстрой подстраховки при изменении файлов в каталоге. Я не хотел запоминать парольную фразу или беспокоиться о том, чтобы вводить парольную фразу каждый раз, когда я хочу создать резервную копию. Поскольку я просто использовал a в качестве пароля, использование этого пароля не дает никаких реальных преимуществ в плане безопасности по сравнению с его отсутствием вообще. Поэтому любые незначительные накладные расходы на запоминание или ввод бесполезного пароля делают инструмент менее совершенным.

Спасибо за объяснение. Я бы хотел оставить эту проверку на месте, поэтому пока закрываю этот вопрос. Пожалуйста, не стесняйтесь добавлять дополнительные комментарии. Спасибо!

Когда мы недавно говорили об этом, вы сказали, что будет обсуждение ...
Не могли бы вы объяснить, почему считаете эту проверку полезной? Репозиторий по-прежнему должен быть зашифрован, чтобы впоследствии можно было добавить пароль.

Я считаю эту проверку полезной, потому что, по моему опыту, большинство пользователей захотят установить пароль. Принятие пустого пароля или даже наличие пути кода, который позволяет принимать пустые пароли, может привести к тому, что пользователи случайно сохранят свои резервные копии в удаленных местах без надлежащего шифрования. Одна из ситуаций, когда это может произойти, - это когда переменная окружения RESTIC_PASSWORD не экспортируется или случайно устанавливается на пустую строку.

Так что в данном случае мне кажется, что защита пользователей от ошибки лучше, чем устранение незначительных неудобств, связанных с необходимостью установки пароля :)

Однако есть простые обходные пути: используйте менеджер паролей, используйте строку test , экспортируйте RESTIC_PASSWORD статически через файл, например, в /etc/profile.d , используйте имя каталога, в котором вы сохраняем (или репозиторий) как пароль ...

Обратите внимание, что для доступа к репозиторию необходимо знать свой пароль.
Потеря пароля означает, что ваши данные будут безвозвратно утеряны.

Как я могу предотвратить это, если я не хочу потерять свои данные навсегда?

@LexSong Используйте менеджер паролей.

Во вторник, 3 июля 2018 г., в 09:56:56 -0700 Ченфэн Бао написал:

@LexSong Используйте менеджер паролей.

Как вы предлагаете сделать резервную копию базы данных менеджера паролей? Ты
предлагаю здесь использовать менеджер паролей с базой данных без
пароль? Какой менеджер паролей поддерживает ограниченную поддержку, чтобы получить
пароль от?

Управление паролями - это огромная тема, и я не хочу вдаваться в подробности в этой теме. Просто указываю, что, если все сделано правильно, пароли не должны быть головной болью. В Интернете есть множество ресурсов.

База данных менеджера паролей уже должна быть должным образом зашифрована, поэтому вы можете разместить ее где угодно без дополнительного уровня шифрования. Существует также множество облачных служб управления паролями, поэтому вам не нужно беспокоиться о резервном копировании самостоятельно.

Что касается поддержки restic, вы можете просто поместить пароль в текстовый файл локально и использовать опцию --password-file . Тогда вам не нужно вводить пароль вручную. Сам пароль тоже нужно поставить в диспетчер паролей для записи.

В конце концов, всегда есть один сложный пароль / кодовая фраза, которую вы должны запомнить, чтобы все было по-настоящему безопасно.

На самом деле, если вам действительно не нужен пароль в репозитории restic, почему бы просто не использовать фиктивный односимвольный пароль?

Использование 'a' в качестве пароля на самом деле было моим обходным путем, но я не считаю его правильным, поскольку я не могу быть уверен, что помню, как использовал это, когда я по какой-то причине снова вижу это репо через несколько лет, на случай, если я забуду удалить его, когда Мне это больше не нужно. Поэтому мне, возможно, придется применить какую-то грубую силу, чтобы понять это. Это вся работа, которой можно было бы избежать.

В прошлом я уже использовал простые временные пароли в ситуациях, которые оставляли меня в этом состоянии, когда я временно защищал внешний жесткий диск паролем, чтобы облегчить его последующее удаление. Однако я не стал его удалять, поэтому, когда я хотел использовать его в следующий раз, я хотел убедиться, что на диске нет ничего важного. К сожалению, пароль от моего менеджера паролей больше не работал, так как я забыл обновить / удалить его оттуда. Поэтому, когда я думаю о себе в будущем, мне кажется, что было бы неплохо облегчить ему задачу, не создавая восстановительных репсозиториев, которые я не могу расшифровать.

У меня есть другая идея, как насчет того, чтобы restic попытался использовать «restic» в качестве пароля по умолчанию, когда нет пароля для доступа к репозиторию, и вернуться к сообщению об ошибке, если он не работает? Затем пользователи могут использовать этот пароль, чтобы указать, что им не нужно шифрование, и restic откроет его без дополнительной магии.

Согласен с предыдущими комментариями, чтобы держать проверку на защиту от ошибок пользователей.

Restic должен поддерживать пустые пароли по уже указанным причинам. я
специально не хочу шифровать мои локальные резервные копии, потому что я не хочу
потерять к ним доступ. Я не хочу рисковать забыть пароль и
невозможно восстановить данные. Это реальный риск, потому что пользователи обычно
восстанавливать очень редко и часто запускать автоматические резервные копии, для которых они не
необходимо ввести пароль, что увеличивает вероятность того, что его забудут.

Сохранение пароля в файле или скрипте - это способ решения проблемы, связанной с ошибками.
проблема, которой не должно быть.

Я согласен с тем, чтобы не допустить случайной загрузки
незашифрованные данные для удаленных репозиториев.

Кажется, что простым решением было бы иметь параметр командной строки,
--allow-empty-password . Пользователи могли установить этот переключатель в своих скриптах и
по умолчанию может остаться требовать пароль.

Это реальный риск, потому что пользователи обычно очень редко восстанавливают данные и часто запускают автоматические резервные копии, для которых им не нужно вводить пароль, что увеличивает вероятность того, что его забудут.

Такие резервные пароли не предназначены для запоминания. Единственный сложный пароль для шифрования, который вам нужно запомнить, - это пароль вашего менеджера паролей, который вы будете часто использовать. И вам действительно_ следует использовать менеджер паролей.

Сохранение пароля в файле или скрипте - это способ решения проблемы, которая не должна существовать, и может привести к ошибкам.

Извините, я просто не понимаю, как это обходное решение подвержено ошибкам. Мне это кажется вполне допустимым способом автоматизации шифрования. Проблема решается, опять же, с помощью менеджера паролей.

Похоже, что простым решением было бы иметь параметр командной строки --allow-empty-password . Пользователи могут установить этот переключатель в своих сценариях, и по умолчанию может остаться запрос пароля.

Это действительно кажется разумным способом избежать ошибок пользователя. Тем не менее, все еще существуют опасения по поводу увеличения поверхности атаки, и к ним необходимо относиться с большой осторожностью.

Такие резервные пароли не предназначены для запоминания. Единственный сложный пароль для шифрования, который вам нужно запомнить, - это пароль вашего менеджера паролей, который вы будете часто использовать. И вам действительно стоит использовать менеджер паролей.

Диспетчер паролей - абсолютно не верное решение этой проблемы. Весь смысл создания резервных копий - это резервное копирование ваших файлов, включая базу данных менеджера паролей ! Как же тогда восстановить пароль к набору резервных копий, если пароль хранится внутри зашифрованного набора резервных копий?

При проектировании системы резервного копирования вы должны спланировать наихудший сценарий, который включает восстановление, когда у вас нет ничего доступного, кроме вашей резервной копии. Очевидно, что вы делаете резервную копию своей базы данных менеджера паролей отдельно от резервных копий Restic. Это нормально для вас , но не вам навязывать эту систему другим пользователям. И абсурдно утверждать, что для использования Restic необходим менеджер паролей, особенно если он даже не предназначен для интеграции с ним. Если да, то покажите мне документацию по этому поводу.

Restic, как и многие другие программы, предназначен для удовлетворения потребностей пользователей. Ваши потребности не включают в себя сценарий восстановления из резервной копии с голым железом и без ограничений. Подходят нужды других пользователей. Пожалуйста, не навязывайте им потребности других людей.

Это действительно кажется разумным способом избежать ошибок пользователя. Тем не менее, все еще существуют опасения по поводу увеличения поверхности атаки, и к ним необходимо относиться с большой осторожностью.

Какие конкретные проблемы вы видите в отношении увеличения поверхности атаки, вызванной предложенным вариантом --allow-empty-password ?

Это действительно кажется разумным способом избежать ошибок пользователя. Тем не менее, все еще существуют опасения по поводу увеличения поверхности атаки, и к ним необходимо относиться с большой осторожностью.

Другая моя идея заключалась в том, чтобы restic использовал пароль по умолчанию для доступа к репозиторию, когда пароль не был указан, например restic . Тогда пользовательский интерфейс для создания нового репозитория не изменится, и только когда пользователь использует пароль по умолчанию, restic автоматически получит доступ к репозиторию, и пользователю не нужно будет запоминать пароль.

Извините, я просто не понимаю, как это обходное решение подвержено ошибкам. Мне это кажется вполне допустимым способом автоматизации шифрования. Проблема решается, опять же, с помощью менеджера паролей.

Пока нет интеграции с диспетчером паролей, все еще существует опасность, что значение в диспетчере паролей неверно, устарело или случайно удалено, поскольку будет копия пароля вне диспетчера паролей.

Я также хотел бы увидеть возможность разрешить пустой пароль (с помощью флага --allow-empty-password или, возможно, чего-то более подробного / уникального, чтобы подчеркнуть риск, например, флаг NRPE --dont-blame-nrpe ).

Мои варианты использования:

• Бизнес: у нас есть репозиторий, содержащийся в доверенной среде, из которого нам нужен «любой», чтобы иметь возможность восстанавливать в случае чрезвычайной ситуации / бедствия, не обладая специальными знаниями (например, паролем репозитория).
• Главная: Я хотел бы создать резервную копию таких вещей, как семейные фотографии. Они не являются особо конфиденциальными, и в случае моей безвременной кончины моя семья должна иметь возможность получить доступ к этим лично важным данным с минимальным сопротивлением (_ например, без необходимости искать кодовую фразу в сейфе, которая, возможно, находится вне ... дату или перепутал с другим_).

Я понимаю, что для обеспечения целостности данных, а также для шифрования необходима кодовая фраза. Я вижу, что файлы в каталоге keys выглядят как объект JSON. Возможно, можно было бы сгенерировать псевдослучайный ключ (а не без ключа) и сохранить там? Однако это не помогает пользователям, которые пытаются избежать накладных расходов на шифрование по соображениям производительности.

@ fd0 Что вы думаете о предлагаемой опции командной строки --allow-empty-password ? По умолчанию для этого потребуются парольные фразы, но при необходимости пользователи смогут их переопределить.

И, пожалуйста, рассмотрите возможность повторного открытия этого вопроса. Потребности многих пользователей включают резервное копирование неконфиденциальных файлов без риска потери доступа из-за забытых или неверных парольных фраз.

Совершенно новый пользователь restic здесь - еще даже не создал свой первый репозиторий - но многолетний опыт работы с другими инструментами - мой любимый - старый добрый «дамп». С уважением, это простая задача - конечно, пустые пароли должны быть разрешены. Обязательно добавьте флаг, чтобы минимизировать риск непреднамеренной ошибки, но, пожалуйста, не навязывайте варианты использования опытным (потенциальным) пользователям, которые четко указали на другие потребности.
Все, что я пытаюсь сделать, это сделать локальные резервные копии в целях безопасности; безопасность не является проблемой, и у меня гораздо больше шансов потерять пароль, чем мне понадобится резервная копия. И я ненавижу менеджеры паролей ...

Требование пароля затрудняет автоматизацию резервного копирования, а необходимость предоставления пароля в env или файле сценария делает всю безопасность бесполезной.

необходимость предоставить пароль в env или файле сценария делает всю безопасность бесполезной.

Это не обязательно правда. Для этого есть хорошие способы.

Это не обязательно правда. Для этого есть хорошие способы.

Пожалуйста, не пересказывайте здесь этот аргумент. Многим пользователям необходимо создавать незашифрованные резервные копии или резервные копии с пустым паролем. Если вы не один из них, хорошо.

@mholt , какие-нибудь рекомендации? Я был бы более чем счастлив сделать резервную копию своих серверов с нулевым вмешательством и максимальной безопасностью.

Многим пользователям необходимо создавать незашифрованные резервные копии или резервные копии с пустым паролем.

Обычно это проблема XY .

@mholt , какие-нибудь рекомендации? Я был бы более чем счастлив сделать резервную копию своих серверов с нулевым вмешательством и максимальной безопасностью.

Это во многом зависит от вашей конкретной ситуации, модели угроз, среды, допустимых рисков, а также технических целей и целей удобства использования. Так что нет, у меня нет общего набора рекомендаций для кого бы то ни было.

Обычно это проблема XY.

Так что нет, у меня нет общего набора рекомендаций для кого бы то ни было.

Такое снисходительное отношение бесполезно. Гораздо хуже то, что, сказав нам, что наши потребности ошибочны, вы отказываетесь давать какие-либо советы. Это проект FOSS, а не Apple Inc.

Например, мне не нужно и не хочу шифровать локальные резервные копии моих уже незашифрованных данных. Если мой основной диск выходит из строя и мне нужно восстановить свои резервные копии, кодовая фраза сохраняется в репозитории резервных копий вместе с моими сценариями резервного копирования и файлами конфигурации. Моя основная забота - не препятствовать доступу других к этим неконфиденциальным данным - моя основная забота - простое восстановление и отсутствие блокировки моих данных.

Это распространенный случай для многих пользователей, и не вам решать, что им нужно.

Программное обеспечение существует для того, чтобы служить пользователям, а не для того, чтобы заставить их подчиняться его требованиям.

Спасибо за объяснение вашего варианта использования и вас снова беспокоит. Для протокола, я считаю, что они действительны, особенно «потерянный пароль». Я также думаю, что специальный флаг для restic init например --allow-empty-password будет работать (у меня есть некоторые соображения для угловых случаев, но я уверен, что они могут быть решены). Поэтому я снова открою этот вопрос.

Имейте в виду, что разрешение пустых паролей решит проблему безопасности «утерянного пароля», но при этом все данные будут зашифрованы как обычно.

С другой стороны, мне совсем не нравится тон в этой беседе. Вы можете не использовать рестик, это нормально. Большинство из нас в свободное время работают над отдыхом. Некоторые комментарии в этой ветке выглядят очень озаглавленными, перефразированными: «Вы должны реализовать эту функцию, есть пользователи, которым она нужна!». Это не так. Мы можем это рассмотреть и реализовать, но мы также можем решить ничего не делать.

Так что, пожалуйста, давайте продолжим эту дискуссию продуктивной, даже если вы не согласны. :)

@ fd0 Простите за непонятность. Я ничего не требую и не жду от вас или других разработчиков Restic. Это ваш проект и ваше время, и вы можете работать над тем, над чем хотите.

Я прошу вас рассмотреть эту функцию и вариант использования. Если вы не заинтересованы в реализации этого самостоятельно, это нормально, и я прошу вас оставить вопрос открытым, чтобы другие могли его обсудить, и что вы учитываете любые PR, которые могут его реализовать.

Я возражаю против комментариев (не ваших), которые предполагают, что пользователи, которым нужна эта функция, не понимают своих собственных потребностей, особенно когда за ними следует отказ предлагать альтернативы. Это грубый и бесполезный шум.

Для меня я использую git-application со специальным пультом bup. Приложение уже поддерживает шифрование файлов (которое я отключил, чтобы использовать функцию дедупликации bup). А затем я создаю резервную копию репозитория bup (который представляет собой просто причудливое репозиторий git) на удаленный сервер. Затем я могу удалить репозиторий bup, поскольку это всего лишь кеш, и при необходимости выполнить восстановление с помощью restic.

Так что, по сути, я сшиваю кучу одноразовых инструментов вместе в Unix Way (tm), поскольку каждый хорошо выполняет свою задачу. Restic (в настоящее время я перехожу с дублирования) выполняет дедупликацию блоков с скользящим окном в удаленное облако, и это все, что мне нужно. Шифрование и локальная дедупликация блоков происходят на другом уровне. Итак, я не хочу указывать пароль или какое-либо шифрование (которое фактически экономит использование процессора).

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

Это только половина того, что я хочу, так как он все еще шифруется, но с пустым паролем. Я бы хотел восстановить использование этого процессора, если бы мог.

Имейте в виду, что разрешение пустых паролей решит проблему безопасности «утерянного пароля», но при этом все данные будут зашифрованы как обычно.

Хм, какова мотивация для шифрования с пустым паролем?

Я имею в виду, что при запуске 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-Problem": запрос состоит в том, чтобы иметь возможность выполнить аварийное восстановление без каких-либо знаний, кроме общедоступной общей документации по restic и, конечно же, доступа к самому репозиторию.
«Без каких-либо знаний» исключает необходимость использования менеджеров паролей.

Причина, по которой я обнаружил эту проблему: _Я помогаю некоторым людям с их компьютерами наедине. Их обработка паролей - беспорядок, попытка научить их правильному обращению с паролями при создании резервной копии на USB-накопителях приведет только к тому, что резервные копии не будут создаваться вообще, или пароль недоступен, когда это необходимо. При необходимости восстановления они могут получить помощь от кого-то другого, поэтому все, что я придумал для смягчения ситуации, может быть недействительным.

Прямо сейчас я сохраняю пароль в текстовом файле на том же USB-накопителе, что и репозиторий restic backup, что полностью портит безопасность наличия пароля.
И мне не нравится это решение, поскольку использование пароля, не обеспечивающего дополнительного уровня безопасности, дает очень неправильное представление о безопасности.

Конечно, здесь я говорю только о личных локальных резервных копиях. Для серверов я рекомендую надежные пароли, скопированные в отдельное автономное хранилище.

Я думаю, здесь есть еще одна проблема; если некоторые фреймворки / API разрешают пустые пароли, а некоторые нет. И нужно расшифровать ввод, который был зашифрован другим API с пустым паролем. В настоящее время это моя проблема с https://github.com/RNCryptor/JNCryptor

Так что, пожалуйста, давайте продолжим эту дискуссию продуктивной, даже если вы не согласны. :)

Прочитав эту ветку, я считаю беседу продуктивной, потому что результат был положительным.

Я хотел бы напомнить всем, что это Github - если вы что-то сильно чувствуете, а разработчик проекта не восприимчив, не стесняйтесь делать форк - это буквально занимает секунды. Если вам не хватает навыков, чтобы изменить ситуацию самостоятельно, попросите других помочь вам. Вы обнаружите, что специалисты по сопровождению могут быть более открытыми для принятия патча, который реализует то, что они не были бы заинтересованы в реализации сами.

Лично я в данном случае считаю ошибкой навязывать каждому предвзятое мнение о том, какой должна быть безопасность. Первое правило безопасности данных заключается в том, что данные должны быть доступны для тех, кто имеет право на них. Любое правило, которое нарушает правило № 1, следует рассматривать с должной осторожностью.

Безопасность - это тема, которая полна FUD и основанных на страхе политик, приводящих к наивным, поспешным и часто лицемерным реализациям, потому что немногие из нас на самом деле любят думать обо всех вещах, которые могут пойти не так. Еще меньше хочется сталкиваться с критикой других, когда видят, что мы позволяем чему-то идти не так, как надо.

Некоторые типичные ошибки, которые мы видим каждый день:

1) Настаивая на том, что данные, записанные на носитель, который зашифрован в состоянии покоя, должны быть зашифрованы сами по себе, даже в надежной среде. Где заканчивается страх перед перехватом? Где мы можем начать верить, что пользователь потенциально может быть компетентным, и что добавление избыточных слоев просто увеличивает риск потери данных?

2) Настаивать на пароле определенного формата, т. Е. 8 символов, по крайней мере, с одной прописной буквой, одной цифрой и одной не буквенно-цифровой - это было обычной практикой в ​​течение 20 лет и теперь было опровергнуто, потому что боль превышает выигрыш. Вместо этого мы должны настаивать на запоминающихся паролях с высокой энтропией, таких как xkcdpassword , или интегрироваться с менеджером паролей (что фактически заставляет всех ключевых потребителей полагаться на общий пароль безопасности SPOF, который может быть задан - просто спросите COMMODO) или интегрировать 2FA (потенциально лучше в зависимости от физической безопасности второго фактора, включая избыточность ключа N + 1).

3) С мастер-паролем - неспособность кэшировать его в сеансе, так что пользователь вынужден вводить его столько раз в течение дня, что само действие по его вводу становится заметным вектором атаки.

4) С мастер-паролем - отказ от проверки политик и слепой запрос мастер-пароля, так что пользователь привыкает представлять его, когда он на самом деле не требуется, в результате чего они перестают критически анализировать, должны ли они предоставлять его в этот экземпляр.

5) Применение политики наименьших привилегий до такой степени, что пользователи возмущаются и избегают выбора, или находят способы обойти ее, оставляя дверь открытой намного дольше, чем если бы существовала более разрешительная схема.

6) Обеспечение политики наименьших привилегий без избыточности N + 1, иначе говоря, отсутствие соображений «непрерывности бизнеса» / «политики ключевого человека». т.е. вместо блокировки общего ресурса за двумя закрытыми ключами, чтобы к нему можно было получить доступ только тогда, когда оба согласны (кворум 2), заблокируйте его за любыми двумя из трех закрытых ключей. Никто не живет вечно.

Каждый раз, когда мы, программисты, реализуем схему шифрования с одним ключом, нам необходимо учитывать важность доступности и слышать опасения тех, кто до боли осознает последствия потери ключа для схемы шифрования с одним ключом.

Давайте также постараемся любезно помнить, что забирать что-то у пользователей исключительно из-за страха неправильного использования в корне неверно - как и почти все решения, принимаемые из-за страха. Наказание всех за то, что кто-то может сделать неправильный поступок, ослабляет общество в целом.

Если в этот момент вы чувствуете, что не согласны с этой концепцией, то сделайте глубокий вдох, сосчитайте до десяти, а затем подумайте вот о чем: что нам, как обществу, следует делать, когда кто-то совершает самоубийство, засунув голову в мешок для мусора с консервной банкой. спрей взбивать сливки и вдыхать всю банку закиси азота? Должны ли мы отнять у всех спрей для взбивания сливок? Пластиковые пакеты? Дыхание? Все это может быть использовано неправильно, что приведет к смерти пользователя.

Вместо коленного рефлекса убрать что-то, как это было бы с ребенком, играющим со спичками, мы должны вместо этого ошибиться, обучая людей правильно пользоваться этими вещами. Или поднимите планку входа так, чтобы ее нашли только те, кто RTFM.

Именно это и произошло в итоге, и решение принять этот результат не было принято до тех пор, пока все вопросы и мнения не были уже высказаны. Я рекомендую посмотреть сеансы парламентских дебатов на государственных телеканалах, чтобы увидеть, как звучат непродуктивные дебаты, лол. По сравнению с этим участники здесь относились друг к другу исключительно уважительно.

Вспомните старые добрые архивные утилиты, в которых шифрование и защита паролем были доступны только как явные параметры, но не по умолчанию. И это правильная логика, потому что безопасность может иметь множество внешних решений, выходящих за рамки этой служебной программы, и потому, что эта забота остается на усмотрении пользователя. Что вы делаете, так это просто предоставляете те инструменты безопасности, которые выбирают пользователи. Но автор предпочитает заботиться о том, о чем не просит пользователь, чтобы предотвратить злоупотребление.

И снова о тоне. Это обычное дело для мира открытого исходного кода. И это подкреплено каким-то психологическим механизмом. Критика, с которой авторы не согласны, рассматривается как требование потратить свободное время. И каждый раз мы должны напоминать: мы не обсуждаем здесь Ваше свободное время, вместо этого мы исследуем Ваше гениальное создание, его функции и логику, лежащую в основе этого. Мы никогда не забываем, что у вас нет обязательств по удовлетворению наших требований и вы имеете полное право вообще ничего не делать. Но если Тебе нравится то, что ты делаешь, это может быть (возможно) потому, что это нравится другим. Так что есть надежда, что Вы заинтересованы в удовлетворении спроса хотя бы большинства.

PS Все это просто абстрактная разглагольствования и никакие практические действия не имеют в виду.

Есть одна вещь, которую я никогда не понимал при обсуждении запрета пароля для репозитория (при условии, что контекст @ fd0 написал ранее, что данные все равно будут зашифрованы); Почему те, кто «не хочет» пароль, просто не используют фиктивный пароль, например, «1234» или что-то еще? Какой смысл писать код в restic, который удаляет пароль, если, если вам не нужен пароль, вы можете просто использовать фиктивный пароль? Это одна переменная среды или файл пароля, если вы считаете, что набирать его в командной строке при запуске restic неудобно.

@rawtaz На это уже был дан ответ в предыдущих комментариях к этой теме.

Просто позвольте мне сказать, что restic init -r foo --no-password , вероятно, более подходящее имя для флага, чем restic init -r foo --allow-empty-password , просто потому, что первое более уместно, а второе слишком многословно.

Я не вижу никаких веских аргументов, почему использование фиктивного пароля не является совершенно жизнеспособным способом сделать это вместо увеличения базы кода restic по этой теме. Я видел, как кто-то говорил, что может забыть пароль «а». Хотя это может быть правдой, безусловно, можно изобрести простой фиктивный пароль и запомнить его или, по крайней мере, при необходимости вычислить его заново. Но как бы там ни было, флаг тоже работает нормально, я просто поражен тем, насколько большой проблемой это кажется: 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 или аналогичный, надеюсь, это решит и этот вариант использования. Спасибо за ваш вклад!

Rawtaz написал

Просто позвольте мне сказать, что restic init -r foo --no-password , вероятно, более подходящее имя для флага, чем restic init -r foo --allow-empty-password , просто потому, что первое более уместно, а второе слишком многословно.

Я не вижу никаких веских аргументов, почему использование фиктивного пароля не является совершенно жизнеспособным способом сделать это вместо увеличения базы кода restic по этой теме. Я видел, как кто-то говорил, что может забыть пароль «а». Хотя это может быть правдой, безусловно, можно изобрести простой фиктивный пароль и запомнить его или, по крайней мере, при необходимости вычислить его заново. Но как бы там ни было, флаг тоже работает нормально, я просто поражен тем, насколько большой проблемой это кажется: D

Меня не беспокоит использование / обработка фиктивных паролей - вместо этого меня иногда беспокоит использование ЦП, замедляющее процесс резервного копирования из-за обязательного шифрования, когда оно выполняется на оборудовании более низкого уровня.

Решение # 1018 (Незашифрованные резервные копии) также решило бы эту проблему - ieeg с переключателем --unencrypted вместо переключателя --no-password .

Я фактически использовал restic на младшем оборудовании, где у ЦП определенно не было AES-NI (или аналогичного расширения) и где резервная копия была привязана к ЦП. В другом случае ЦП был немного мощнее, но единственный доступный внешний жесткий диск уже был зашифрован LUKS и, таким образом, был привязан к ЦП, потому что он не был достаточно мощным, чтобы обрабатывать два процесса шифрования параллельно.

См. Также: https://github.com/restic/restic/issues/1018#issuecomment -307549863

Если Вы забыли, как использовать 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 (Незашифрованные резервные копии) также решило бы эту проблему - ieeg с параметром --unencrypted вместо параметра --no-password.

Шифрование по-прежнему должно быть обязательным для защиты от двоичного поиска на хостинг-провайдере независимо от формата, передачи по незашифрованному каналу с помощью MITM и так далее. Хотя это дает вам такую ​​же защиту, как и пустой пароль для целевых атак (ноль), он все же позволяет избежать сопутствующего ущерба от нецелевых атак.

@rawtaz

Это инструмент резервного копирования, одной из основных функций которого является обеспечение безопасности ваших резервных копий. Итак, вы очень далеки от того, чтобы сказать, что он не заботится о безопасности.

Не за горами. Укажите мне, где я говорю: «Это не касается безопасности». Я не. Вы говорите то же самое: «Это инструмент резервного копирования». Резервное копирование - это не безопасность, верно? Так что restic - это не средство безопасности. И «... одна из основных черт ...». Вы снова правы: это особенность. т.е. безопасность - это характеристика, а резервное копирование - это функциональное (целевое) назначение.

@rawtaz

Честно говоря, вся эта дискуссия становится до смешного глупой. Не могу поверить, что люди говорят, что пароль вроде 1234 ...

Я ничего не могу сделать, но и в этом случае Вы правы. Что глупо, так это обсуждение фиктивного пароля. Но я думаю, что важнее понять, что защита паролем и шифрование должны быть необязательными. А также не навязывать пользователям лишние нежелательные функции, оставляя им выбор использовать или не использовать его. И это тоже показатель качества программного обеспечения.

Но я думаю, что важнее понять, что защита паролем и шифрование должны быть необязательными.

Почему? Почему в инструменте резервного копирования не должно быть шифрования по умолчанию? Просто потому, что это «резервный» инструмент? Вы просто говорите это, но для этого нет никаких причин.

Ни одно дизайнерское решение не может понравиться каждому. Restic _chooses_ уделяет большое внимание безопасности, и такие пользователи, как я, _любят_, что по умолчанию используется надежное шифрование.

• Если вы не заботитесь о безопасности, вы _не__ нельзя злоупотреблять системой безопасности по умолчанию. В худшем случае вы видите какие-то ошибки и повторите попытку с настроенной командой.
• Если вы заботитесь о безопасности, существует масса способов злоупотребить незащищенной по умолчанию системой до катастрофических последствий. Один флаг отсутствует, и ваши конфиденциальные данные утекают, возможно, _необратимо_.

Одно дело - попросить флаг, который может опускать пароль, но аргументы в пользу отсутствия шифрования по умолчанию - это опасный «дурак» для всех существующих пользователей, которые полагаются на шифрование restic. Потенциал катастрофических ошибок пользователя огромен.

@cfbao

Но я думаю, что важнее понять, что защита паролем и шифрование должны быть необязательными.

Почему? Почему в инструменте резервного копирования не должно быть шифрования по умолчанию? Просто потому, что это «резервный» инструмент? Вы просто говорите это, но для этого нет никаких причин.

«необязательный» - это не то же самое, что «по умолчанию». Значения по умолчанию как таковые могут быть спорными. Но важнее иметь варианты. Пока у нас нет выбора, значения по умолчанию тут не причем. В этом-то и дело. Сначала предоставьте параметры, а затем имеет смысл обсудить значения по умолчанию.

В этом случае (проблема) это довольно просто - скорее всего, будет --no-password или аналогичный флаг для restic init (по умолчанию по-прежнему остается то, что restic запрашивает пароль при инициализации), но это просто Мое мнение о последнем ответе

Между тем, используйте фиктивный пароль :) Я бы предположил, что правильная реализация включает в себя возможность удалить / сбросить пароль / ключ, который ранее использовался для инициализации репозитория, поэтому не нужно воссоздавать весь репозиторий.

Однако шифрование - это другое дело, и оно отслеживается в этой другой проблеме.

Меня не слишком заботит опция без пароля, но вы спорили о том, что по умолчанию нет шифрования:

Таким образом, защита паролем и шифрование могут быть предоставлены только как опции, и их не должно быть по умолчанию.

Кстати: значения по умолчанию - это знак качества программного обеспечения.

что я считаю опасным.

Хотя я в целом согласен с замечаниями @rawtaz , если речь идет строго о варианте без пароля (без изменения значения по умолчанию), я не особо в этом заинтересован.

@cfbao

Меня не слишком заботит опция без пароля, но вы спорили о том, что по умолчанию нет шифрования:

Таким образом, защита паролем и шифрование могут быть предоставлены только как опции, и их не должно быть по умолчанию.

Вы можете видеть, что даже в этой цитате сначала идут «параметры», а затем - «по умолчанию». И снова в этом суть.

В этом случае (проблема) это довольно просто - скорее всего, будет --no-password или аналогичный флаг для restic init (по умолчанию по-прежнему остается то, что restic запрашивает пароль при инициализации), но это просто Мое мнение о последнем ответе

Между тем, используйте фиктивный пароль :) Я бы предположил, что правильная реализация включает в себя возможность удалить / сбросить пароль / ключ, который ранее использовался для инициализации репозитория, поэтому не нужно воссоздавать весь репозиторий.

Вероятно, более простым решением было бы, чтобы restic поддерживал фиктивный пароль, который будет пытаться открыть существующий репозиторий, если пользователь не указал пароль.

Что касается работы с фиктивными паролями: не существует лучшего фиктивного пароля, который подошел бы всем. 1234 - раздражающий фиктивный пароль, поскольку для его ввода требуется четыре пальца. Например, "asdf" набирать намного быстрее. Также некоторые службы ограничивают выбор пароля, поэтому использование только цифр или только четырех цифр может быть невозможно. Поэтому раствор внутри restic будет наиболее удобным для пользователя. Тогда пользователям нужно будет ввести фиктивный пароль только один раз.

С точки зрения безопасности создание фиктивного пароля - плохая идея.

IFF кто-то действительно хочет обойти шифрование или не нуждается в нем, просто введите непротиворечивый пароль. Вам не нужно вводить его, вы можете написать сценарий, чтобы обернуть туда рестик и жесткий код, сколько душе угодно. Действительно, это больше работы, чем указание адреса репозитория или других параметров конфигурации?

Перезапустить набор поддельных или фиктивных жестко запрограммированных паролей - это просто напрашивается на неприятности. Что, если какая-нибудь бедняжка выберет один из предложенных вами «волшебных» паролей? Предупреждаем ли мы их, чтобы они не выбирали наши специальные фиктивные, поддельные пароли шифрования? «Нет, Тед, ты не можешь выбрать SPACECHICKEN в качестве пароля к хранилищу, это _специально_». ;)

Я согласен с тем, чтобы предоставить пользователям возможность стрелять себе в ногу с помощью ("--no-repository-password"), но я не думаю, что restic должен идти дальше этого, чтобы успокоить очень небольшой сегмент пользователей, которые желать СНИЖЕННОЙ безопасности.

С точки зрения безопасности создание фиктивного пароля - плохая идея.

Почему это хуже, чем не вводить пароль?

IFF кто-то действительно хочет обойти шифрование или не нуждается в нем, просто введите непротиворечивый пароль. Вам не нужно вводить его, вы можете написать сценарий, чтобы обернуть туда рестик и жесткий код, сколько душе угодно. Действительно, это больше работы, чем указание адреса репозитория или других параметров конфигурации?

Да, это больше работы. Restic будет решением для резервного копирования, а его выходом будет репозиторий. Так что в идеале репозиторий должен содержать все для восстановления резервной копии. Но при использовании сценария-оболочки, который жестко кодирует фиктивный пароль, это означает, что этот сценарий должен быть зарезервирован чем-то еще, иначе репозиторий будет бесполезен.

Перезапустить набор поддельных или фиктивных жестко запрограммированных паролей - это просто напрашивается на неприятности. Что, если какая-нибудь бедняжка выберет один из предложенных вами «волшебных» паролей? Предупреждаем ли мы их, чтобы они не выбирали наши специальные фиктивные, поддельные пароли шифрования? «Нет, Тед, ты не можешь выбрать SPACECHICKEN в качестве пароля к хранилищу, это _специально_». ;)

в чем именно проблема?: Тед все еще может выбрать этот пароль. Это просто означает, что 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 может расшифровать. Этот аргумент применим для любого заданного набора паролей, который вы выбираете в своем жестко заданном наборе. Это принципиально плохой дизайн безопасности.

Я не предлагал пробовать, когда расшифровка не удалась, но когда для расшифровки не указан пароль. Если кто-то выберет небезопасный пароль, он будет небезопасным, независимо от того, был ли он испробован напрямую рестиком или кем-то, подбрасывающим пароли. «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 или действительно любой всемирно признанный стандарт для руководства по передовой практике здесь. Мы не на новой территории.

Неактивное шифрование не означает, что это необходимо для restic. Хранилище только для добавления можно при необходимости зашифровать каким-либо другим способом. Тем не менее, будет некоторая незашифрованная память, даже если она предназначена только для пароля. В противном случае концепция резервного копирования будет полагаться на то, что кто-то всегда будет помнить пароль.

отказ от подписки на эту ветку ...

Давайте просто оставим все как есть, ясно, что некоторым людям нужна опция --no-password для init , и это все, о чем идет речь. Шифрование или нет - отдельный вопрос.

Просто небольшой комментарий здесь:
Я пользователь, которого не волнует шифрование. В моих данных нет ничего конфиденциального. Я действительно забочусь о людях, которые через 20-40 лет смогут использовать их, кроме меня. Еще одна худшая альтернатива - использование rclone.

Restic выглядит как хороший инструмент для этого, за исключением того, что обязательное шифрование и пароль означает, что мне нужно это учитывать. Может быть, README в репозитории резервных копий. Это больше работы, и любое решение (с моей стороны) в любом случае побеждает любое шифрование.

отметка

Спасибо за ваш вклад, я думаю, мы собрали достаточно информации.