Restic: Autoriser les mots de passe vides

Restic devrait autoriser les mots de passe vides.

Pouvez-vous préciser quel est votre cas d'utilisation ? Pourquoi restic devrait-il autoriser les mots de passe vides ?

c'est une décision de conception.

En effet, ça l'est. Mais je suis curieux de savoir ce que vous essayez de réaliser.

Un problème connexe est peut-être #1018

Je voulais juste sauvegarder temporairement certains répertoires sur mon système local comme filet de sécurité rapide lors de la modification de fichiers dans un répertoire. Je ne voulais pas me souvenir d'une phrase secrète ou être dérangé pour entrer une phrase secrète à chaque fois que je veux créer une sauvegarde. Étant donné que je viens d'utiliser a comme mot de passe, il n'y a aucun avantage réel en matière de sécurité à utiliser ce mot de passe par rapport à ne pas utiliser de mot de passe du tout. Par conséquent, toute faible surcharge à mémoriser ou à saisir un mot de passe inutile rend l'outil moins parfait.

Merci pour l'explication. J'aimerais garder ce contrôle en place, donc je ferme ce problème pour l'instant. N'hésitez pas à ajouter d'autres commentaires. Merci!

Lorsque nous en avons parlé il y a quelque temps, vous avez dit qu'il y aurait une discussion...
Pouvez-vous peut-être expliquer pourquoi vous considérez ce contrôle comme utile ? Le référentiel doit toujours être crypté afin qu'un mot de passe puisse être ajouté par la suite.

Je considère cette vérification utile car d'après mon expérience, la plupart des utilisateurs voudront définir un mot de passe. Accepter un mot de passe vide, ou même avoir un chemin de code qui permet d'accepter des mots de passe vides, peut conduire les utilisateurs à enregistrer accidentellement leurs sauvegardes sur des emplacements distants sans cryptage approprié. Une situation où cela peut se produire est lorsque la variable d'environnement RESTIC_PASSWORD n'est pas exportée ou définie accidentellement sur la chaîne vide.

Donc, dans ce cas, il me semble que protéger les utilisateurs d'une erreur est mieux que de supprimer le petit inconvénient d'avoir à définir un mot de passe :)

Il existe cependant des solutions simples pour cela : utilisez un gestionnaire de mots de passe, utilisez la chaîne test , exportez RESTIC_PASSWORD manière statique via un fichier, par exemple dans /etc/profile.d , utilisez le nom du répertoire que vous 'enregistrez (ou le référentiel) en tant que mot de passe ...

Veuillez noter que la connaissance de votre mot de passe est nécessaire pour accéder au référentiel.
La perte de votre mot de passe signifie que vos données sont irrémédiablement perdues.

Comment puis-je empêcher que cela se produise si je ne veux pas perdre mes données pour toujours ?

@LexSong Utilisez un gestionnaire de mots de passe.

Le mardi 03 juillet 2018 à 09:56:56 -0700, Chenfeng Bao a écrit :

@LexSong Utilisez un gestionnaire de mots de passe.

Comment proposez-vous de sauvegarder la base de données du gestionnaire de mots de passe ? Est-ce que tu
propose ici d'utiliser un gestionnaire de mots de passe avec une base de données sans
le mot de passe? Quel gestionnaire de mots de passe prend en charge restic pour obtenir le
mot de passe de ?

La gestion des mots de passe est un sujet énorme que je ne veux pas entrer dans trop de détails dans ce fil. Soulignant simplement que si cela est fait correctement, les mots de passe ne devraient pas être un casse-tête. Il existe de nombreuses ressources en ligne.

La base de données d'un gestionnaire de mots de passe doit déjà être correctement cryptée, vous pouvez donc la placer où vous le souhaitez sans autre couche de cryptage. Il existe également de nombreux services de gestion de mots de passe basés sur le cloud, vous n'avez donc pas à vous soucier des sauvegardes vous-même.

En ce qui concerne la prise en charge de restic, vous pouvez simplement mettre le mot de passe dans un fichier en texte brut localement et utiliser l'option --password-file . Ensuite, vous n'avez pas besoin d'entrer le mot de passe manuellement. Le mot de passe lui-même doit également être placé dans le gestionnaire de mots de passe pour enregistrement.

En fin de compte, il y a toujours un mot de passe/phrase de passe complexe que vous devez mémoriser pour garder les choses vraiment sécurisées.

En fait, si vous ne voulez vraiment pas de mot de passe sur un référentiel restic, pourquoi ne pas simplement utiliser un mot de passe factice à un caractère ?

L'utilisation de 'a' comme mot de passe était en fait ma solution de contournement, mais cela ne semble pas approprié car je ne suis pas sûr de me souvenir de l'avoir utilisé lorsque je revois ce référentiel pour une raison quelconque dans quelques années au cas où j'oublierais de le supprimer quand Je n'en ai plus besoin. Par conséquent, je devrais peut-être implémenter une sorte de forçage brutal pour le comprendre. C'est tout un travail qui pourrait être évité.

Dans le passé, j'utilisais déjà de simples mots de passe temporaires dans des situations qui me laissaient dans cet état lorsque je protégeais temporairement un disque dur externe avec un mot de passe pour faciliter sa suppression par la suite. Cependant, je ne l'ai pas supprimé, donc lorsque je voulais l'utiliser la prochaine fois, je voulais m'assurer qu'il n'y avait rien d'important sur le lecteur. Malheureusement, le mot de passe de mon gestionnaire de mots de passe ne fonctionnait plus car j'avais oublié de le mettre à jour/supprimer à partir de là. Par conséquent, lorsque je pense à mon futur moi, il semble que ce soit une bonne idée de lui faciliter la tâche en ne créant pas de repères statiques que je ne peux pas décrypter.

J'ai une autre idée, que diriez-vous de restic essaierait d'utiliser "restic" comme mot de passe par défaut lorsqu'aucun mot de passe pour accéder à un référentiel et reviendrait à un message d'erreur si cela ne fonctionne pas? Ensuite, les utilisateurs pourraient utiliser ce mot de passe pour indiquer qu'ils n'ont pas besoin de cryptage et restic l'ouvrirait sans magie supplémentaire.

Je suis d'accord avec les commentaires précédents pour garder le contrôle de la protection contre les erreurs de l'utilisateur.

Restic doit prendre en charge les mots de passe vides pour les raisons déjà indiquées. je
spécifiquement je ne veux pas chiffrer mes sauvegardes locales parce que je ne veux pas
d'en perdre l'accès. Je ne veux pas risquer d'oublier le mot de passe et
ne pas pouvoir restaurer les données. Il s'agit d'un risque réel car les utilisateurs
restaurent très rarement et exécutent souvent des sauvegardes sans surveillance pour lesquelles ils ne
besoin d'entrer le mot de passe, le rendant plus susceptible d'être oublié.

Le stockage du mot de passe dans un fichier ou un script est une solution de contournement sujette aux erreurs pour un
problème qui ne devrait pas exister.

J'accepte que des précautions soient prises pour éviter de télécharger accidentellement
données non cryptées vers des référentiels distants.

Il semble qu'une solution simple serait d'avoir une option de ligne de commande,
--allow-empty-password . Les utilisateurs peuvent définir ce commutateur dans leurs scripts et
la valeur par défaut pourrait rester pour exiger un mot de passe.

Il s'agit d'un risque réel car les utilisateurs restaurent généralement très rarement et exécutent souvent des sauvegardes sans surveillance pour lesquelles ils n'ont pas besoin d'entrer le mot de passe, ce qui le rend plus susceptible d'être oublié.

