Restic: Leere Passwörter zulassen

Restic sollte leere Passwörter zulassen.

Können Sie Ihren Anwendungsfall erläutern? Warum sollte restic leere Passwörter zulassen?

es ist eine Designentscheidung.

Es ist wirklich. Aber ich bin gespannt, was Sie erreichen wollen.

Ein verwandtes Problem ist vielleicht #1018

Ich wollte nur vorübergehend einige Verzeichnisse auf meinem lokalen System sichern, um eine schnelle Sicherheit beim Ändern von Dateien in einem Verzeichnis zu gewährleisten. Ich wollte mich nicht an eine Passphrase erinnern oder mir die Mühe machen, jedes Mal eine Passphrase einzugeben, wenn ich ein Backup erstellen möchte. Da ich gerade a als Passwort verwendet habe, gibt es keinen wirklichen Sicherheitsvorteil bei der Verwendung dieses Passworts im Vergleich dazu, kein Passwort zu verwenden. Daher macht jeder geringe Aufwand, sich ein nutzloses Passwort zu merken oder einzugeben, das Tool weniger perfekt.

Danke für die Erklärung. Ich möchte diese Überprüfung beibehalten, daher schließe ich dieses Thema vorerst. Bitte zögern Sie nicht, weitere Kommentare hinzuzufügen. Danke!

Als wir vor einiger Zeit darüber gesprochen haben, sagtest du, es würde eine Diskussion geben...
Können Sie vielleicht erklären, warum Sie diese Prüfung für sinnvoll halten? Das Repository sollte weiterhin verschlüsselt sein, damit anschließend ein Passwort hinzugefügt werden kann.

Ich halte diese Überprüfung für sinnvoll, da meiner Erfahrung nach die meisten Benutzer ein Passwort festlegen möchten. Das Akzeptieren eines leeren Passworts oder sogar ein Codepfad, der das Akzeptieren leerer Passwörter ermöglicht, kann dazu führen, dass Benutzer ihre Backups versehentlich ohne ordnungsgemäße Verschlüsselung an Remote-Standorten speichern. Dies kann passieren, wenn die Umgebungsvariable RESTIC_PASSWORD nicht exportiert oder versehentlich auf eine leere Zeichenfolge gesetzt wird.

In diesem Fall denke ich, dass es besser ist, Benutzer vor einem Fehler zu schützen, als die kleinen Unannehmlichkeiten zu beseitigen, ein Passwort festlegen zu müssen :)

Dafür gibt es aber einfache Workarounds: Verwenden Sie einen Passwort-Manager, verwenden Sie die Zeichenfolge test , exportieren Sie RESTIC_PASSWORD statisch über eine Datei zB in /etc/profile.d , verwenden Sie den Namen des Verzeichnisses, das Sie 'speichere (oder das Repository) als Passwort...

Bitte beachten Sie, dass für den Zugriff auf das Repository die Kenntnis Ihres Passworts erforderlich ist.
Der Verlust Ihres Passworts bedeutet, dass Ihre Daten unwiederbringlich verloren gehen.

Wie kann ich dies verhindern, wenn ich meine Daten nicht für immer verlieren möchte?

@LexSong Verwenden Sie einen Passwort-Manager.

Am Di, 03.07.2018 um 09:56:56 -0700 schrieb Chenfeng Bao:

@LexSong Verwenden Sie einen Passwort-Manager.

Wie schlagen Sie vor, die Datenbank des Passwort-Managers zu sichern? Tust du
schlagen Sie hier vor, einen Passwort-Manager mit einer Datenbank ohne a . zu verwenden
Passwort? Welcher Passwort-Manager unterstützt restic, um die
Passwort von?

Passwortverwaltung ist ein riesiges Thema, auf das ich in diesem Thread nicht zu sehr eingehen möchte. Nur darauf hinweisen, dass Passwörter bei richtiger Anwendung kein Kopfzerbrechen bereiten sollten. Es gibt zahlreiche Ressourcen online.

Die Datenbank eines Passwortmanagers sollte bereits ordnungsgemäß verschlüsselt sein, sodass Sie sie ohne weitere Verschlüsselungsebene überall hinstellen können. Es gibt auch viele Cloud-basierte Passwort-Manager-Dienste, sodass Sie sich nicht selbst um Backups kümmern müssen.

Was die Unterstützung von restic betrifft, können Sie das Passwort einfach lokal in eine Klartextdatei einfügen und die Option --password-file . Dann müssen Sie das Passwort nicht manuell eingeben. Das Passwort selbst sollte auch im Passwort-Manager zur Aufzeichnung hinterlegt werden.

Am Ende des Tages gibt es immer ein komplexes Passwort/eine Passphrase, die Sie sich merken müssen, um die Dinge wirklich sicher zu halten.

Wenn Sie wirklich kein Passwort für ein restisches Repository haben möchten, warum verwenden Sie dann nicht einfach ein einstelliges Dummy-Passwort?

Die Verwendung von 'a' als Passwort war eigentlich meine Problemumgehung, aber es fühlt sich nicht richtig an, da ich nicht sicher sein kann, ob ich mich daran erinnern kann, dies zu verwenden, wenn ich dieses Repository in ein paar Jahren aus irgendeinem Grund wieder sehe, falls ich vergesse, es zu löschen, wenn Ich brauche es nicht mehr. Daher muss ich möglicherweise eine Art Brute-Force-Verfahren implementieren, um es herauszufinden. Dies ist alles Arbeit, die vermieden werden könnte.

Ich habe in der Vergangenheit bereits einfache temporäre Passwörter in Situationen verwendet, die mich in diesem Zustand belassen haben, wenn ich eine externe HD vorübergehend mit einem Passwort geschützt habe, um das spätere Löschen zu erleichtern. Ich habe es jedoch nicht gelöscht, also wollte ich bei der nächsten Verwendung sicherstellen, dass sich nichts Wichtiges auf dem Laufwerk befindet. Leider funktionierte das Passwort aus meinem Passwortmanager nicht mehr, da ich vergessen hatte, es dort zu aktualisieren/zu entfernen. Wenn ich also an mein zukünftiges Ich denke, scheint es eine gute Idee zu sein, es ihm leichter zu machen, indem ich keine restriktiven Repositorys erstelle, die ich nicht entschlüsseln kann.

Ich habe eine andere Idee, wie wäre es, wenn restic versuchen würde, "restic" als Standardkennwort zu verwenden, wenn kein Kennwort für den Zugriff auf ein Repository vorhanden ist, und auf eine Fehlermeldung zurückgreifen, wenn es nicht funktioniert? Dann könnten Benutzer dieses Passwort verwenden, um anzugeben, dass sie keine Verschlüsselung benötigen und restic es ohne zusätzliche Magie öffnen würde.

Ich würde den vorherigen Kommentaren zustimmen, um den Scheck zum Schutz vor Benutzerfehlern zu behalten.

Restic muss aus den bereits genannten Gründen leere Passwörter unterstützen. ich
Ich möchte speziell meine lokalen Backups nicht verschlüsseln, weil ich es nicht möchte
den Zugang zu ihnen zu verlieren. Ich möchte nicht riskieren, das Passwort zu vergessen und
Daten nicht wiederherstellen können. Dies ist ein echtes Risiko, da Benutzer normalerweise
sehr selten wiederherstellen und oft unbeaufsichtigte Backups ausführen, für die dies nicht der Fall ist
Sie müssen das Passwort eingeben, wodurch es wahrscheinlicher wird, dass es vergessen wird.

Das Speichern des Passworts in einer Datei oder einem Skript ist eine fehleranfällige Problemumgehung für a
Problem, das es nicht geben sollte.

Ich stimme zu, dass darauf geachtet werden sollte, ein versehentliches Hochladen zu vermeiden
unverschlüsselte Daten an Remote-Repositorys.

Es scheint eine einfache Lösung zu sein, eine Befehlszeilenoption zu haben,
--allow-empty-password . Benutzer könnten diesen Schalter in ihren Skripten einstellen und
die Standardeinstellung könnte bleiben, um ein Kennwort zu erfordern.

Dies ist ein echtes Risiko, da Benutzer normalerweise sehr selten Wiederherstellungen durchführen und oft unbeaufsichtigte Backups ausführen, für die sie das Kennwort nicht eingeben müssen, wodurch es wahrscheinlicher vergessen wird.

Solche Backup-Passwörter sind nicht zum Auswendiglernen gedacht. Das einzige komplexe Verschlüsselungspasswort, das Sie sich merken müssen, ist das Passwort für Ihren Passwort-Manager, das Sie häufig verwenden werden. Und Sie sollten _wirklich_ einen Passwort-Manager verwenden.

Das Speichern des Kennworts in einer Datei oder einem Skript ist eine fehleranfällige Problemumgehung für ein Problem, das nicht existieren sollte.

Tut mir leid, ich verstehe einfach nicht, wie dies eine fehleranfällige Problemumgehung ist. Es scheint mir eine völlig gültige Möglichkeit zu sein, die Verschlüsselung zu automatisieren. Das Problem wird wiederum durch die Verwendung eines Passwort-Managers gelöst.

Es scheint eine einfache Lösung zu sein, eine Befehlszeilenoption --allow-empty-password . Benutzer könnten diesen Schalter in ihren Skripten festlegen und die Standardeinstellung könnte beibehalten werden, um ein Kennwort zu erfordern.

Dies scheint eine vernünftige Möglichkeit zu sein, Benutzerfehler zu vermeiden. Es bestehen jedoch weiterhin Bedenken hinsichtlich einer erhöhten Angriffsfläche, die mit großer Sorgfalt angegangen werden müssen.

Solche Backup-Passwörter sind nicht zum Auswendiglernen gedacht. Das einzige komplexe Verschlüsselungspasswort, das Sie sich merken müssen, ist das Passwort für Ihren Passwort-Manager, das Sie häufig verwenden werden. Und Sie sollten wirklich einen Passwort-Manager verwenden.

Ein Passwort-Manager ist absolut keine gültige Lösung für dieses Problem. Der Sinn von Backups besteht darin, Ihre Dateien zu sichern, einschließlich der Datenbank des Passwort-Managers ! Wie würden Sie dann das Kennwort für den Backup-Satz wiederherstellen, wenn das Kennwort im verschlüsselten Backup-Satz gespeichert

Beim Entwerfen eines Backup-Systems müssen Sie das Worst-Case-Szenario planen, das eine Wiederherstellung beinhaltet, wenn Sie außer Ihrem Backup nichts mehr zur Verfügung haben. Was Sie offensichtlich tun, ist, Ihre Passwort-Manager-Datenbank getrennt von Ihren Restic-Backups zu sichern. Das ist für Sie in Ordnung, aber Sie können dieses System nicht anderen Benutzern aufzwingen. Und es ist absurd zu sagen, dass für die Verwendung von Restic ein Passwort-Manager erforderlich ist, insbesondere wenn er nicht einmal für die Integration mit einem entwickelt wurde. Wenn dies der Fall ist, zeigen Sie mir bitte die entsprechende Dokumentation.

Restic soll, wie viele andere Software, Benutzern ermöglichen, ihre Bedürfnisse zu erfüllen. Ihre Anforderungen umfassen kein reines, nichts als Ihr Restic-Backup-Wiederherstellungsszenario. Die Bedürfnisse anderer Benutzer tun dies. Bitte diktieren Sie ihnen nicht die Bedürfnisse anderer.

Dies scheint eine vernünftige Möglichkeit zu sein, Benutzerfehler zu vermeiden. Es bestehen jedoch weiterhin Bedenken hinsichtlich einer erhöhten Angriffsfläche, die mit großer Sorgfalt angegangen werden müssen.

Welche konkreten Bedenken sehen Sie hinsichtlich einer erhöhten Angriffsfläche, die durch die vorgeschlagene Option --allow-empty-password ?

Dies scheint eine vernünftige Möglichkeit zu sein, Benutzerfehler zu vermeiden. Es bestehen jedoch weiterhin Bedenken hinsichtlich einer erhöhten Angriffsfläche, die mit großer Sorgfalt angegangen werden müssen.

Meine andere Idee war, dass restic ein Standardpasswort verwendet, um auf ein Repository zuzugreifen, wenn kein Passwort angegeben wurde, zum Beispiel restic . Dann ändert sich die Benutzeroberfläche zum Erstellen eines neuen Repositorys nicht und nur wenn ein Benutzer das Standardkennwort restic verwendet, kann er automatisch auf das Repository zugreifen und der Benutzer muss sich das Kennwort nicht merken.

Tut mir leid, ich verstehe einfach nicht, wie dies eine fehleranfällige Problemumgehung ist. Es scheint mir eine völlig gültige Möglichkeit zu sein, die Verschlüsselung zu automatisieren. Das Problem wird wiederum durch die Verwendung eines Passwort-Managers gelöst.

Solange keine Integration mit dem Passwortmanager erfolgt, besteht dennoch die Gefahr, dass der Wert im Passwortmanager falsch, veraltet oder versehentlich gelöscht wird, da eine Kopie des Passworts außerhalb des Passwortmanagers angelegt wird.

Ich würde auch gerne eine Option sehen, um ein leeres Passwort zuzulassen (durch die Verwendung des --allow-empty-password Flags oder vielleicht etwas ausführlicher/eindeutiger, um das Risiko hervorzuheben, wie das --dont-blame-nrpe Flag von NRPE).

Meine Anwendungsfälle:

• Geschäft: Wir haben ein Repository in einer vertrauenswürdigen Umgebung, von der wir im Notfall / im Katastrophenfall "jedermann" brauchen, um es wiederherstellen zu können, ohne spezielle Kenntnisse (zB ein Repository-Passwort) haben zu müssen.
• Zuhause: Ich möchte ein restliches Backup von Dingen wie Familienfotos erstellen. Diese sind nicht besonders vertraulich, und im Falle meines vorzeitigen Ablebens muss meine Familie mit minimalem Widerstand auf diese persönlich wichtigen Daten zugreifen können (_zum Beispiel ohne eine Passphrase in einem Safe finden zu müssen, das ist möglicherweise Datum oder mit einem anderen verwechselt_).

Ich verstehe die Notwendigkeit einer Passphrase, um die Datenintegrität und Verschlüsselung sicherzustellen. Ich sehe, dass die Datei(en) im Verzeichnis keys ein JSON-Objekt zu sein scheint. Vielleicht könnte ein pseudozufälliger Schlüssel generiert (und nicht kein Schlüssel) und darin gespeichert werden? Dies hilft jedoch nicht den Benutzern, die versuchen, den Overhead der Verschlüsselung aus Leistungsgründen zu vermeiden.

@fd0 Was halten Sie von der vorgeschlagenen Befehlszeilenoption --allow-empty-password ? Es würde standardmäßig Passphrasen erfordern, aber Benutzern ermöglichen, es bei Bedarf zu überschreiben.

Und bitte erwägen Sie, dieses Thema erneut zu öffnen. Viele Benutzer müssen nicht vertrauliche Dateien sichern, ohne den Zugriff aufgrund vergessener oder falsch platzierter Passphrasen zu verlieren.

Brandneuer Restic-Benutzer hier -- habe noch nicht einmal mein erstes Repository erstellt -- aber jahrelange Erfahrung mit anderen Tools -- mein Favorit ist der gute alte "Dump". Mit Respekt, dies ist ein Kinderspiel – leere Passwörter sollten natürlich erlaubt sein. Fügen Sie auf jeden Fall ein Flag hinzu, um das Risiko versehentlicher Fehler zu minimieren, aber diktieren Sie bitte keine Anwendungsfälle an erfahrene (potenzielle) Benutzer, die eindeutig andere Bedürfnisse angegeben haben.
Alles, was ich versuche, ist, aus Sicherheitsgründen lokale Backups zu erstellen; Sicherheit ist kein Problem, und es ist viel wahrscheinlicher, dass ich das Passwort aus den Augen verliere, als dass ich das Backup benötige. Und ich hasse Passwortmanager...

Das Erfordernis eines Passworts macht es schwierig, Backups zu automatisieren, und die Notwendigkeit, das Passwort in einer Umgebungs- oder Skriptdatei bereitzustellen, macht die ganze Sicherheitssache von vornherein nutzlos.

die Notwendigkeit, das Passwort in einer env- oder Skriptdatei anzugeben, macht die ganze Sicherheitssache von vornherein nutzlos.

Das stimmt nicht unbedingt. Dafür gibt es gute Möglichkeiten.

Das stimmt nicht unbedingt. Dafür gibt es gute Möglichkeiten.

Bitte wiederholen Sie dieses Argument hier nicht. Viele Benutzer müssen unverschlüsselte Backups oder Backups mit leerem Passwort erstellen. Wenn Sie keiner von ihnen sind, gut für Sie.

@mholt , irgendwelche Empfehlungen? Ich würde mich sehr freuen, meine Server störungsfrei und mit maximaler Sicherheit zu sichern.