De tels mots de passe de sauvegarde ne sont pas destinés à être mémorisés. Le seul mot de passe de cryptage complexe que vous devez retenir est celui de votre gestionnaire de mots de passe, que vous utiliserez souvent. Et vous devriez vraiment utiliser un gestionnaire de mots de passe.

Le stockage du mot de passe dans un fichier ou un script est une solution de contournement sujette aux erreurs pour un problème qui ne devrait pas exister.

Désolé, je ne vois pas en quoi c'est une solution de contournement sujette aux erreurs. Cela me semble être un moyen tout à fait valable d'automatiser le cryptage. Le problème est résolu, encore une fois, en utilisant un gestionnaire de mots de passe.

Il semble qu'une solution simple serait d'avoir une option de ligne de commande, --allow-empty-password . Les utilisateurs peuvent définir ce commutateur dans leurs scripts et la valeur par défaut peut rester pour exiger un mot de passe.

Cela semble être un moyen raisonnable d'éviter les erreurs de l'utilisateur. Cependant, des inquiétudes subsistent concernant l'augmentation de la surface d'attaque et doivent être traitées avec le plus grand soin.

De tels mots de passe de sauvegarde ne sont pas destinés à être mémorisés. Le seul mot de passe de cryptage complexe que vous devez retenir est celui de votre gestionnaire de mots de passe, que vous utiliserez souvent. Et vous devriez vraiment utiliser un gestionnaire de mots de passe.

Un gestionnaire de mots de passe n'est absolument pas une solution valable à ce problème. Tout l'intérêt de faire des sauvegardes est de sauvegarder vos fichiers, ce qui inclut la base de données du gestionnaire de mots de passe ! Comment, alors, récupéreriez-vous le mot de passe du jeu de sauvegarde lorsque le mot de passe est stocké dans le jeu de sauvegarde chiffré ?

Lors de la conception d'un système de sauvegarde, vous devez prévoir le pire des cas, ce qui inclut la restauration lorsque vous n'avez rien d'autre de disponible que votre sauvegarde. Ce que vous faites évidemment est de sauvegarder votre base de données de gestionnaire de mots de passe séparément de vos sauvegardes Restic. C'est bien pour vous , mais ce n'est pas à vous d'imposer ce système aux autres utilisateurs. Et il est absurde de dire qu'un gestionnaire de mots de passe est nécessaire pour utiliser Restic, surtout quand il n'est même pas conçu pour s'intégrer à un. Si c'est le cas, veuillez me montrer la documentation à cet effet.

Restic, comme beaucoup de logiciels, est destiné à permettre aux utilisateurs de répondre à leurs besoins. Vos besoins n'incluent pas un scénario de restauration sans système d'exploitation, rien d'autre que votre sauvegarde Restic. Les besoins des autres utilisateurs le font. Veuillez ne pas leur dicter les besoins des autres.

Cela semble être un moyen raisonnable d'éviter les erreurs de l'utilisateur. Cependant, des inquiétudes subsistent concernant l'augmentation de la surface d'attaque et doivent être traitées avec le plus grand soin.

Quelles préoccupations spécifiques voyez-vous concernant une surface d'attaque accrue causée par l'option --allow-empty-password proposée ?

Cela semble être un moyen raisonnable d'éviter les erreurs de l'utilisateur. Cependant, des inquiétudes subsistent concernant l'augmentation de la surface d'attaque et doivent être traitées avec le plus grand soin.

Mon autre idée était que restic utilise un mot de passe par défaut pour accéder à un référentiel lorsqu'aucun mot de passe n'a été spécifié, par exemple restic . Ensuite, l'interface utilisateur pour créer un nouveau référentiel ne change pas et uniquement lorsqu'un utilisateur utilise le mot de passe par défaut, restic pourra automatiquement accéder au référentiel et l'utilisateur n'a pas besoin de se souvenir du mot de passe.

Désolé, je ne vois pas en quoi c'est une solution de contournement sujette aux erreurs. Cela me semble être un moyen tout à fait valable d'automatiser le cryptage. Le problème est résolu, encore une fois, en utilisant un gestionnaire de mots de passe.

Tant qu'il n'y a pas d'intégration avec le gestionnaire de mots de passe, il existe toujours le risque que la valeur dans le gestionnaire de mots de passe soit erronée, obsolète ou supprimée accidentellement car il y aura une copie du mot de passe en dehors du gestionnaire de mots de passe.

J'aimerais également voir une option permettant d'autoriser un mot de passe vide (via l'utilisation du drapeau --allow-empty-password , ou peut-être quelque chose de plus détaillé/unique pour mettre en évidence le risque, comme le drapeau --dont-blame-nrpe NRPE).

Mes cas d'utilisation :

• Entreprise : nous avons un référentiel contenu dans un environnement de confiance dont nous avons besoin de « n'importe qui » ​​pour pouvoir le restaurer en cas d'urgence/de catastrophe sans avoir à avoir de connaissances particulières (c'est-à-dire un mot de passe de référentiel).
• Accueil : j'aimerais créer une sauvegarde restic de choses comme des photos de famille. Celles-ci ne sont pas particulièrement confidentielles, et dans le cas de mon décès prématuré, ma famille doit pouvoir accéder à ces données personnelles importantes avec un minimum de résistance (_par exemple, sans avoir à trouver une phrase secrète dans un coffre-fort, c'est peut-être hors de date ou confondu avec un autre_).

Je comprends la nécessité d'une phrase secrète pour assurer l'intégrité des données ainsi que le cryptage. Je vois que le ou les fichiers du répertoire keys semblent être un objet JSON. Peut-être qu'une clé pseudo-aléatoire pourrait être générée (plutôt qu'aucune clé) et stockée là-dedans ? Cela n'aide cependant pas les utilisateurs qui essaient d'éviter la surcharge du chiffrement pour des raisons de performances.

@fd0 Que pensez-vous de l'option de ligne de commande --allow-empty-password proposée ? Cela nécessiterait des phrases secrètes par défaut, mais permettrait aux utilisateurs de les remplacer si nécessaire.

Et s'il vous plaît envisager de rouvrir ce problème. Les besoins de nombreux utilisateurs incluent la sauvegarde de fichiers non confidentiels sans risque de perdre l'accès en raison de mots de passe oubliés ou égarés.

Tout nouvel utilisateur restic ici - je n'ai même pas encore créé mon premier référentiel - mais des années d'expérience avec d'autres outils - mon préféré étant le bon vieux "dump". Avec respect, c'est une évidence - bien sûr, les mots de passe vides devraient être autorisés. Ajoutez certainement un indicateur pour minimiser le risque d'erreur accidentelle, mais veuillez ne pas dicter de cas d'utilisation à des utilisateurs (potentiels) expérimentés qui ont clairement indiqué d'autres besoins.
Tout ce que j'essaie de faire, c'est de faire des sauvegardes locales pour plus de sécurité ; la sécurité n'est pas un problème, et je suis beaucoup plus susceptible de perdre la trace du mot de passe que d'avoir besoin de la sauvegarde. Et je déteste les gestionnaires de mots de passe...

L'exigence d'un mot de passe rend difficile l'automatisation des sauvegardes, et le fait de devoir fournir le mot de passe dans un fichier env ou un fichier de script rend l'ensemble de la sécurité inutile en premier lieu.

avoir besoin de fournir le mot de passe dans un fichier env ou un fichier de script rend toute chose de sécurité inutile en premier lieu.

Ce n'est pas nécessairement vrai. Il existe de bonnes façons de le faire.