Viele Benutzer müssen unverschlüsselte Backups oder Backups mit leerem Passwort erstellen.

Dies ist normalerweise ein XY-Problem .

@mholt , irgendwelche Empfehlungen? Ich würde mich sehr freuen, meine Server störungsfrei und mit maximaler Sicherheit zu sichern.

Dies hängt stark von Ihrer spezifischen Situation, Ihrem Bedrohungsmodell, Ihrer Umgebung, den akzeptablen Risiken sowie den technischen und Benutzerfreundlichkeitszielen ab. Also nein, ich habe keine Pauschalempfehlungen für irgendjemanden.

Dies ist normalerweise ein XY-Problem.

Also nein, ich habe keine Pauschalempfehlungen für irgendjemanden.

Diese herablassende Haltung ist nicht hilfreich. Noch schlimmer ist, dass Sie, nachdem Sie uns mitgeteilt haben, dass unsere Bedürfnisse falsch sind, keine Beratung anbieten. Dies ist ein FOSS-Projekt, nicht von Apple, Inc.

Ich brauche und möchte beispielsweise meine lokalen Backups meiner bereits unverschlüsselten Daten weder verschlüsseln noch verschlüsseln. Wenn meine primäre Festplatte ausfällt und ich meine Backups wiederherstellen muss, wird die Passphrase mit meinen Backup-Skripts und Konfigurationsdateien im Backup-Repository gespeichert. Mein Hauptanliegen ist es nicht, andere daran zu hindern, auf diese nicht sensiblen Daten zuzugreifen – mein Hauptanliegen ist die einfache Wiederherstellung und nicht der Ausschluss von meinen Daten.

Dies ist ein häufiger Fall für viele Benutzer, und es liegt nicht an Ihnen, die Bedürfnisse der Benutzer zu bestimmen.

Software existiert, um Benutzern zu dienen, und nicht, um Benutzer zu zwingen, ihren Forderungen nachzukommen.

Nochmals vielen Dank für die Erläuterung Ihres Anwendungsfalls bzw. Ihrer Anwendungsfälle. Fürs Protokoll, ich denke, sie sind gültig, insbesondere das "Passwort verloren". Ich denke auch, dass ein spezielles Flag für restic init wie --allow-empty-password funktionieren würde (ich habe einige Überlegungen für Eckfälle, bin aber zuversichtlich, dass sie gelöst werden können). Ich öffne daher dieses Thema nochmal.

Bitte beachten Sie, dass das Zulassen leerer Passwörter die Sicherheitsbedenken für "Passwort verloren" ausräumt, aber dennoch alle Daten wie gewohnt verschlüsselt.

Ansonsten gefällt mir der Ton in diesem Thread überhaupt nicht. Es steht Ihnen frei, Restic nicht zu verwenden, das ist völlig in Ordnung. Die meisten von uns arbeiten in ihrer Freizeit an Restic. Einige Kommentare in diesem Thread wirken sehr berechtigt, paraphrasiert: "Sie müssen dieses Feature implementieren, es gibt Benutzer, die es brauchen!". Das ist nicht der Fall. Wir können es erwägen und umsetzen, aber wir können uns auch entscheiden, nichts zu tun.

Also bitte alle, lasst uns diese Diskussion produktiv halten, auch wenn ihr anderer Meinung seid. :)

@fd0 Verzeihen Sie, dass ich unklar bin. Ich verlange und erwarte nichts von Ihnen oder irgendwelchen Restic-Entwicklern. Es ist Ihr Projekt und Ihre Zeit, und Sie können an allem arbeiten, was Sie wollen.

Ich bitte Sie, diese Funktion und diesen Anwendungsfall zu berücksichtigen. Wenn Sie nicht daran interessiert sind, es selbst zu implementieren, ist das in Ordnung, und ich bitte Sie, das Thema offen zu lassen, damit andere es diskutieren können, und dass Sie alle PRs berücksichtigen, die es implementieren könnten.

Wogegen ich Einwände habe, sind Kommentare (nicht Ihre), die darauf hindeuten, dass Benutzer, die diese Funktion wünschen, ihre eigenen Bedürfnisse nicht verstehen, insbesondere wenn sie von einer Weigerung gefolgt werden, Alternativen vorzuschlagen. Das ist unhöflich und nicht hilfreich.

Für mich verwende ich git-annex mit einer speziellen bup-Fernbedienung. Annex unterstützt bereits die Verschlüsselung von Dateien (die ich deaktiviert habe, um die Deduplizierungsfunktion von bup zu nutzen). Und dann sichere ich das Bup-Repo (das nur ein schickes Git-Repo ist) auf einem Remote-Server. Ich kann dann das Bup-Repo löschen, da es nur ein Cache ist, und bei Bedarf eine Wiederherstellung über restic durchführen.

Im Grunde füge ich also eine Reihe von Einwegwerkzeugen zusammen, im Unix-Weg (tm), da jedes seine eigene Sache gut macht. Restic (ich wechsle gerade von Duplicity) führt Sliding-Window-Block-Deduplizierung in eine Remote-Cloud durch, und das ist alles, was ich tun muss. Verschlüsselung und lokale Blockdeduplizierung erfolgen auf einer anderen Ebene. Ich möchte also weder ein Passwort angegeben noch eine Verschlüsselung (die tatsächlich CPU-Auslastung spart).

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

Dies ist nur die Hälfte von dem, was ich will, da es immer noch verschlüsselt, aber mit einem leeren Passwort. Ich würde diese CPU-Auslastung gerne wiederherstellen, wenn ich könnte.

Bitte beachten Sie, dass das Zulassen leerer Passwörter die Sicherheitsbedenken für "Passwort verloren" ausräumt, aber dennoch alle Daten wie gewohnt verschlüsselt.

Hm, was ist die Motivation, immer noch mit einem leeren Passwort zu verschlüsseln?

Ich meine, wenn Restic auf stromsparender Hardware ausgeführt wird, fügt die Verschlüsselung einen spürbaren Laufzeit-Overhead hinzu.

Edit: Ok, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - vor allem der 2. Punkt beantwortet meine Frage.

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

Das Hauptproblem bei diesem Vorschlag ist: Es funktioniert einfach nicht, restic fragt dann interaktiv nach einem Passwort:

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

Vielen Dank, @fd0 , dass Sie das Problem erneut öffnen. Ich stimme @alphapapa zu , meine Absicht ist es nicht , Freizeitentwickler dazu zu bringen, ihre Zeit mit Dingen zu verbringen, mit denen sie keinen Spaß haben.

Wir mögen es einfach nicht, von anderen gesagt zu werden, dass wir unsere eigenen Bedürfnisse nicht verstehen.

Meiner Meinung nach ist das wichtigste Feature eines Backup-Tools die Möglichkeit, auf jeden Fall eine Wiederherstellung durchzuführen. Obwohl die Sicherheit einen sehr, sehr hohen Stellenwert hat, hängt es von der jeweiligen Situation ab, ob die Datensicherheit (Wiederherstellungsfähigkeit) oder die Datensicherheit (Schutz vor unberechtigtem Zugriff) eine höhere Priorität hat.

Natürlich können Sie frei entscheiden, ein Tool nur für Situationen zu entwickeln, in denen Sicherheit wichtiger ist als Sicherheit.

Wie @mholt das "XY-Problem" erwähnte: Die Anforderung besteht darin, über eine öffentlich verfügbare generische restic-Dokumentation und natürlich Zugriff auf das Repository selbst ohne jegliches Wissen eine Disaster-Recovery durchführen zu
„Ohne Wissen“ schließt die Notwendigkeit oder den Einsatz von Passwort-Managern aus.

Der Grund, warum ich dieses Problem gefunden habe, ist: _Ich helfe einigen Leuten privat mit ihren PCs. Ihr Umgang mit Passwörtern ist ein Chaos. Der Versuch, ihnen beim Einrichten eines Backups auf USB-Laufwerken den richtigen Umgang mit Passwörtern beizubringen, führt nur dazu, dass entweder keine Backups erstellt werden oder das Passwort bei Bedarf nicht verfügbar ist. Sie erhalten möglicherweise Hilfe von jemand anderem, wenn sie eine Wiederherstellung benötigen. Daher kann alles, was ich zur Linderung der Situation einfalle, ungültig sein._

Im Moment speichere ich das Passwort in einer Textdatei auf demselben USB-Laufwerk wie das restliche Backup-Repository, was die Sicherheit eines Passworts komplett verdirbt.
Und ich mag diese Lösung nicht, da die Verwendung eines Passworts, das keine zusätzliche Sicherheitsebene bietet, eine sehr falsche Vorstellung von Sicherheit vermittelt.