Ce n'est pas nécessairement vrai. Il existe de bonnes façons de le faire.

Veuillez ne pas ressasser cet argument ici. De nombreux utilisateurs doivent effectuer des sauvegardes non cryptées ou avec un mot de passe vide. Si vous n'êtes pas l'un d'entre eux, tant mieux pour vous.

@mholt , des recommandations ? Je serais plus qu'heureux de sauvegarder mes serveurs sans aucune interférence avec une sécurité maximale.

De nombreux utilisateurs doivent effectuer des sauvegardes non cryptées ou avec un mot de passe vide.

Il s'agit généralement d'un problème XY .

@mholt , des recommandations ? Je serais plus qu'heureux de sauvegarder mes serveurs sans aucune interférence avec une sécurité maximale.

Cela dépend fortement de votre situation spécifique, du modèle de menace, de l'environnement, des risques acceptables et des objectifs techniques et de convivialité. Donc non, je n'ai pas d'ensemble général de recommandations pour qui que ce soit.

Il s'agit généralement d'un problème XY.

Donc non, je n'ai pas d'ensemble général de recommandations pour qui que ce soit.

Cette attitude condescendante n'est pas utile. Bien pire qu'après nous avoir dit que nos besoins sont erronés, vous refusez ensuite de donner des conseils. Il s'agit d'un projet FOSS, pas d'Apple, Inc.

Par exemple, je n'ai ni besoin ni envie de crypter mes sauvegardes locales de mes données déjà non cryptées. Si mon disque principal tombe en panne et que je dois récupérer mes sauvegardes, la phrase secrète est stockée dans le référentiel de sauvegarde avec mes scripts de sauvegarde et mes fichiers de configuration. Ma principale préoccupation n'est pas d'empêcher les autres d'accéder à ces données non sensibles - ma principale préoccupation est une récupération facile et le fait de ne pas être verrouillé sur mes données.

C'est un cas courant pour de nombreux utilisateurs, et ce n'est pas à vous de décider quels sont les besoins des utilisateurs.

Le logiciel existe pour servir les utilisateurs, pas pour forcer les utilisateurs à acquiescer à ses exigences.

Merci d'avoir expliqué votre (vos) cas d'utilisation et vos inquiétudes à nouveau. Pour mémoire, je pense qu'ils sont valides, en particulier celui du "mot de passe perdu". Je pense également qu'un indicateur spécial pour restic init comme --allow-empty-password fonctionnerait (j'ai quelques considérations pour les cas extrêmes, mais je suis convaincu qu'ils peuvent être résolus). Je vais donc rouvrir ce sujet.

Veuillez noter que le fait d'autoriser les mots de passe vides résoudra le problème de sécurité du « mot de passe perdu », mais cryptera toujours toutes les données comme d'habitude.

Sur une note différente, je n'aime pas du tout le ton de ce fil. Vous êtes libre de ne pas utiliser restic, c'est parfaitement bien. La plupart d'entre nous travaillons sur restic pendant notre temps libre. Certains commentaires de ce fil semblent très intitulés, paraphrasés : "vous devez implémenter cette fonctionnalité, il y a des utilisateurs qui en ont besoin !". Ce n'est pas le cas. Nous pouvons l'envisager et le mettre en œuvre, mais nous pouvons aussi décider de ne rien faire.

Alors, s'il vous plaît, tout le monde, gardons cette discussion productive, même si vous n'êtes pas d'accord. :)

@fd0 Pardonnez-moi de ne pas être clair. Je n'exige ni n'attend quoi que ce soit de vous ou des développeurs Restic. C'est votre projet et votre temps, et vous pouvez travailler sur ce que vous voulez.

Ce que je demande, c'est que vous considériez cette fonctionnalité et ce cas d'utilisation. Si vous n'êtes pas intéressé à le mettre en œuvre vous-même, c'est très bien, et je vous demande de laisser le problème ouvert afin que d'autres puissent en discuter, et que vous considériez tout PR qui pourrait le mettre en œuvre.

Ce à quoi je m'oppose, ce sont les commentaires (pas les vôtres) qui suggèrent que les utilisateurs qui souhaitent cette fonctionnalité ne comprennent pas leurs propres besoins, en particulier lorsqu'ils sont suivis d'un refus de proposer des alternatives. C'est un bruit grossier et inutile.

Pour moi, j'utilise git-annex avec une télécommande spéciale bup. Annex prend déjà en charge le cryptage des fichiers (que j'ai désactivé pour utiliser la fonction de déduplication de bup). Et puis je sauvegarde le référentiel bup (qui n'est qu'un référentiel git sophistiqué) sur un serveur distant. Je peux ensuite supprimer le référentiel bup, car il ne s'agit que d'un cache, et effectuer une restauration via restic, si nécessaire.