Natürlich rede ich hier nur von persönlichen lokalen Backups. Für Server empfehle ich starke Passwörter, die in einen separaten Offline-Speicher kopiert werden.

Ich denke, ein weiteres Problem ist hier; wenn einige Frameworks/APIs leere Passwörter zulassen und andere nicht. Und man muss eine Eingabe entschlüsseln, die von einer anderen API mit leerem Passwort verschlüsselt wurde. Dies ist derzeit mein Problem mit https://github.com/RNCryptor/JNCryptor

Also bitte alle, lasst uns diese Diskussion produktiv halten, auch wenn ihr anderer Meinung seid. :)

Nachdem ich diesen Thread gelesen habe, finde ich die Konversation produktiv, weil das Ergebnis positiv war.

Ich möchte alle daran erinnern, dass dies Github ist – wenn Sie sich für etwas stark fühlen und der Projektbetreuer nicht empfänglich ist, können Sie gerne eine Abzweigung erstellen – es dauert buchstäblich Sekunden. Wenn Sie nicht die Fähigkeit haben, die Änderung selbst vorzunehmen, bitten Sie andere, Ihnen zu helfen. Sie werden feststellen, dass Betreuer offener dafür sein können, einen Patch zu akzeptieren, der etwas implementiert, für das sie selbst nicht motiviert gewesen wären.

Ich persönlich halte es in diesem Fall für einen Fehler, jedem eine vorgefasste Meinung darüber aufzuzwingen, was Sicherheit sein "sollte". Die erste Regel der Datensicherheit lautet, dass die Daten für diejenigen zugänglich sein müssen, die dazu berechtigt sind. Jede Regel, die Regel 1 kompromittiert, sollte mit gebührender Sorgfalt betrachtet werden.

Sicherheit ist ein Thema voller FUD und angstgetriebener Richtlinien, die zu naiven, voreiligen und oft heuchlerischen Implementierungen führen, weil nur wenige von uns gerne über all die Dinge nachdenken, die schief gehen können. Noch weniger wollen sich der Kritik anderer stellen, wenn wir sehen, dass Dinge schief gehen.

Einige häufige Fehler, die wir jeden Tag sehen:

1) Bestehen darauf, dass Daten, die auf ein im Ruhezustand verschlüsseltes Medium geschrieben werden, selbst in einer vertrauenswürdigen Umgebung verschlüsselt werden müssen. Wo hört die Angst vor dem Abfangen auf? Wo können wir anfangen, darauf zu vertrauen, dass der Benutzer möglicherweise kompetent ist und dass das Hinzufügen redundanter Schichten lediglich das Risiko von Datenverlusten erhöht?

2) Auf Passwort in einem bestimmten Format bestehen, dh 8 Zeichen mit mindestens einem Großbuchstaben, einer Zahl und einer nicht-alphanumerischen - dies war 20 Jahre lang gängige Praxis und wurde jetzt entlarvt, weil der Schmerz den Gewinn übersteigt. Stattdessen sollten wir auf einprägsamen Passwörtern mit hoher Entropie wie xkcdpassword bestehen oder einen Passwort-Manager integrieren (was effektiv alle wichtigen Verbraucher auf ein gemeinsames Sicherheits-SPOF-Master-Passwort angewiesen macht, das spearphishing ist – fragen Sie einfach COMMODO) oder integrieren Sie 2FA (potenziell besser .) abhängig von der physischen Sicherheit des zweiten Faktors, einschließlich N+1-Schlüsselredundanz).

3) Mit einem Master-Passwort – es wird nicht in einer Sitzung zwischengespeichert, sodass der Benutzer gezwungen ist, es im Laufe des Tages so oft einzugeben, dass die bloße Aktion seiner Eingabe zu einem auffälligen Angriffsvektor wird.

4) Mit einem Master-Passwort - Richtlinien werden nicht überprüft und blind nach dem Master-Passwort abgefragt, sodass sich der Benutzer daran gewöhnt, es zu präsentieren, wenn es eigentlich nicht erforderlich ist, und damit aufhört, kritisch zu analysieren, ob er es bereitstellen sollte oder nicht diese Instanz.

5) Die Durchsetzung einer Richtlinie mit den geringsten Privilegien bis zu einem Punkt, an dem Benutzer sie übel nehmen und vermeiden, sich anzumelden oder Wege zu finden, sie zu umgehen, wodurch die Tür viel länger offen bleibt, als wenn es ein freizügigeres System gäbe.

6) Durchsetzung einer Richtlinie mit den geringsten Privilegien ohne N+1-Redundanz, auch bekannt als Mangel an Überlegungen zur "Geschäftskontinuität / "Richtlinie für Schlüsselpersonen". dh anstatt eine gemeinsam genutzte Ressource hinter 2 privaten Schlüsseln zu sperren, damit nur dann darauf zugegriffen werden kann, wenn beide einverstanden sind (Quorum von 2), sperren Sie sie hinter 2 von 3 privaten Schlüsseln. Niemand lebt ewig.

Jedes Mal, wenn wir als Programmierer ein Verschlüsselungsverfahren mit einem einzigen Schlüssel implementieren, müssen wir die Bedeutung der Zugänglichkeit berücksichtigen und die Bedenken derer anhören, die sich der Konsequenzen des Schlüsselverlusts für ein Verschlüsselungsverfahren mit einem einzigen Schlüssel schmerzlich bewusst sind.

Versuchen wir auch, daran zu erinnern, dass es grundsätzlich falsch ist, den Nutzern Dinge aus Angst vor Missbrauch wegzunehmen – wie fast alle Entscheidungen aus Angst. Alle zu bestrafen, weil jemand das Falsche tun könnte, schmälert die Gesellschaft als Ganzes.

Wenn Sie in diesem Moment das Gefühl haben, mit diesem Konzept nicht einverstanden zu sein, dann atmen Sie tief durch, zählen Sie bis zehn, dann überlegen Sie: Was sollen wir als Gesellschaft tun, wenn jemand Selbstmord begeht, indem er seinen Kopf in einen Müllsack mit einer Dose Schlagsahne aufsprühen und die gesamte Dose Lachgas inhalieren? Sollen wir allen die Sprühsahne wegnehmen? Plastiktüten? Atmung? All diese Dinge könnten auf eine Weise missbraucht werden, die zum Tod des Benutzers führt.

Anstelle des reflexartigen Drangs, Dinge wegzunehmen, wie wir es bei einem Kind tun würden, das mit Streichhölzern spielt, sollten wir stattdessen auf die Seite gehen, die Menschen zum richtigen Umgang mit diesen Dingen zu erziehen. Oder heben Sie die Einstiegslatte so hoch, dass nur diejenigen, die RTFM haben, sie finden.

Das ist hier letztendlich passiert, und die Entscheidung, dieses Ergebnis zu akzeptieren, fiel erst, als alle Fragen und Meinungen geäußert wurden. Ich empfehle, die parlamentarischen Debatten in den öffentlich-rechtlichen Fernsehsendern anzuschauen, um Beispiele dafür zu finden, wie sich eine unproduktive Debatte anhört, lol. Die Teilnehmer hier waren im Vergleich zueinander außergewöhnlich respektvoll.

Erinnern Sie sich an alte gute Archivierungsprogramme, bei denen Verschlüsselung und Passwortschutz nur als explizite Optionen, aber nicht standardmäßig verfügbar waren. Und das ist die richtige Logik, denn Security kann viele externe Lösungen aus diesem Anwendungsbereich haben und diese Sorgfalt liegt beim Benutzer. Sie stellen lediglich die Sicherheitstools der Benutzer zur Verfügung. Aber der Autor kümmert sich lieber um das, was der Benutzer nicht verlangt, um Missbrauch zu verhindern.

Und noch einmal über den Ton. Dies ist in der Open-Source-Welt üblich. Und es wird durch einen psychologischen Mechanismus unterstützt. Kritik, der die Autoren nicht zustimmen, wird als Anspruch auf Freizeitbeschäftigung behandelt. Und jedes Mal müssen wir daran erinnern: Wir diskutieren hier nicht über Ihre Freizeit, sondern erforschen Ihr geniales Wesen, seine Funktionsweise und die Logik dahinter. Wir vergessen nie, dass Sie nicht verpflichtet sind, unsere Forderung zu erfüllen, und Sie haben das volle Recht, überhaupt nichts zu tun. Aber wenn Sie mögen, was Sie tun, kann es (vielleicht) daran liegen, dass andere es mögen. Es besteht also möglicherweise die Hoffnung, dass Sie daran interessiert sind, die Nachfrage zumindest der Mehrheit zu decken.

PS All dies sind nur abstrakte Geplänkel und keine Übungshandlungen sind gemeint.

Es gibt eine Sache, die ich bei der Diskussion über das Zulassen eines Passworts für ein Repository nie verstanden habe (vorausgesetzt der Kontext, den @fd0 zuvor geschrieben hat, dass die Daten immer noch verschlüsselt werden); Warum verwenden diejenigen, die kein Passwort "wollen", nicht einfach ein Dummy-Passwort wie "1234" oder was auch immer? Was bringt es, Code in Restic zu schreiben, der das Passwort entfernt, wenn Sie, wenn Sie sich nicht für ein Passwort interessieren, einfach ein Dummy-Passwort verwenden können? Es ist eine Umgebungsvariable oder Passwortdatei entfernt, wenn Sie denken, dass es umständlich ist, es in der Befehlszeile einzugeben, wenn Sie restic ausführen.

@rawtaz Dies wurde in früheren Kommentaren zu diesem Thread beantwortet.

Lassen Sie mich nur sagen, dass restic init -r foo --no-password wahrscheinlich ein besserer Flagname ist als restic init -r foo --allow-empty-password , einfach weil ersteres mehr auf den Punkt kommt und letzteres einfach zu ausführlich ist.

Ich sehe keine guten Argumente, warum die bloße Verwendung eines Dummy-Passworts keine vollkommen praktikable Möglichkeit ist, dies zu tun, anstatt die restliche Codebasis zu diesem Thema zu erhöhen. Ich habe jemanden sagen sehen, dass er das Passwort "a" vergessen könnte. Das mag stimmen, aber es ist sicherlich möglich, ein einfaches Dummy-Passwort zu erfinden und sich daran zu erinnern oder es zumindest bei Bedarf neu herauszufinden. Aber egal, eine Flagge funktioniert auch gut, ich bin nur erstaunt, wie groß das Problem ist :D

Nun, hier ist ein Beispiel. Habe vor einem Jahr ein Restic Backup gemacht. Geskriptet als
Dummy-Passwort, aus einer Datei lesen. Passwort nicht aufgeschrieben
irgendwo anders. Nach einem Jahr, in dem ich diese Maschine nicht benutzt habe, bin ich vollständig
sowohl den Prozess als auch das Passwort vergessen – und eine Stunde damit verschwendet, es zu versuchen
erraten Sie das Passwort, bevor Sie es schließlich finden (und zurückentwickeln)
das Skript. Ganz meine Schuld, aber trotzdem -- ich brauche die Sicherheit nicht,
und möchten nicht gezwungen werden, sich ein Dummy-Passwort zu merken. Und wenn ich
Hätte ich keinen Zugriff auf die Originaldateien gehabt, wäre ich ausgesperrt worden.

TD

Ist das nicht zu kompliziert? Eines der gebräuchlichsten Passwörter ist 1234. Verwenden Sie dieses und Sie müssen nicht versuchen, es irgendwo zu finden (vorausgesetzt, Sie denken nicht, dass Sie ein komplexeres Passwort verwendet haben), denn wenn Sie ein Dummy-Passwort eingeben müssen, wissen Sie, dass es ist 1234. Aber klar, ich verstehe, was Sie meinen.

Ich würde auch gerne eine Option sehen, um ein leeres Passwort zuzulassen (durch die Verwendung des --allow-empty-password Flags oder vielleicht etwas ausführlicher/eindeutiger, um das Risiko hervorzuheben, wie das --dont-blame-nrpe Flag von NRPE).

Meine Anwendungsfälle:

* **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_).

Ich verstehe die Notwendigkeit einer Passphrase, um die Datenintegrität und Verschlüsselung sicherzustellen. Ich sehe, dass die Datei(en) im Verzeichnis keys ein JSON-Objekt zu sein scheint. Vielleicht könnte ein pseudozufälliger Schlüssel generiert (und nicht kein Schlüssel) und darin gespeichert werden? Dies hilft jedoch nicht den Benutzern, die versuchen, den Overhead der Verschlüsselung aus Leistungsgründen zu vermeiden.

• Geschäft: Wir haben ein Repository in einer vertrauenswürdigen Umgebung, von der wir im Notfall / im Katastrophenfall "jedermann" brauchen, um es wiederherstellen zu können, ohne spezielle Kenntnisse (zB ein Repository-Passwort) haben zu müssen.

Aber diese "irgendjemanden" brauchen bereits spezielle Kenntnisse/Anleitungen. Sie müssen entweder wissen, wie man restic ausführt, um Daten wiederherzustellen, einschließlich des zu verwendenden Repositorys und andere Dinge, und es wäre dann unglaublich einfach, ein Dummy-Passwort in diese Anweisungen aufzunehmen. Oder sie würden ein Skript oder eine ähnliche Automatisierung verwenden, die die Wiederherstellung für sie durchführt (in diesem Fall müssen sie immer noch wissen / Anweisungen erhalten, wo sie dieses Tool verwenden können), in diesem Fall würde das Dummy-Passwort vom Skript verarbeitet . Egal wie Sie dies betrachten, ein Dummy-Passwort ist kein Problem. Und im Ernst, wenn es jeder plötzlich vergessen würde, werden die Leute 1234 einfach erraten oder es brachial erzwingen. Das ist kein Problem :P

• Zuhause: Ich möchte ein restliches Backup von Dingen wie Familienfotos erstellen. Diese sind nicht besonders vertraulich, und im Falle meines vorzeitigen Ablebens muss meine Familie mit minimalem Widerstand auf diese persönlich wichtigen Daten zugreifen können (_zum Beispiel ohne eine Passphrase in einem Safe finden zu müssen, das ist möglicherweise Datum oder mit einem anderen verwechselt_).

Warte was? Warum um alles in der Welt wollen Sie kein Passwort haben, und wenn das (zumindest derzeit) nicht möglich ist, verwenden Sie ein supereinfaches Dummy-Passwort (zB 1234) und legen Sie dieses supereinfache Dummy-Passwort in einen Safe ? Das wäre völlig sinnlos. Legen Sie es woanders hin, und für was es wert ist, haben Sie wahrscheinlich bereits eine ganze Reihe anderer Informationen, die Ihre Familie im Falle Ihres Ablebens wissen muss, also fügen Sie einfach Ihr Dummy-Passwort hinzu.

Schließlich sollte ein Dummy-Passwort so einfach und offensichtlich sein, dass es nicht veraltet, und es ist nicht mehr als ein Dummy-Passwort erforderlich. Es sollte also nicht veraltet oder mit einem anderen vermischt sein.

Ja, diese Vorschläge wurden bereits gemacht, also drehen wir uns jetzt im Kreis. Für mein Umfeld und meine Anwendungsfälle sind das persönlich keine geeigneten Lösungen, mit denen ich mich wohl fühle.

Sie brauchen diese Funktion nicht, das ist in Ordnung. Das bedeutet nicht, dass die Anwendungsfälle aller anderen ungültig sind. Ich habe keine Verwendung für das Amazon S3-Backend, aber ich deklariere es nicht für nicht benötigt, ich benutze es einfach nicht. Wenn diese Funktion implementiert ist, kostet es Sie nichts, sie nicht zu verwenden.

Ja, diese Vorschläge wurden bereits gemacht, also drehen wir uns jetzt im Kreis.

Ja, und ehrlich gesagt habe ich immer noch keine wirkliche Erklärung dafür gesehen, warum ein Dummy-Passwort so schwer zu handhaben ist, ich habe das Gefühl, dass ich es meistens überkompliziert habe.

Für mein Umfeld und meine Anwendungsfälle sind das persönlich keine geeigneten Lösungen, mit denen ich mich wohl fühle.

Das ist etwas, was ich total respektiere. Jeder Anwendungsfall ist individuell und Sie haben Ihren Workflow :)

Ich denke, irgendwann werden wir ein --no-password oder ähnliches bekommen, hoffentlich wird das auch diesen Anwendungsfall lösen. Danke für deinen Beitrag!

rawtaz hat geschrieben

Lassen Sie mich nur sagen, dass restic init -r foo --no-password wahrscheinlich ein besserer Flagname ist als restic init -r foo --allow-empty-password , einfach weil ersteres mehr auf den Punkt kommt und letzteres einfach zu ausführlich ist.