Donc, en gros, j'assemble un tas d'outils à usage unique, à la manière Unix (tm), car chacun fait bien son travail. Restic (je passe actuellement de la duplicité) effectue la déduplication par blocs à fenêtres coulissantes vers un cloud distant, et c'est tout ce dont j'ai besoin. Le chiffrement et la déduplication des blocs locaux se produisent à une couche différente. Donc, je ne veux pas avoir de mot de passe spécifié, ni de cryptage (qui économise en fait sur l'utilisation du processeur).

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

Ce n'est que la moitié de ce que je veux, car il crypte toujours, mais avec un mot de passe vide. J'aimerais récupérer cette utilisation du processeur, si je le pouvais.

Veuillez noter que le fait d'autoriser les mots de passe vides résoudra le problème de sécurité du « mot de passe perdu », mais cryptera toujours toutes les données comme d'habitude.

Hm, quelle est la motivation derrière le cryptage avec un mot de passe vide ?

Je veux dire, lors de l'exécution de restic sur du matériel de faible puissance, le cryptage ajoute une surcharge notable à l'exécution.

Edit: Ok, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - en particulier le 2ème point répond à ma question.

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

Le principal problème avec cette suggestion est le suivant : cela ne fonctionne tout simplement pas, restic demande un mot de passe de manière interactive puis :

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

Merci, @fd0 , pour la réouverture du problème. Je suis d'accord avec @alphapapa , mon intention n'est pas de pousser les développeurs de temps libre à passer leur temps sur tout ce avec quoi ils ne s'amusent pas.

Nous n'aimons tout simplement pas que les autres nous disent que nous ne comprenons pas nos propres besoins.

À mon avis, la caractéristique la plus importante d'un outil de sauvegarde est la possibilité d'effectuer une restauration dans tous les cas. Bien que la sécurité ait une importance très, très élevée, cela dépend de la situation spécifique si la sécurité des données (capacité de restauration) ou la sécurité des données (protection contre les accès non autorisés) a une priorité plus élevée.

Bien sûr, vous pouvez librement décider de développer un outil uniquement pour les situations où la sécurité est plus importante que la sûreté.

Comme @mholt l'a mentionné "XY-Problem": La demande est de pouvoir effectuer une reprise après sinistre sans aucune connaissance au-delà d'une documentation restic générique disponible au public et bien sûr d'un accès au référentiel lui-même.
"Sans aucune connaissance" exclut le besoin ou l'utilisation de gestionnaires de mots de passe.

La raison pour laquelle j'ai trouvé ce problème est la suivante : _J'aide certaines personnes avec leur PC en privé. Leur gestion des mots de passe est un gâchis, essayer de leur apprendre à gérer correctement les mots de passe lors de la configuration d'une sauvegarde sur des lecteurs USB ne fera que ne pas créer de sauvegardes du tout ou ne pas avoir de mot de passe disponible en cas de besoin. Ils peuvent obtenir l'aide de quelqu'un d'autre lorsqu'ils ont besoin d'une restauration, donc tout ce que je propose pour atténuer la situation pourrait être nul._

En ce moment, j'enregistre le mot de passe dans un fichier texte sur la même clé USB que le référentiel de sauvegarde restic, ce qui gâche complètement la sécurité d'avoir un mot de passe.
Et je n'aime pas cette solution car l'utilisation d'un mot de passe qui ne donne aucune couche de sécurité supplémentaire donne une très mauvaise idée de la sécurité.

Bien sûr, je ne parle ici que des sauvegardes locales personnelles. Pour les serveurs, je recommande des mots de passe forts copiés dans un stockage hors ligne séparé.

Je pense qu'un autre problème est ici ; si certains frameworks/API autorisent les mots de passe vides et d'autres non. Et il faut déchiffrer une entrée qui a été chiffrée par une autre API avec un mot de passe vide. C'est actuellement mon problème avec https://github.com/RNCryptor/JNCryptor

Alors, s'il vous plaît, tout le monde, gardons cette discussion productive, même si vous n'êtes pas d'accord. :)

Après avoir lu ce fil, je trouve la conversation productive, car le résultat a été positif.

J'aimerais rappeler à tout le monde qu'il s'agit de Github - si quelque chose vous tient à cœur et que le mainteneur du projet n'est pas réceptif, n'hésitez pas à faire un fork - cela prend littéralement quelques secondes. Si vous n'avez pas les compétences nécessaires pour effectuer le changement vous-même, demandez aux autres de vous aider. Vous constaterez que les responsables peuvent être plus ouverts à accepter un correctif qui implémente quelque chose qu'ils n'auraient pas été motivés à implémenter eux-mêmes.

Personnellement, dans ce cas, je pense qu'imposer à tout le monde une idée préconçue de ce que la sécurité "devrait" être est une erreur. La première règle de la sécurité des données est que les données doivent être accessibles à ceux qui ont le droit de les avoir. Toute règle qui compromet la règle n° 1 doit être considérée avec la plus grande prudence.

La sécurité est un sujet qui regorge de politiques FUD et axées sur la peur, entraînant des implémentations naïves, hâtives et souvent hypocrites, car peu d'entre nous aiment réellement penser à tout ce qui peut mal tourner. Encore moins envie de faire face à la critique des autres quand on nous voit permettre que les choses tournent mal.

Quelques erreurs courantes que nous voyons tous les jours :

1) Insistant sur le fait que les données écrites sur un support crypté au repos doivent elles-mêmes être cryptées, même dans un environnement de confiance. Où s'arrête la peur de l'interception ? Par où commencer à croire que l'utilisateur pourrait potentiellement être compétent et que l'ajout de couches redondantes ne fait qu'augmenter le risque de perte de données ?

2) Insister sur un mot de passe d'un format spécifique, c'est-à-dire 8 caractères avec au moins une lettre majuscule, un chiffre et un non alphanumérique - c'était une pratique courante pendant 20 ans et maintenant démystifiée car la douleur dépasse le gain. Au lieu de cela, nous devrions insister sur des mots de passe à xkcdpassword , ou intégrer à un gestionnaire de mots de passe (ce qui rend efficacement tous les consommateurs clés dépendants d'un mot de passe principal SPOF de sécurité partagé qui peut être harponné - il suffit de demander à COMMODO) ou d'intégrer 2FA (potentiellement meilleur en fonction de la sécurité physique du deuxième facteur, dont la redondance des clés N+1).

3) Avec un mot de passe principal - ne pas le mettre en cache dans une session de telle sorte que l'utilisateur est obligé de le saisir tellement de fois au cours de la journée que l'action même de le saisir devient un vecteur d'attaque visible.

4) Avec un mot de passe principal - ne pas vérifier les politiques et demander aveuglément le mot de passe principal de telle sorte que l'utilisateur s'habitue à le présenter alors qu'il ne devrait pas être requis, ce qui l'empêche d'analyser de manière critique s'il doit ou non le fournir dans cette instance.

5) Appliquer une politique de moindre privilège à un point tel que les utilisateurs la détestent et évitent de s'y inscrire, ou trouvent des moyens de la contourner, laissant la porte ouverte beaucoup plus longtemps que s'il existait un schéma plus permissif.

6) L'application d'une politique de moindre privilège sans redondance N+1, c'est-à-dire l'absence de considérations de « continuité d'activité / « politique de l'homme clé ». c'est-à-dire qu'au lieu de verrouiller une ressource partagée derrière 2 clés privées afin qu'elle ne soit accessible que lorsque les deux sont d'accord (quorum de 2), verrouillez-la derrière 2 des 3 clés privées. Personne ne vit éternellement.

Chaque fois que nous, en tant que programmeurs, mettons en œuvre un schéma de cryptage à clé unique, nous devons considérer l'importance de l'accessibilité et entendre les préoccupations de ceux qui sont douloureusement conscients des conséquences de la perte de clé pour un schéma de cryptage à clé unique.

Essayons également de nous rappeler gentiment que retirer des choses aux utilisateurs uniquement par peur d'une mauvaise utilisation est fondamentalement mauvais - comme presque toutes les décisions prises par peur. Punir tout le monde parce que quelqu'un pourrait faire la mauvaise chose, diminue la société dans son ensemble.

Si vous sentez en ce moment que vous n'êtes pas d'accord avec ce concept, respirez profondément, comptez jusqu'à dix, puis réfléchissez à ceci : que devrions-nous faire en tant que société lorsqu'une personne se suicide en mettant sa tête dans un sac poubelle avec une canette de vaporiser de la crème fouettée et inhaler toute la boîte de protoxyde d'azote ? Devrions-nous retirer la crème fouettée en spray à tout le monde ? Sacs en plastique? Respiration? Toutes ces choses pourraient être mal utilisées d'une manière qui entraîne la mort de l'utilisateur.

Au lieu de l'impulsion instinctive de retirer des choses, comme nous le ferions avec un enfant jouant avec des allumettes, nous devrions plutôt pécher par excès d'éducation pour qu'ils utilisent correctement ces choses. Ou élevez la barre d'entrée de telle sorte que seuls ceux qui RTFM le trouveront.

C'est ce qui s'est passé à la fin ici, et la décision d'accepter ce résultat n'est venue que lorsque tous les problèmes et opinions ont déjà été exprimés. Je recommande de regarder les séances de débat parlementaire sur les chaînes de télévision publiques pour des exemples de ce à quoi ressemble un débat improductif, lol. Les participants ici étaient exceptionnellement respectueux les uns envers les autres en comparaison.

Rappelez-vous les anciens bons utilitaires d'archivage où le cryptage et la protection par mot de passe étaient disponibles en tant qu'options explicites uniquement, mais pas par défaut. Et c'est la bonne logique car la sécurité peut avoir beaucoup de solutions externes hors de cette portée utilitaire et parce que ce soin appartient à l'utilisateur. Qu'est-ce que vous faites, c'est simplement fournir les outils de sécurité du choix des utilisateurs. Mais l'auteur préfère faire attention à ce que l'utilisateur ne demande pas pour éviter les abus.