Ich sehe keine guten Argumente, warum die bloße Verwendung eines Dummy-Passworts keine vollkommen praktikable Möglichkeit ist, dies zu tun, anstatt die restliche Codebasis zu diesem Thema zu erhöhen. Ich habe jemanden sagen sehen, dass er das Passwort "a" vergessen könnte. Das mag stimmen, aber es ist sicherlich möglich, ein einfaches Dummy-Passwort zu erfinden und sich daran zu erinnern oder es zumindest bei Bedarf neu herauszufinden. Aber egal, eine Flagge funktioniert auch gut, ich bin nur erstaunt, wie groß das Problem ist :D

Ich mache mir keine Sorgen über die Verwendung / Handhabung von Dummy-Passwörtern - stattdessen mache ich mir manchmal Sorgen, dass die CPU-Auslastung den Backup-Prozess durch die obligatorische Verschlüsselung verlangsamt, wenn er auf Low-End-Hardware ausgeführt wird.

Das Auflösen von #1018 (unverschlüsselte Backups) würde dieses Problem ebenfalls lösen - zB mit einem --unencrypted Schalter anstelle von --no-password Schalter.

Ich habe Restic tatsächlich auf Low-End-Hardware verwendet, bei der die CPU definitiv kein AES-NI (oder eine ähnliche Erweiterung) hatte und das Backup dann CPU-gebunden war. In einem anderen Fall war die CPU etwas leistungsfähiger, aber die einzige verfügbare externe Festplatte war bereits LUKS-verschlüsselt und somit CPU-gebunden, da sie nicht leistungsstark genug war, um zwei Verschlüsselungsvorgänge parallel abzuwickeln.

Siehe auch: https://github.com/restic/restic/issues/1018#issuecomment -307549863

Wenn Sie die Verwendung von restic vergessen haben, können Sie die Dokumentation lesen. Wenn Sie einen Repository-Speicherort vergessen, können Sie ihn finden. Oder Sie können beiläufig auf ein verwaistes Repository stoßen und sich fragen, was darin gesichert ist. Aber wenn Sie das Passwort vergessen haben, verlieren Sie Ihre Daten für immer. Und im wirklichen Leben können Sie jedes einfachste Dummy-Passwort vergessen. Sie können alles vergessen, was Sie nicht oft verwenden.

Wenn Sie das Root-Passwort verlieren, können Sie mit der Option init=/bin/bash booten und erhalten vollen Zugriff. Obwohl dieses Loch geschlossen werden könnte, existiert es in den meisten Systemen immer noch. Wieso den? Denn der Verlust durch die Nichtverfügbarkeit wäre in diesen Fällen mehr als durch Unsicherheit. Somit ist es ein Kompromiss zwischen Sicherheit und Verfügbarkeit. Für Systeme mit höheren Anforderungen gibt es spezielle Lösungen, wie redundante Schlüssel, die sowohl Sicherheit als auch Verfügbarkeit bieten.

resitc ist kein Sicherheitstool. Es ist ein Backup-Tool. Und als solches sollte es zunächst die Backup-Funktionalität selbst bereitstellen und erst dann die Sicherheit. Passwortschutz und Verschlüsselung könnten daher nur als Optionen bereitgestellt werden und sollten nicht standardmäßig vorhanden sein.

Übrigens: Standardeinstellungen sind das Zeichen für Softwarequalität.

@vstavrinov Bitte lesen Sie die Einführung zu restic, bevor Sie sagen, dass es sich nicht um ein Sicherheitstool handelt. Es ist ein Backup-Tool, dessen eine der Hauptfunktionen darin besteht, dass es versucht, Ihre Backups zu sichern. Sie liegen also ziemlich weit daneben, wenn Sie sagen, dass es nicht um die Sicherheit geht.

Aber wenn Sie das Passwort vergessen haben, verlieren Sie Ihre Daten für immer.

Ja, und deshalb verwenden Sie (in diesem Fall die einfache Möglichkeit) ein Dummy-Passwort, damit Sie das Passwort auch dann immer wiedererkennen, wenn Sie es vergessen sollten.

Und im wirklichen Leben können Sie jedes einfachste Dummy-Passwort vergessen.

Wenn Sie dies tun, haben Sie ein zu komplexes Dummy-Passwort gewählt, und es ist nicht mehr wirklich ein einfaches Dummy-Passwort.

Diese ganze Diskussion wird ehrlich gesagt urkomisch albern. Ich kann nicht glauben, dass die Leute sagen, dass ein Passwort wie 1234, das eines der gebräuchlichsten und offensichtlichsten ist, etwas ist, das sie vielleicht vergessen und dann nicht schnell herausfinden können (zB indem sie einfach ein paar offensichtliche Dummys ausprobieren .) Passwörter). Ich würde sagen, Sie müssen sich wirklich anstrengen, um 1234 nicht "erraten" zu können, wenn Sie sich in dieser Situation befinden, und selbst dann werden Sie es höchstwahrscheinlich nicht erraten.

Aber wenn Sie das Passwort vergessen haben, verlieren Sie Ihre Daten für immer.

Wikipedia könnte Ihnen helfen: Probieren Sie einfach die gängigsten Passwörter von https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List aus.

Dies kann beispielsweise passieren, wenn die Umgebungsvariable RESTIC_PASSWORD nicht exportiert oder versehentlich auf eine leere Zeichenfolge gesetzt wird.

Es ist möglich, dass der Code prüft, ob ein Passwort explizit auf einen leeren String gesetzt wurde oder einfach nicht gesetzt wurde (keine Kommandozeilenoption angegeben, Umgebungsvariable nicht gesetzt -> anders als ein leerer String).

Ich denke, die Wahl sollte dem Benutzer überlassen werden, welches Passwort er wählen möchte.

Das Auflösen von #1018 (Unverschlüsselte Backups) würde dieses Problem ebenfalls lösen - zB mit einem --unencrypted-Schalter anstelle des --no-password-Schalters.

Die Verschlüsselung sollte zum Schutz vor binärer Suche auf einem Hosting-Provider unabhängig vom Format, Übertragung über einen unverschlüsselten Kanal mit MITM usw. weiterhin obligatorisch sein. Dies bietet Ihnen zwar genauso viel Schutz wie ein leeres Passwort für gezielte Angriffe (null), vermeidet jedoch Kollateralschäden bei nicht gezielten Angriffen.

@rawtaz

Es ist ein Backup-Tool, dessen eine der Hauptfunktionen darin besteht, dass es versucht, Ihre Backups zu sichern. Sie liegen also ziemlich weit daneben, wenn Sie sagen, dass es nicht um die Sicherheit geht.

Nicht weit weg. Zeigen Sie mir, wo ich sage "es geht nicht um die Sicherheit". Ich nicht. Sie sagen dasselbe: "Es ist ein Backup-Tool". Backup ist keine Sicherheit, oder?. Restic ist also kein Sicherheitstool. Und "... eines der Hauptmerkmale ...". Sie haben wieder Recht: Es ist ein Feature. dh Sicherheit ist ein Merkmal, während ein Backup eine funktionale (Ziel-)Bezeichnung ist.

@rawtaz

Diese ganze Diskussion wird ehrlich gesagt urkomisch albern. Ich kann nicht glauben, dass die Leute sagen, dass ein Passwort wie 1234 ...

Ich kann nichts tun, aber auch in diesem Fall hast du recht. Was albern ist, ist eine Diskussion über ein Dummy-Passwort. Aber ich denke, wichtiger ist es zu verstehen, dass Passwortschutz und Verschlüsselung optional sein sollten. Erzwingen Sie den Benutzern keine zusätzlichen unerwünschten Funktionen, sodass sie die Wahl haben, sie zu verwenden oder nicht. Und das ist auch das Zeichen für Softwarequalität.

Aber ich denke, wichtiger ist es zu verstehen, dass Passwortschutz und Verschlüsselung optional sein sollten.

Wieso den? Warum "sollte" ein Backup-Tool keine Standardverschlüsselung haben? Nur weil es ein "Backup"-Tool ist? Du sagst das nur, aber dazu gibt es keinen Grund.

Keine Designentscheidung kann jedem gefallen. Restic _wählt_, großen Wert auf Sicherheit zu legen, und Benutzer wie ich _lieben_, dass eine starke Verschlüsselung die Standardeinstellung ist.