Et encore pour le ton. C'est habituel pour le monde open-source. Et il est soutenu par un mécanisme psychologique. Les critiques que les auteurs ne partagent pas sont traitées comme une prétention à passer leur temps libre. Et à chaque fois, nous devons nous rappeler : nous ne discutons pas ici de votre temps libre, mais nous explorons plutôt votre créature de génie, ses fonctionnalités et la logique qui la sous-tend. Nous n'oublions jamais que vous n'avez aucune obligation de répondre à notre demande et que vous avez le droit de ne rien faire du tout. Mais si vous aimez ce que vous faites, c'est peut-être (peut-être) parce que d'autres l'aiment. Il existe donc un espoir que vous soyez intéressé à répondre à la demande au moins de la majorité.

PS Tout cela ne sont que des discours abstraits et aucune action pratique n'est prévue.

Il y a une chose que je n'ai jamais comprise avec la discussion sur l'interdiction de mot de passe pour un référentiel (en supposant que le contexte @fd0 a écrit plus tôt, que les données seront toujours cryptées); Pourquoi ceux qui "ne veulent pas" de mot de passe n'utilisent-ils pas simplement un mot de passe factice comme "1234" ou autre ? Quel est l'intérêt d'écrire du code en restic qui supprime le mot de passe, alors que si vous ne vous souciez pas d'avoir un mot de passe, vous pouvez simplement utiliser un mot de passe factice ? Il s'agit d'une variable d'environnement ou d'un fichier de mot de passe, si vous pensez qu'il est fastidieux de le saisir sur la ligne de commande lors de l'exécution de restic.

@rawtaz Cela a été répondu dans les commentaires précédents sur ce fil.

Permettez-moi simplement de dire que restic init -r foo --no-password est probablement un meilleur nom de drapeau que restic init -r foo --allow-empty-password , simplement parce que le premier est plus pertinent et le second est tout simplement trop verbeux.

Je ne vois pas de bons arguments pour lesquels l'utilisation d'un mot de passe factice n'est pas un moyen parfaitement viable de le faire au lieu d'augmenter la base de code restic sur ce sujet. J'ai vu quelqu'un dire qu'il pourrait oublier le mot de passe "a". Bien que cela puisse être vrai, il est sûrement possible d'inventer un simple mot de passe factice et de s'en souvenir, ou du moins de le redéfinir en cas de besoin. Mais peu importe, un drapeau fonctionne bien aussi, je suis juste étonné de voir à quel point cela semble être un problème :D

Eh bien, voici un exemple. Fait une sauvegarde restic il y a un an. A scénarisé un
mot de passe factice, lu à partir d'un fichier. Je n'ai pas noté le mot de passe
n'importe où ailleurs. Après un an sans utiliser cette machine, j'ai complètement
oublié à la fois le processus et le mot de passe - et j'ai perdu une heure à essayer de
devinez le mot de passe avant de finalement trouver (et reverse engineering)
le scénario. C'est entièrement de ma faute, mais quand même -- je n'ai pas besoin de la sécurité,
et je ne veux pas être obligé de mémoriser un mot de passe factice. Et si je
n'avais pas eu accès aux fichiers originaux, j'aurais été bloqué.

TD

N'est-ce pas une question d'avoir trop compliqué les choses ? L'un des mots de passe les plus courants est 1234. Utilisez-le et vous n'aurez pas à essayer de le trouver quelque part (en supposant que vous ne pensez pas en avoir utilisé un plus complexe) car lorsque vous devez entrer un mot de passe factice, vous savez que c'est 1234. Mais bien sûr, je vois ce que vous voulez dire.

J'aimerais également voir une option permettant d'autoriser un mot de passe vide (via l'utilisation du drapeau --allow-empty-password , ou peut-être quelque chose de plus détaillé/unique pour mettre en évidence le risque, comme le drapeau --dont-blame-nrpe NRPE).

Mes cas d'utilisation :

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

Je comprends la nécessité d'une phrase secrète pour assurer l'intégrité des données ainsi que le cryptage. Je vois que le ou les fichiers du répertoire keys semblent être un objet JSON. Peut-être qu'une clé pseudo-aléatoire pourrait être générée (plutôt qu'aucune clé) et stockée là-dedans ? Cela n'aide cependant pas les utilisateurs qui essaient d'éviter la surcharge du chiffrement pour des raisons de performances.

• Entreprise : nous avons un référentiel contenu dans un environnement de confiance dont nous avons besoin de « n'importe qui » ​​pour pouvoir le restaurer en cas d'urgence/de catastrophe sans avoir à avoir de connaissances particulières (c'est-à-dire un mot de passe de référentiel).

Mais ces "n'importe qui" ont déjà besoin de connaissances/instructions spéciales. Ils doivent savoir soit comment exécuter restic pour restaurer les données, y compris quel référentiel utiliser et d'autres choses, et il serait alors incroyablement facile d'inclure un mot de passe factice dans ces instructions. Ou ils utiliseraient un script ou une automatisation similaire qui effectue la restauration pour eux (auquel cas ils doivent toujours savoir/obtenir des instructions pour savoir où aller pour utiliser cet outil), auquel cas le mot de passe factice serait géré par le script . Peu importe comment vous regardez cela, un mot de passe factice n'est pas un problème. Et sérieusement, si tout le monde l'oubliait soudainement, les gens pourraient simplement deviner 1234 ou le forcer brutalement. Ce n'est pas un problème :P

• Accueil : j'aimerais créer une sauvegarde restic de choses comme des photos de famille. Celles-ci ne sont pas particulièrement confidentielles, et dans le cas de mon décès prématuré, ma famille doit pouvoir accéder à ces données personnelles importantes avec un minimum de résistance (_par exemple, sans avoir à trouver une phrase secrète dans un coffre-fort, c'est peut-être hors de date ou confondu avec un autre_).

Attends quoi? Pourquoi diable voudriez-vous n'avoir aucun mot de passe, et quand ce n'est pas possible (au moins actuellement), utilisez un mot de passe factice super simple (par exemple 1234), puis mettez ce mot de passe factice super simple dans un coffre -

Enfin, un mot de passe fictif doit être si simple et évident qu'il ne sera pas obsolète, et il n'est pas nécessaire d'avoir plus d'un mot de passe fictif. Il ne doit donc pas être périmé ou mélangé avec un autre.

Oui, ces suggestions ont déjà été faites, alors nous tournons en rond maintenant. Personnellement, ce ne sont pas des solutions adaptées avec lesquelles je suis à l'aise pour mon environnement et mes cas d'utilisation.

Vous n'avez pas besoin de cette fonctionnalité, c'est très bien. Cela ne signifie pas que les cas d'utilisation de tout le monde sont invalides. Je n'ai pas d'utilité pour le backend Amazon S3, mais je ne le déclare pas inutile, je ne l'utilise tout simplement pas. Si cette fonctionnalité est implémentée, cela ne vous coûte rien de ne pas l'utiliser.

Oui, ces suggestions ont déjà été faites, alors nous tournons en rond maintenant.

Ouais, et honnêtement, je n'ai toujours pas vu d'explication réelle sur la raison pour laquelle un mot de passe factice est si difficile à gérer, j'ai l'impression d'en avoir surtout vu des complications excessives.

Personnellement, ce ne sont pas des solutions adaptées avec lesquelles je suis à l'aise pour mon environnement et mes cas d'utilisation.

C'est quelque chose que je respecte totalement. Le cas d'utilisation de chacun est individuel et vous avez votre workflow :)

Je suppose qu'à un moment donné, nous obtiendrons un --no-password ou similaire, j'espère que cela résoudra également ce cas d'utilisation. Merci pour votre contribution!

rawtaz a écrit

Permettez-moi simplement de dire que restic init -r foo --no-password est probablement un meilleur nom de drapeau que restic init -r foo --allow-empty-password , simplement parce que le premier est plus pertinent et le second est tout simplement trop verbeux.