• Wenn Ihnen Sicherheit nicht wichtig ist, können Sie ein standardmäßig sicheres System _nicht_ missbrauchen. Schlimmstenfalls sehen Sie einige Fehler und versuchen es erneut mit einem angepassten Befehl.
• Wenn Ihnen Sicherheit am Herzen liegt, gibt es unzählige Möglichkeiten, ein standardmäßig unsicheres System mit katastrophalen Folgen zu missbrauchen. Ein fehlendes Flag, und Ihre sensiblen Daten sind durchgesickert, vielleicht _irreversibel_.

Es ist eine Sache, nach einem Flag zu fragen, das das Passwort weglassen kann, aber für alle bestehenden Benutzer, die auf die Verschlüsselung von restic angewiesen sind, zu argumentieren, ist eine gefährliche "Verdammung". Das Potenzial für katastrophale Benutzerfehler ist riesig.

@cfbao

Aber ich denke, wichtiger ist es zu verstehen, dass Passwortschutz und Verschlüsselung optional sein sollten.

Wieso den? Warum "sollte" ein Backup-Tool keine Standardverschlüsselung haben? Nur weil es ein "Backup"-Tool ist? Du sagst das nur, aber dazu gibt es keinen Grund.

"optional" ist nicht gleich "default". Defaults als solche können strittig sein. Aber es ist wichtiger, Optionen zu haben. Obwohl wir keine Wahl haben, gibt es nichts mit Standardeinstellungen zu tun. Das ist der Punkt. Geben Sie zuerst Optionen an, dann ist es sinnvoll, die Standardeinstellungen zu besprechen.

In diesem Fall (Problem) ist es ziemlich einfach - es wird wahrscheinlich ein --no-password oder ähnliches Flag für restic init (wobei die Standardeinstellung immer noch so ist, dass restic beim Initieren ein Passwort anfordert), aber das ist nur meine Meinung zur letzten Antwort von

Verwenden Sie in der Zwischenzeit ein Dummy-Passwort :) Ich würde vermuten, dass eine ordnungsgemäße Implementierung die Möglichkeit beinhaltet, ein Passwort/einen Schlüssel, der zuvor zum Initieren des Repositorys verwendet wurde, zu entfernen/aufzuheben, sodass man nicht das gesamte Repository neu erstellen muss.

Verschlüsselung ist jedoch eine andere Sache und wird in diesem anderen Problem verfolgt.

Ich kümmere mich nicht so sehr um eine Option ohne Passwort, aber Sie argumentierten für standardmäßig keine Verschlüsselung:

Passwortschutz und Verschlüsselung könnten daher nur als Optionen bereitgestellt werden und sollten nicht standardmäßig vorhanden sein.

Übrigens: Standardeinstellungen sind das Zeichen für Softwarequalität.

was ich gefährlich finde.

Obwohl ich den Punkten von @rawtaz im Allgemeinen zustimme, habe ich keinen allzu großen Anteil daran, wenn es sich bei der Diskussion ausschließlich um eine Option ohne Passwort handelt (die Standardeinstellung wird nicht geändert).

@cfbao

Ich kümmere mich nicht so sehr um eine Option ohne Passwort, aber Sie argumentierten für standardmäßig keine Verschlüsselung:

Passwortschutz und Verschlüsselung könnten daher nur als Optionen bereitgestellt werden und sollten nicht standardmäßig vorhanden sein.

Sie können sogar in diesem Zitat sehen, dass die "Optionen" an erster Stelle stehen und "Standard" als nächstes. Und das ist wieder der Punkt.

In diesem Fall (Problem) ist es ziemlich einfach - es wird wahrscheinlich ein --no-password oder ähnliches Flag für restic init (wobei die Standardeinstellung immer noch so ist, dass restic beim Initieren ein Passwort anfordert), aber das ist nur meine Meinung zur letzten Antwort von

Verwenden Sie in der Zwischenzeit ein Dummy-Passwort :) Ich würde vermuten, dass eine ordnungsgemäße Implementierung die Möglichkeit beinhaltet, ein Passwort/einen Schlüssel, der zuvor zum Initieren des Repositorys verwendet wurde, zu entfernen/aufzuheben, sodass man nicht das gesamte Repository neu erstellen muss.

Eine wahrscheinlich einfachere Lösung wäre, dass restic ein Dummy-Passwort unterstützt, das versucht, ein vorhandenes Repository zu öffnen, wenn vom Benutzer kein Passwort angegeben wird.

Zum Umgang mit Dummy-Passwörtern: Es gibt kein klares bestes Dummy-Passwort, das für alle funktioniert. 1234 ist ein nerviges Dummy-Passwort, da es vier Finger erfordert, um sich nach oben zu bewegen und einzugeben. "asdf" ist zum Beispiel viel schneller zu tippen. Außerdem schränken einige Dienste die Passwortauswahl ein, sodass nur Zahlen oder nur vier Ziffern möglicherweise nicht möglich sind. Daher wäre eine Lösung innerhalb von restic am benutzerfreundlichsten. Dann müssten die Benutzer das Dummy-Passwort nur einmal eingeben.

Aus Sicherheitsgründen ist es keine gute Idee, ein beliebiges Dummy-Passwort bereitzustellen.

IFF jemand die Verschlüsselung unbedingt umgehen will oder nicht braucht, einfach ein einheitliches Passwort mitgeben. Sie müssen es nicht eingeben, Sie können ein Skript schreiben, um restic und harten Code nach Herzenslust einzuschließen. Ist das wirklich mehr Arbeit, als die Repository-Adresse oder andere Konfigurationsoptionen anzugeben?

Ein restriktives Ausprobieren einer Reihe von falschen oder falschen hartcodierten Passwörtern ist nur Ärger. Was ist, wenn eine arme Seele zufällig eines Ihrer vorgeschlagenen "magischen" Passwörter wählt? Warnen wir sie davor, unsere speziellen falschen, gefälschten Verschlüsselungspasswörter zu wählen? "Nein Ted, du kannst SPACECHICKEN nicht als dein Repository-Passwort wählen, es ist _special_." ;)

Ich finde es gut, Benutzern die Möglichkeit zu geben, sich selbst in den Fuß zu schießen ("--no-repository-password"), aber ich denke nicht, dass restic weiter gehen sollte, um die sehr kleine Gruppe von Benutzern zu besänftigen Wunsch REDUZIERTE Sicherheit.

Aus Sicherheitsgründen ist es keine gute Idee, ein beliebiges Dummy-Passwort bereitzustellen.

Warum ist es schlimmer, als kein Passwort zuzulassen?

IFF jemand die Verschlüsselung unbedingt umgehen will oder nicht braucht, einfach ein einheitliches Passwort mitgeben. Sie müssen es nicht eingeben, Sie können ein Skript schreiben, um restic und harten Code nach Herzenslust einzuschließen. Ist das wirklich mehr Arbeit, als die Repository-Adresse oder andere Konfigurationsoptionen anzugeben?

Ja, es ist mehr Arbeit. Restic wäre die Backup-Lösung und seine Ausgabe ist das Repository. Im Idealfall würde das Repository also alles enthalten, um das Backup wiederherzustellen. Wenn Sie jedoch ein Wrapper-Skript verwenden, das das Dummy-Passwort hartcodiert, muss dieses Skript von etwas anderem gesichert werden, sonst wäre das Repository nutzlos.

Ein restriktives Ausprobieren einer Reihe von falschen oder falschen hartcodierten Passwörtern ist nur Ärger. Was ist, wenn eine arme Seele zufällig eines Ihrer vorgeschlagenen "magischen" Passwörter wählt? Warnen wir sie davor, unsere speziellen falschen, gefälschten Verschlüsselungspasswörter zu wählen? "Nein Ted, du kannst SPACECHICKEN nicht als dein Repository-Passwort wählen, es ist _special_." ;)

Was genau ist das Problem? Ted kann dieses Passwort immer noch wählen. Es bedeutet nur, dass restic es bequemerweise verwendet, wenn es nicht angegeben wird. Restic würde das Repository immer noch auf die gleiche Weise verschlüsseln/entschlüsseln, als ob es kein spezielles Passwort wäre.

Ich finde es gut, Benutzern die Möglichkeit zu geben, sich selbst in den Fuß zu schießen ("--no-repository-password"), aber ich denke nicht, dass restic weiter gehen sollte, um die sehr kleine Gruppe von Benutzern zu besänftigen Wunsch REDUZIERTE Sicherheit.

Dies als "sich selbst in den Fuß schießen" zu bezeichnen, ist unnötig wertend und bedeutet auch keine verminderte Sicherheit. Verfügbarkeit und Widerstandsfähigkeit gegen Ransomware sollten Teil eines Sicherheitskonzepts sein. Die fehlende Möglichkeit, eine Sicherung wiederherzustellen, weil der Zugriff auf das Verschlüsselungskennwort fehlt, würde die Sicherheit verringern. Das sichere Speichern des Backups auf einem Nur-Anhängen-Speichersystem würde das Sicherheitsniveau hier nicht verringern.