Je ne vois pas de bons arguments pour lesquels l'utilisation d'un mot de passe factice n'est pas un moyen parfaitement viable de le faire au lieu d'augmenter la base de code restic sur ce sujet. J'ai vu quelqu'un dire qu'il pourrait oublier le mot de passe "a". Bien que cela puisse être vrai, il est sûrement possible d'inventer un simple mot de passe factice et de s'en souvenir, ou du moins de le redéfinir en cas de besoin. Mais peu importe, un drapeau fonctionne bien aussi, je suis juste étonné de voir à quel point cela semble être un problème :D

Je ne suis pas préoccupé par l'utilisation/la gestion des mots de passe factices - au lieu de cela, je suis parfois préoccupé par l'utilisation du processeur qui ralentit le processus de sauvegarde par le cryptage obligatoire lorsqu'il s'exécute sur du matériel bas de gamme.

La résolution de #1018 (sauvegardes non cryptées) résoudrait également ce problème - c'est-à-dire avec un commutateur --unencrypted au lieu d' --no-password commutateur

J'ai en fait utilisé restic sur du matériel bas de gamme où le processeur n'avait certainement pas AES-NI (ou une extension similaire) et où la sauvegarde était alors liée au processeur. Dans un autre cas, le processeur était un peu plus puissant, mais le seul disque dur externe disponible était déjà chiffré par LUKS et il était donc lié au processeur car il n'était pas assez puissant pour gérer deux processus de chiffrement en parallèle.

Voir aussi : https://github.com/restic/restic/issues/1018#issuecomment -307549863

Si vous oubliez comment utiliser restic, vous pouvez lire la doc. Si vous oubliez un emplacement de référentiel, vous pouvez le trouver. Ou vous pouvez rencontrer occasionnellement un référentiel orphelin et vous demander ce qu'il y a de sauvegarde à l'intérieur. Mais si vous avez oublié votre mot de passe, vous perdez vos données pour toujours. Et dans la vraie vie, vous pouvez oublier n'importe quel mot de passe factice le plus simple. Vous pouvez oublier tout ce que vous n'utilisez pas souvent.

Si vous perdez le mot de passe root, vous pouvez démarrer avec l'option init=/bin/bash et obtenir un accès complet. Bien que ce trou puisse être fermé, il existe toujours dans la plupart des systèmes. Pourquoi? Parce que la perte de l'indisponibilité serait plus que de l'insécurité dans ces cas. Il s'agit donc d'un compromis entre sécurité et disponibilité. Pour les systèmes avec des exigences plus élevées, des solutions spéciales existent, telles que des clés redondantes, offrant à la fois sécurité et disponibilité.

resitc n'est pas un outil de sécurité. C'est un outil de sauvegarde. Et en tant que tel, il devrait d'abord fournir lui-même une fonctionnalité de sauvegarde, et ensuite seulement la sécurité. Ainsi, la protection par mot de passe et le cryptage pourraient être fournis en option uniquement et ne devraient pas être en place par défaut.

BTW : les valeurs par défaut sont la marque de la qualité du logiciel.

@vstavrinov Veuillez lire l'introduction à restic avant de dire que ce n'est pas un outil de sécurité. C'est un outil de sauvegarde dont l'une des principales caractéristiques est qu'il essaie de sécuriser vos sauvegardes. Donc, vous êtes assez loin quand vous dites qu'il ne s'agit pas de sécurité.

Mais si vous avez oublié votre mot de passe, vous perdez vos données pour toujours.

Oui, et c'est pourquoi vous (dans ce cas, vous avez la possibilité simple d') utiliser un mot de passe factice afin que vous puissiez toujours comprendre le mot de passe même si vous l'oubliez.

Et dans la vraie vie, vous pouvez oublier n'importe quel mot de passe factice le plus simple.

Si vous le faites, vous avez choisi un mot de passe factice trop complexe, et ce n'est plus vraiment un simple mot de passe factice.

Toute cette discussion devient hilarante, franchement. Je ne peux pas croire que les gens disent qu'un mot de passe comme 1234, qui est l'un des plus courants et des plus évidents, est quelque chose qu'ils pourraient oublier et ensuite ne pas être en mesure de comprendre très rapidement (par exemple en essayant juste quelques mots de passe). Je dirais que vous devez faire de gros efforts pour ne pas être en mesure de "deviner" 1234 lorsque vous êtes dans cette situation, et même dans ce cas, vous ne parviendrez probablement pas à ne pas le deviner.

Mais si vous avez oublié votre mot de passe, vous perdez vos données pour toujours.

Wikipedia pourrait vous aider : essayez simplement les mots de passe les plus courants sur https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

Une situation où cela peut se produire est lorsque la variable d'environnement RESTIC_PASSWORD n'est pas exportée ou définie accidentellement sur la chaîne vide.

Il est possible pour le code de vérifier si un mot de passe a été défini sur une chaîne vide explicitement ou simplement non défini (aucune option de ligne de commande spécifiée, variable d'environnement non définie -> différente d'une chaîne vide).

Je pense que le choix devrait être donné à l'utilisateur quel mot de passe il veut choisir.

La résolution de #1018 (sauvegardes non cryptées) résoudrait également ce problème - c'est-à-dire avec un commutateur --unencrypted au lieu de --no-password.

Le cryptage devrait toujours être obligatoire pour se protéger contre la recherche binaire sur un hébergeur indépendamment du format, la transmission sur un canal non crypté avec MITM, etc. Bien que cela vous offre autant de protection qu'un mot de passe vide pour les attaques ciblées (zéro), cela évite toujours les dommages collatéraux sur les attaques non ciblées.

@rawtaz

C'est un outil de sauvegarde dont l'une des principales caractéristiques est qu'il essaie de sécuriser vos sauvegardes. Donc, vous êtes assez loin quand vous dites qu'il ne s'agit pas de sécurité.

Pas loin. Indiquez-moi où je dis "ce n'est pas concerné par la sécurité". Je ne. Vous dites la même chose : "C'est un outil de sauvegarde". La sauvegarde n'est pas la sécurité, n'est-ce pas ?. Restic n'est donc pas un outil de sécurité. Et "... l'une des principales caractéristiques...". Vous avez encore raison : c'est une caractéristique. c'est-à-dire que la sécurité est une caractéristique, tandis qu'une sauvegarde est une désignation fonctionnelle (cible).

@rawtaz

Toute cette discussion devient hilarante, franchement. Je ne peux pas croire que les gens disent qu'un mot de passe comme 1234 ...

Je ne peux rien faire, mais tu as raison dans ce cas aussi. Ce qui est idiot, c'est une discussion sur un mot de passe factice. Mais je pense que le plus important est de comprendre que la protection par mot de passe et le cryptage devraient être facultatifs. En plus de ne pas imposer aux utilisateurs de fonctionnalités indésirables supplémentaires, leur laissant le choix de l'utiliser ou de ne pas l'utiliser. Et c'est aussi la marque de la qualité du logiciel.

Mais je pense que le plus important est de comprendre que la protection par mot de passe et le cryptage devraient être facultatifs.

Pourquoi? Pourquoi « devrait » un outil de sauvegarde ne pas avoir de cryptage par défaut ? Juste parce que c'est un outil de « sauvegarde » ? Tu dis juste ça mais il n'y a aucune raison à tout ça.

Aucune décision de conception ne peut plaire à tout le monde. Restic _choisit_ de mettre fortement l'accent sur la sécurité, et les utilisateurs comme moi _adorent_ que le cryptage fort est la valeur par défaut.

• Si vous ne vous souciez pas de la sécurité, vous _ne pouvez pas_ abuser d'un système sécurisé par défaut. Au pire, vous voyez des erreurs et réessayez avec une commande ajustée.
• Si vous vous souciez de la sécurité, il existe de nombreuses façons d'abuser d'un système non sécurisé par défaut avec un effet catastrophique. Un indicateur manquant, et vos données sensibles sont divulguées, peut-être _irréversiblement_.

C'est une chose de demander un indicateur qui peut omettre le mot de passe, mais plaider pour qu'il n'y ait pas de cryptage par défaut est un dangereux « merde » pour tous les utilisateurs existants qui comptent sur le cryptage de restic. Le potentiel d'erreurs catastrophiques de l'utilisateur est énorme.

@cfbao

Mais je pense que le plus important est de comprendre que la protection par mot de passe et le cryptage devraient être facultatifs.

Pourquoi? Pourquoi « devrait » un outil de sauvegarde ne pas avoir de cryptage par défaut ? Juste parce que c'est un outil de « sauvegarde » ? Tu dis juste ça mais il n'y a aucune raison à tout ça.

"facultatif" n'est pas la même chose que "par défaut". Les valeurs par défaut en tant que telles peuvent être discutables. Mais avoir des options est plus important. Bien que nous n'ayons pas le choix, il n'y a rien à voir avec les valeurs par défaut. C'est le but. Fournissez d'abord des options, puis il est logique de discuter des valeurs par défaut.

Dans ce cas (problème), c'est assez simple - il y aura probablement un indicateur --no-password ou similaire à restic init (la valeur par défaut étant toujours que restic demande un mot de passe lors de l'initialisation), mais c'est juste mon avis sur la dernière réponse de @fd0 . Et il n'y a pas d'ETA à ce stade, pas besoin de demander à ce sujet :)

Pendant ce temps, utilisez un mot de passe factice :) Je suppose qu'une implémentation appropriée inclut la possibilité de supprimer/désactiver un mot de passe/clé qui a été précédemment utilisé pour initialiser le référentiel, donc on ne devrait pas avoir à recréer l'intégralité du référentiel.

Le cryptage est une autre chose cependant, et suivi dans cet autre problème.

Je ne me soucie pas trop d'une option sans mot de passe, mais vous plaidiez pour un non-chiffrement par défaut :

Ainsi, la protection par mot de passe et le cryptage pourraient être fournis en option uniquement et ne devraient pas être en place par défaut.

BTW : les valeurs par défaut sont la marque de la qualité du logiciel.

que je trouve dangereux.

Bien que je sois généralement d'accord avec les points de @rawtaz , si la discussion porte strictement sur une option sans mot de passe (ne changeant pas la valeur par défaut), je n'y ai pas trop d'intérêt.

@cfbao

Je ne me soucie pas trop d'une option sans mot de passe, mais vous plaidiez pour un non-chiffrement par défaut :

Ainsi, la protection par mot de passe et le cryptage pourraient être fournis en option uniquement et ne devraient pas être en place par défaut.

Vous pouvez voir même dans cette citation que les "options" sont en premier et "par défaut" est la suivante. Et c'est encore le point.

Dans ce cas (problème), c'est assez simple - il y aura probablement un indicateur --no-password ou similaire à restic init (la valeur par défaut étant toujours que restic demande un mot de passe lors de l'initialisation), mais c'est juste mon avis sur la dernière réponse de @fd0 . Et il n'y a pas d'ETA à ce stade, pas besoin de demander à ce sujet :)

Pendant ce temps, utilisez un mot de passe factice :) Je suppose qu'une implémentation appropriée inclut la possibilité de supprimer/désactiver un mot de passe/clé qui a été précédemment utilisé pour initialiser le référentiel, donc on ne devrait pas avoir à recréer l'intégralité du référentiel.

Une solution probablement plus simple serait que restic prenne en charge un mot de passe factice qui essaiera d'ouvrir un référentiel existant si aucun mot de passe n'est spécifié par l'utilisateur.

Concernant la gestion des mots de passe factices : il n'existe pas de meilleur mot de passe factice clair qui fonctionne pour tout le monde. 1234 est un mot de passe factice ennuyeux car il nécessite quatre doigts pour se déplacer et taper. "asdf" est beaucoup plus rapide à taper par exemple. De plus, certains services restreignent le choix des mots de passe, de sorte que seuls les chiffres ou seulement quatre chiffres peuvent ne pas être possibles. Par conséquent, une solution à l'intérieur de restic serait la plus conviviale. Ensuite, les utilisateurs n'auraient qu'à taper le mot de passe factice une seule fois.

Du point de vue de la sécurité dès la conception, fournir toute sorte de mot de passe factice est une mauvaise idée.

IFF quelqu'un veut vraiment contourner le cryptage ou n'en a pas besoin, fournissez simplement un mot de passe cohérent. Vous n'avez pas à le taper, vous pouvez écrire un script pour y encapsuler du code statique et dur à votre guise. Vraiment, est-ce plus de travail que de fournir l'adresse du référentiel ou d'autres options de configuration ?

Demander à restic d'essayer un ensemble de mots de passe codés en dur faux ou factices ne fait que demander des ennuis. Et si une pauvre âme venait à choisir l'un de vos mots de passe « magique » ? Les avertissons-nous de choisir nos faux mots de passe de cryptage spéciaux factices ? "Non Ted, tu ne peux pas choisir SPACECHICKEN comme mot de passe de dépôt, c'est _spécial_." ;)

Je suis d'accord pour fournir une option aux utilisateurs pour se tirer une balle dans le pied avec ("--no-repository-password") mais je ne pense pas que restic devrait aller plus loin que cela pour apaiser le très petit segment d'utilisateurs qui désir de sécurité RÉDUITE.

Du point de vue de la sécurité dès la conception, fournir toute sorte de mot de passe factice est une mauvaise idée.

Pourquoi est-ce pire que de ne pas autoriser de mot de passe ?

IFF quelqu'un veut vraiment contourner le cryptage ou n'en a pas besoin, fournissez simplement un mot de passe cohérent. Vous n'avez pas à le taper, vous pouvez écrire un script pour y encapsuler du code statique et dur à votre guise. Vraiment, est-ce plus de travail que de fournir l'adresse du référentiel ou d'autres options de configuration ?

Oui, c'est plus de travail. Restic serait la solution de sauvegarde et sa sortie serait le référentiel. Donc, idéalement, le référentiel contiendrait tout pour restaurer la sauvegarde. Mais lorsque vous utilisez un script wrapper qui code en dur, le mot de passe factice signifie que ce script doit être sauvegardé par autre chose, sinon le référentiel serait inutile.

Demander à restic d'essayer un ensemble de mots de passe codés en dur faux ou factices ne fait que demander des ennuis. Et si une pauvre âme venait à choisir l'un de vos mots de passe « magique » ? Les avertissons-nous de choisir nos faux mots de passe de cryptage spéciaux factices ? "Non Ted, tu ne peux pas choisir SPACECHICKEN comme mot de passe de dépôt, c'est _spécial_." ;)

Quel est le problème exactement? Ted peut toujours choisir ce mot de passe. Cela signifie simplement que restic l'utilisera commodément s'il ne le spécifie pas. Restic crypterait/décrypterait toujours le référentiel de la même manière que s'il ne s'agissait pas d'un mot de passe spécial.

Je suis d'accord pour fournir une option aux utilisateurs pour se tirer une balle dans le pied avec ("--no-repository-password") mais je ne pense pas que restic devrait aller plus loin que cela pour apaiser le très petit segment d'utilisateurs qui désir de sécurité RÉDUITE.