Why is it worse than allowing no password?

Ich bin mir nicht sicher, wie ich jemanden davon überzeugen soll, dass hartcodierte, versteckte, heimlich gegen Repository-Passwörter getestete Kennwörter eine schlechte Idee wären. Wenn Sie denken, dass dies der Fall ist, gibt es wahrscheinlich kein sicherheitsorientiertes Argument, das Sie überzeugen würde.

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.

Ich habe ein unterhaltsames Beispiel gewählt, das ich vielleicht nicht hätte tun sollen. Nehmen wir an, Ihr Dummy-Passwort, das restic heimlich und automatisch versuchen soll, wenn die Entschlüsselung fehlschlägt, lautet: "12345". Ein naiver Benutzer könnte das sehr wohl als Passwort wählen. Jetzt haben sie ein Repository, von dem sie glauben, dass es verschlüsselt ist (und das auch irgendwie ist), aber _jeder_restic kann entschlüsseln. Dieses Argument gilt für jeden beliebigen Satz von Passwörtern, den Sie in Ihrem hartcodierten Satz wählen. Dies ist ein grundsätzlich schlechtes Sicherheitsdesign.

Es gibt einen Begriff für das, was Sie vorschlagen. Es wird eine Verschlüsselungs-Backdoor genannt :) Das Verstecken dieser Backdoor in den Dokumenten setzt voraus, dass alle Leser das Handbuch vollständig lesen, bevor sie restic verwenden. Würde es nicht den Bedürfnissen von mehr Menschen dienen, sie dazu zu bringen, die Dokumente zu lesen, um festzustellen, wie sie die Sicherheit verringern können, sollten sie dies seltsamerweise wünschen?

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.

Wenn Sie die Verschlüsselung im Ruhezustand nicht für eine solide Sicherheitsrichtlinie halten und sich für etwas anderes entscheiden würden, sind Sie sicherlich in der tiefen Minderheit. Diese Art von unsicheren Ausfällen dient niemandem und sollte zu jedem Zeitpunkt entmutigt werden. In diesem Fall braucht man nur JEDE Sicherheitsreferenz zu Rate zu ziehen. Mein Punkt ist nicht der strittige - ich argumentiere mit der branchenüblichen Praxis.

Sogar Ihr Beispiel für das Anhängen von Speichermedien würde stark von der Verschlüsselung im Ruhezustand profitieren. Ich würde dringend empfehlen, einen aktuellen Satz von NIST, ISO 27002, NERC, IEC 62443 oder wirklich alle weltweit anerkannten Standards zu lesen, um hier eine Anleitung für bewährte Verfahren zu erhalten. Wir sind kein Neuland.

Ich sollte auch darauf hinweisen, dass wir in diesem Thread effektiv zwei Themen miteinander vermischen: Schlüsselverwaltung und Verschlüsselung.

Vielleicht entsteht hier die Verwirrung.

Vielleicht kann dieses Problem durch eine Dokumentation gelöst werden, die etwa Folgendes sagt:

Wenn Sie Ihr Repository nicht mit einem Passwort sichern möchten, verwenden Sie einfach die Zeichenfolge: password

Auf diese Weise gibt es einen bekannten Weg, um Backup/Restore mit Restic zu erreichen, ohne Schlüssel verwalten zu müssen.

Why is it worse than allowing no password?

Ich bin mir nicht sicher, wie ich jemanden davon überzeugen soll, dass hartcodierte, versteckte, heimlich gegen Repository-Passwörter getestete Kennwörter eine schlechte Idee wären. Wenn Sie denken, dass dies der Fall ist, gibt es wahrscheinlich kein sicherheitsorientiertes Argument, das Sie überzeugen würde.

Ich schätze, da fehlt ein "nicht"...

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.

Ich habe ein unterhaltsames Beispiel gewählt, das ich vielleicht nicht hätte tun sollen. Nehmen wir an, Ihr Dummy-Passwort, das restic heimlich und automatisch versuchen soll, wenn die Entschlüsselung fehlschlägt, lautet: "12345". Ein naiver Benutzer könnte das sehr wohl als Passwort wählen. Jetzt haben sie ein Repository, von dem sie glauben, dass es verschlüsselt ist (und das auch irgendwie ist), aber _jeder_restic kann entschlüsseln. Dieses Argument gilt für jeden beliebigen Satz von Passwörtern, den Sie in Ihrem hartcodierten Satz wählen. Dies ist ein grundsätzlich schlechtes Sicherheitsdesign.

Ich habe nicht vorgeschlagen, es zu versuchen, wenn die Entschlüsselung fehlschlägt, aber kein Kennwort für die Entschlüsselung angegeben ist. Wenn jemand ein unsicheres Passwort wählt, ist es unsicher, unabhängig davon, ob es direkt von restic oder von jemandem mit Brute-Forcing-Passwörtern versucht wird. "12345" ist heutzutage auch ein unsicheres Passwort, und es würde sich nicht ändern, wenn es das Standardpasswort für restic würde.

Es gibt einen Begriff für das, was Sie vorschlagen. Es wird eine Verschlüsselungs-Backdoor genannt :) Das Verstecken dieser Backdoor in den Dokumenten setzt voraus, dass alle Leser das Handbuch vollständig lesen, bevor sie restic verwenden. Würde es nicht den Bedürfnissen von mehr Menschen dienen, sie dazu zu bringen, die Dokumente zu lesen, um festzustellen, wie sie die Sicherheit verringern können, sollten sie dies seltsamerweise wünschen?

Eine Verschlüsselungs-Backdoor wäre, wenn restic beim Verschlüsseln von Daten zusätzlich zum vom Benutzer bereitgestellten Passwort ein Standardpasswort verwendet. Mein Vorschlag ist, ein Passwort bei der Entschlüsselung auszuprobieren. Der Benutzer würde dieses falsche Passwort immer noch aktiv wählen.

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.

Wenn Sie die Verschlüsselung im Ruhezustand nicht für eine solide Sicherheitsrichtlinie halten und sich für etwas anderes entscheiden würden, sind Sie sicherlich in der tiefen Minderheit. Diese Art von unsicheren Ausfällen dient niemandem und sollte zu jedem Zeitpunkt entmutigt werden. In diesem Fall braucht man nur JEDE Sicherheitsreferenz zu Rate zu ziehen. Mein Punkt ist nicht der strittige - ich argumentiere mit der branchenüblichen Praxis.

Was ist Ihrer Meinung nach der unsichere Standard?

Sogar Ihr Beispiel für das Anhängen von Speichermedien würde stark von der Verschlüsselung im Ruhezustand profitieren. Ich würde dringend empfehlen, einen aktuellen Satz von NIST, ISO 27002, NERC, IEC 62443 oder wirklich alle weltweit anerkannten Standards zu lesen, um hier eine Anleitung für bewährte Verfahren zu erhalten. Wir sind kein Neuland.

At-Rest-Verschlüsselung bedeutet nicht, dass Restic dies tun muss. Der Nur-Append-Speicher kann bei Bedarf noch anderweitig verschlüsselt werden. Trotzdem wird es einen unverschlüsselten Speicher geben, auch wenn es nur für das Passwort ist. Andernfalls würde das Backup-Konzept darauf angewiesen sein, dass sich jemand immer an das Passwort erinnert.

diesen Thread abbestellen...

Belassen wir es dabei, es ist klar, dass einige Leute eine Option --no-password für init , und darum geht es in dieser Ausgabe. Verschlüsselung oder nicht ist ein separates Thema.

Hier nur ein kurzer Kommentar:
Ich bin ein Benutzer, der sich nicht um Verschlüsselung kümmert. Meine Daten sind nicht sensibel. Ich interessiere mich dafür, dass Leute in 20-40 Jahren gebrauchen können, die nicht ich sind. Die bloße Verwendung von rclone ist eine weitere schlechtere Alternative.

Restic scheint dafür ein gutes Werkzeug zu sein, außer dass ich die Verschlüsselung und ein Passwort vorschreiben muss, die ich berücksichtigen muss. Vielleicht eine README im Backup-Repository. Es ist mehr Arbeit und jede Lösung (von meiner Seite) besiegt sowieso jede Verschlüsselung.

markieren

Vielen Dank für Ihre Beiträge, ich denke, wir haben genug Informationen gesammelt.