Appeler cela « se tirer une balle dans le pied » est inutilement critique et n'implique pas non plus une sécurité réduite. La disponibilité et la résilience contre les ransomwares doivent faire partie d'un concept de sécurité. La capacité manquante de restaurer une sauvegarde en raison d'un accès manquant au mot de passe de cryptage réduirait la sécurité. Stocker la sauvegarde en toute sécurité sur un système de stockage à ajout uniquement ne diminuerait pas le niveau de sécurité, ici.

Why is it worse than allowing no password?

Je ne sais pas comment je ferais pour convaincre quelqu'un que les mots de passe codés en dur, cachés, secrètement essayés contre les référentiels seraient une mauvaise idée. Si vous pensez qu'ils le sont, il n'y a probablement aucun argument axé sur la sécurité qui pourrait vous convaincre.

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.

J'ai choisi un exemple amusant, je n'aurais peut-être pas dû. Supposons que votre mot de passe factice que vous souhaitez que restic essaie secrètement et automatiquement si le déchiffrement échoue est : "12345". Un utilisateur naïf pourrait très bien choisir cela comme mot de passe. Maintenant, ils ont un référentiel qui, selon eux, est crypté (et l'est en quelque sorte) mais _n'importe qui_ restic peut déchiffrer. Cet argument s'applique à tout ensemble de mots de passe que vous choisissez dans votre ensemble codé en dur. C'est une conception de sécurité fondamentalement mauvaise.

Il y a un terme pour ce que vous proposez. C'est ce qu'on appelle une porte dérobée de cryptage :) Cacher cette porte dérobée dans les documents suppose que tous les lecteurs liront entièrement le manuel avant d'utiliser restic. Cela ne servirait-il pas les besoins de plus de gens de leur faire lire les documents pour déterminer comment réduire la sécurité s'ils le désirent étrangement ?

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.

Si vous ne pensez pas que le cryptage au repos est une politique de sécurité solide et que vous opteriez pour autre chose, vous êtes certainement dans la grande minorité. Ce type de défauts non sécurisés ne sert personne et doit être découragé à tout moment. Il suffit de consulter N'IMPORTE QUELLE référence de sécurité pour obtenir des conseils dans ce cas. Mon point n'est pas controversé - je défends la pratique standard de l'industrie.

Même votre exemple d'ajout de supports de stockage uniquement bénéficierait fortement du chiffrement au repos. Je recommanderais vivement de lire un ensemble récent de NIST, ISO 27002, NERC, IEC 62443 ou vraiment toute norme acceptée à l'échelle mondiale pour obtenir des conseils sur les meilleures pratiques ici. Nous ne sommes pas dans un nouveau territoire.

Je dois également souligner que nous confondons effectivement deux problèmes dans ce fil : la gestion des clés et le cryptage.

C'est peut-être de là que surgit la confusion.

Peut-être que ce problème peut être résolu par une documentation qui dit quelque chose comme :

Si vous ne souhaitez pas sécuriser votre référentiel avec un mot de passe, utilisez simplement la chaîne : password

De cette façon, il existe un moyen bien connu d'effectuer une sauvegarde/restauration avec restic sans avoir à gérer de clés.

Why is it worse than allowing no password?

Je ne sais pas comment je ferais pour convaincre quelqu'un que les mots de passe codés en dur, cachés, secrètement essayés contre les référentiels seraient une mauvaise idée. Si vous pensez qu'ils le sont, il n'y a probablement aucun argument axé sur la sécurité qui pourrait vous convaincre.

Je suppose qu'il vous manque un "pas" là-bas...

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.

J'ai choisi un exemple amusant, je n'aurais peut-être pas dû. Supposons que votre mot de passe factice que vous souhaitez que restic essaie secrètement et automatiquement si le déchiffrement échoue est : "12345". Un utilisateur naïf pourrait très bien choisir cela comme mot de passe. Maintenant, ils ont un référentiel qui, selon eux, est crypté (et l'est en quelque sorte) mais _n'importe qui_ restic peut déchiffrer. Cet argument s'applique à tout ensemble de mots de passe que vous choisissez dans votre ensemble codé en dur. C'est une conception de sécurité fondamentalement mauvaise.

Je n'ai pas proposé de l'essayer lorsque le déchiffrement échoue mais lorsqu'aucun mot de passe n'est spécifié pour le déchiffrement. Si quelqu'un choisit un mot de passe non sécurisé, il n'est pas sécurisé, qu'il soit essayé directement par restic ou par quelqu'un qui force brutalement les mots de passe. "12345" est également un mot de passe non sécurisé de nos jours, et il ne changerait pas s'il devenait le mot de passe par défaut pour restic.

Il y a un terme pour ce que vous proposez. C'est ce qu'on appelle une porte dérobée de cryptage :) Cacher cette porte dérobée dans les documents suppose que tous les lecteurs liront entièrement le manuel avant d'utiliser restic. Cela ne servirait-il pas les besoins de plus de gens de leur faire lire les documents pour déterminer comment réduire la sécurité s'ils le désirent étrangement ?

Une porte dérobée de cryptage serait si restic utilisait un mot de passe par défaut en plus du mot de passe fourni par l'utilisateur lors du cryptage des données. Ma proposition consiste à essayer un mot de passe lors du déchiffrement. L'utilisateur choisirait toujours activement ce mauvais mot de passe.

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.

Si vous ne pensez pas que le cryptage au repos est une politique de sécurité solide et que vous opteriez pour autre chose, vous êtes certainement dans la grande minorité. Ce type de défauts non sécurisés ne sert personne et doit être découragé à tout moment. Il suffit de consulter N'IMPORTE QUELLE référence de sécurité pour obtenir des conseils dans ce cas. Mon point n'est pas controversé - je défends la pratique standard de l'industrie.

Quel est le défaut non sécurisé à votre avis ?

Même votre exemple d'ajout de supports de stockage uniquement bénéficierait fortement du chiffrement au repos. Je recommanderais vivement de lire un ensemble récent de NIST, ISO 27002, NERC, IEC 62443 ou vraiment toute norme acceptée à l'échelle mondiale pour obtenir des conseils sur les meilleures pratiques ici. Nous ne sommes pas dans un nouveau territoire.

Le chiffrement au repos ne signifie pas que restic doit le faire. Le stockage d'ajout uniquement peut toujours être chiffré d'une autre manière si nécessaire. Néanmoins, il y aura du stockage non crypté, même si ce n'est que pour le mot de passe. Sinon, le concept de sauvegarde reposerait sur quelqu'un qui se souviendrait toujours du mot de passe.

se désinscrire de ce fil...

Restons-en là, il est clair que certaines personnes veulent une option --no-password à init , et c'est tout le sujet de ce problème. Le cryptage ou non est une question distincte.

Juste un petit commentaire ici :
Je suis un utilisateur qui ne se soucie pas du cryptage. Il n'y a rien de sensible sur mes données. Je me soucie du fait que les gens qui ne sont pas moi puissent utiliser dans 20-40 ans. Utiliser simplement rclone est une autre alternative plus pauvre.

Restic semble être un bon outil pour cela, sauf que le cryptage obligatoire et un mot de passe signifient que je dois en tenir compte. Peut-être un fichier README dans le référentiel de sauvegarde. C'est plus de travail et toute solution (de mon côté) défait tout cryptage de toute façon.

marque

Merci pour vos contributions, je pense que nous avons collecté suffisamment d'informations.