Restic: Permitir senhas vazias

Restic deve permitir senhas vazias.

Você pode explicar qual é o seu caso de uso? Por que o restic deve permitir senhas vazias?

é uma decisão de design.

Na verdade, é. Mas estou curioso para saber o que você está tentando alcançar.

Um problema relacionado é talvez # 1018

Eu só queria fazer backup de alguns diretórios temporariamente em meu sistema local como uma rede de segurança rápida ao alterar arquivos em um diretório. Eu não queria lembrar uma senha longa ou me incomodar em digitá-la sempre que quiser criar um backup. Como acabei de usar a como senha, não há nenhum benefício de segurança real em usar essa senha em comparação a não usar uma senha. Portanto, qualquer pequena sobrecarga para lembrar ou inserir uma senha inútil torna a ferramenta menos perfeita.

Obrigada pelo esclarecimento. Gostaria de manter essa verificação em vigor, portanto, encerrarei este problema por enquanto. Sinta-se à vontade para adicionar mais comentários. Obrigado!

Quando conversamos sobre isso há um tempo, você disse que haveria uma discussão ...
Você pode explicar por que considera esta verificação útil? O repositório ainda deve ser criptografado para que uma senha possa ser adicionada posteriormente.

Considero essa verificação útil porque, em minha experiência, a maioria dos usuários deseja definir uma senha. Aceitar uma senha vazia, ou mesmo ter um caminho de código que permite aceitar senhas vazias, pode fazer com que os usuários salvem acidentalmente seus backups em locais remotos sem a criptografia adequada. Uma situação em que isso pode acontecer é quando a variável de ambiente RESTIC_PASSWORD não é exportada ou definida como uma string vazia acidentalmente.

Portanto, neste caso, parece-me que proteger os usuários de um erro é melhor do que remover o pequeno inconveniente de ter que definir uma senha :)

Existem soluções fáceis para isso: use um gerenciador de senhas, use a string test , exporte RESTIC_PASSWORD estaticamente por meio de um arquivo, por exemplo, em /etc/profile.d , use o nome do diretório que você está salvando (ou o repositório) como a senha ...

Observe que o conhecimento de sua senha é necessário para acessar o repositório.
Perder sua senha significa que seus dados estão irrecuperavelmente perdidos.

Como posso evitar que isso aconteça se não quero perder meus dados para sempre?

@LexSong Use um gerenciador de senhas.

Na terça-feira, 3 de julho de 2018 às 09:56:56 AM -0700, Chenfeng Bao escreveu:

@LexSong Use um gerenciador de senhas.

Como você propõe fazer backup do banco de dados do gerenciador de senhas? Você
proponho aqui usar um gerenciador de senhas com um banco de dados sem um
senha? Qual gerenciador de senha não oferece suporte para obter o
senha de?

O gerenciamento de senhas é um tópico enorme que não quero entrar em muitos detalhes neste tópico. Apenas apontando que, se feitas corretamente, as senhas não devem ser uma dor de cabeça. Existem vários recursos online.

O banco de dados de um gerenciador de senhas já deve estar devidamente criptografado, para que você possa colocá-lo em qualquer lugar que desejar, sem outra camada de criptografia. Existem também muitos serviços de gerenciamento de senhas baseados em nuvem, então você não precisa se preocupar com backups.

Quanto ao suporte do Restic, você pode simplesmente colocar a senha em um arquivo de texto simples localmente e usar a opção --password-file . Então você não precisa inserir a senha manualmente. A própria senha também deve ser colocada no gerenciador de senhas para registro.

No final do dia, sempre há uma senha / frase secreta complexa que você precisa memorizar para manter as coisas realmente seguras.

Na verdade, se você realmente não quer uma senha em um repositório Restic, por que não usar uma senha fictícia de um caractere?

Usar 'a' como senha foi na verdade minha solução alternativa, mas não parece ser adequado, pois não posso ter certeza de que me lembro de usar isso quando vejo este repositório por algum motivo novamente em alguns anos, caso eu me esqueça de excluí-lo quando Não preciso mais disto. Portanto, posso ter que implementar algum tipo de força bruta para descobrir. Todo esse trabalho pode ser evitado.

No passado eu já utilizava senhas temporárias simples em situações que me deixavam nesse estado ao proteger temporariamente um HD externo com senha para facilitar a exclusão posterior. No entanto, não o eliminei, por isso, quando o quisesse utilizar da próxima vez, queria ter a certeza de que não há nada importante na unidade. Infelizmente, a senha do meu gerenciador de senhas não funcionou mais, pois esqueci de atualizá-la / removê-la de lá. Portanto, quando penso em meu eu futuro, parece ser uma boa ideia torná-lo mais fácil para ele, não criando repsositórios impassíveis que eu não possa decifrar.

Eu tenho outra ideia, que tal o restic tentaria usar "restic" como uma senha padrão quando não houver senha para acessar um repositório e voltar para uma mensagem de erro se não funcionar? Em seguida, os usuários podem usar essa senha para indicar que não precisam de criptografia e o restic pode abri-la sem magia extra.

Concordo com os comentários anteriores em manter a verificação de proteção contra erros do usuário.

Restic precisa oferecer suporte a senhas vazias pelos motivos já declarados. eu
especificamente não quero criptografar meus backups locais porque não quero
para perder o acesso a eles. Não quero correr o risco de esquecer a senha e
não sendo capaz de restaurar os dados. Este é um risco real porque os usuários normalmente
restauram muito raramente e, muitas vezes, executam backups autônomos para os quais não
precisa inserir a senha, tornando mais provável que seja esquecido.

Armazenar a senha em um arquivo ou script é uma solução alternativa propensa a erros para um
problema que não deveria existir.

Concordo que deve-se ter cuidado para evitar o upload acidental
dados não criptografados para repositórios remotos.

Parece que uma solução simples seria ter uma opção de linha de comando,
--allow-empty-password . Os usuários podem definir essa opção em seus scripts e
o padrão pode permanecer para exigir uma senha.

Este é um risco real porque os usuários geralmente restauram muito raramente e geralmente executam backups autônomos para os quais não precisam inserir a senha, tornando mais provável que sejam esquecidos.

Essas senhas de backup não devem ser memorizadas. A única senha de criptografia complexa de que você precisa se lembrar é a do gerenciador de senhas, que você usará com frequência. E você _realmente_ deve usar um gerenciador de senhas.

Armazenar a senha em um arquivo ou script é uma solução alternativa propensa a erros para um problema que não deveria existir.

Lamento, mas não vejo como é uma solução alternativa sujeita a erros. Parece uma forma totalmente válida de automatizar a criptografia para mim. O problema é resolvido, novamente, usando um gerenciador de senhas.

Parece que uma solução simples seria ter uma opção de linha de comando, --allow-empty-password . Os usuários podem definir essa opção em seus scripts e o padrão pode permanecer para exigir uma senha.

Esta parece ser uma forma razoável de evitar erros do usuário. No entanto, ainda existem preocupações em relação ao aumento da superfície de ataque e precisam ser tratadas com muito cuidado.

Essas senhas de backup não devem ser memorizadas. A única senha de criptografia complexa de que você precisa se lembrar é a do gerenciador de senhas, que você usará com frequência. E você realmente deve usar um gerenciador de senhas.

Um gerenciador de senhas não é absolutamente uma solução válida para este problema. O objetivo de fazer backups é fazer backup de seus arquivos, o que inclui o banco de dados do gerenciador de senhas ! Como, então, você recuperaria a senha para o conjunto de backup quando a senha é armazenada dentro do conjunto de backup criptografado?

Ao projetar um sistema de backup, você deve planejar o pior cenário, que inclui a restauração quando você não tem nada disponível, exceto o seu backup. O que você evidentemente faz é fazer backup do banco de dados do gerenciador de senhas separadamente dos backups Restic. Isso é bom para você , mas não cabe a você impor esse sistema a outros usuários. E é um absurdo dizer que um gerenciador de senhas é necessário para usar o Restic, principalmente quando ele nem mesmo foi projetado para se integrar a um. Em caso afirmativo, mostre-me a documentação para o efeito.

O Restic, como muitos softwares, tem como objetivo permitir que os usuários atendam às suas necessidades. Suas necessidades não incluem um cenário de restauração bare-metal, nada-exceto-seu-backup-Restic. As necessidades de outros usuários sim. Por favor, não imponha as necessidades de outras pessoas a eles.

Esta parece ser uma forma razoável de evitar erros do usuário. No entanto, ainda existem preocupações em relação ao aumento da superfície de ataque e precisam ser tratadas com muito cuidado.

Que preocupações específicas você vê em relação ao aumento da superfície de ataque causado pela opção --allow-empty-password proposta?

Esta parece ser uma forma razoável de evitar erros do usuário. No entanto, ainda existem preocupações em relação ao aumento da superfície de ataque e precisam ser tratadas com muito cuidado.

Minha outra ideia era que o restic usasse uma senha padrão para acessar um repositório quando nenhuma senha fosse especificada, por exemplo restic . Então, a IU para criar um novo repositório não muda e apenas quando um usuário usa a senha padrão, o restic será automaticamente capaz de acessar o repositório e o usuário não precisa se lembrar da senha.

Lamento, mas não vejo como é uma solução alternativa sujeita a erros. Parece uma forma totalmente válida de automatizar a criptografia para mim. O problema é resolvido, novamente, usando um gerenciador de senhas.

Enquanto não houver integração com o gerenciador de senhas, ainda existe o perigo de que o valor no gerenciador de senhas esteja errado, desatualizado ou apagado acidentalmente, pois haverá uma cópia da senha fora do gerenciador de senhas.

Também gostaria de ver uma opção para permitir uma senha vazia (por meio do uso do sinalizador --allow-empty-password , ou talvez algo mais detalhado / exclusivo para destacar o risco, como o sinalizador --dont-blame-nrpe do NRPE).

Meus casos de uso:

• Negócios: temos um repositório contido em um ambiente confiável do qual precisamos "qualquer um" para poder restaurar em uma emergência / desastre sem ter que ter um conhecimento especial (ou seja, uma senha de repositório).
• Home: Eu gostaria de fazer um backup de coisas como fotos de família. Eles não são particularmente confidenciais e, no caso de minha morte prematura, minha família precisa ser capaz de acessar esses dados pessoalmente importantes com o mínimo de resistência (_por exemplo, sem ter que encontrar uma senha longa em um cofre, isso está possivelmente fora de uso data ou misturado com outro_).

Eu entendo a necessidade de uma senha longa para garantir a integridade dos dados, bem como a criptografia. Vejo que os arquivos no diretório keys parecem ser um objeto JSON. Talvez uma chave psuedo-aleatória pudesse ser gerada (em vez de nenhuma chave) e armazenada lá? Isso não ajuda os usuários que estão tentando evitar a sobrecarga de criptografia por motivos de desempenho.

@ fd0 O que você acha da opção de linha de comando --allow-empty-password proposta? Isso exigiria frases-senha por padrão, mas permitiria que os usuários as substituíssem quando necessário.

E considere reabrir este problema. As necessidades de muitos usuários incluem o backup de arquivos não confidenciais sem o risco de perder o acesso devido a senhas esquecidas ou perdidas.

Novo usuário restic aqui - nem mesmo criei meu primeiro repositório ainda - mas anos de experiência com outras ferramentas - meu favorito é o bom e velho "despejo". Com respeito, isso é um acéfalo - é claro que senhas vazias devem ser permitidas. De qualquer forma, adicione um sinalizador para minimizar o risco de erro inadvertido, mas não dite casos de uso para usuários experientes (potenciais) que indicaram claramente outras necessidades.
Tudo o que estou tentando fazer é fazer backups locais por segurança; a segurança não é um problema e tenho muito mais probabilidade de perder a senha do que precisar do backup. E eu odeio gerenciadores de senhas ...

Ter um requisito de senha torna difícil automatizar backups, e a necessidade de fornecer a senha em um env ou em um arquivo de script torna toda a segurança inútil em primeiro lugar.

a necessidade de fornecer a senha em um env ou em um arquivo de script torna toda a segurança inútil em primeiro lugar.

Isso não é necessariamente verdade. Existem boas maneiras de fazer isso.

Isso não é necessariamente verdade. Existem boas maneiras de fazer isso.

Por favor, não repita este argumento aqui. Muitos usuários precisam fazer backups não criptografados ou com senha vazia. Se você não é um deles, bom para você.

@mholt , alguma recomendação? Eu ficaria mais do que feliz em fazer backup de meus servidores com nenhuma interferência com segurança máxima.

Muitos usuários precisam fazer backups não criptografados ou com senha vazia.

Isso geralmente é um problema XY .

@mholt , alguma recomendação? Eu ficaria mais do que feliz em fazer backup de meus servidores com nenhuma interferência com segurança máxima.

Depende muito de sua situação específica, modelo de ameaça, ambiente, riscos aceitáveis ​​e objetivos técnicos e de usabilidade. Portanto, não, não tenho um conjunto de recomendações para ninguém.

Isso geralmente é um problema XY.

Portanto, não, não tenho um conjunto de recomendações para ninguém.

Essa atitude condescendente não ajuda. Muito pior que, depois de nos dizer que nossas necessidades estão erradas, você se recuse a oferecer qualquer conselho. Este é um projeto FOSS, não Apple, Inc.

Por exemplo, não preciso nem quero criptografar meus backups locais de meus dados já não criptografados. Se meu disco principal falhar e eu precisar recuperar meus backups, a frase secreta é armazenada dentro do repositório de backup com meus scripts de backup e arquivos de configuração. Minha principal preocupação não é impedir que outras pessoas acessem esses dados não confidenciais - minha principal preocupação é a fácil recuperação e não ser bloqueado para meus dados.

Esse é um caso comum para muitos usuários e não cabe a você decidir quais são as necessidades dos usuários.

O software existe para servir aos usuários, não para forçá-los a concordar com suas demandas.

Obrigado por explicar seu (s) caso (s) de uso e suas preocupações novamente. Só para constar, acho que eles são válidos, principalmente o de "senha perdida". Também acho que um sinalizador especial para restic init como --allow-empty-password , funcionaria (tenho algumas considerações para casos esquivos, mas tenho certeza de que podem ser resolvidos). Portanto, reabrirei este problema.

Esteja ciente de que permitir senhas vazias resolverá a preocupação com a segurança de "senha perdida", mas ainda criptografará todos os dados normalmente.

Por outro lado, não gosto do tom deste tópico. Você é livre para não usar restic, isso é perfeitamente normal. A maioria de nós trabalha com repouso nas horas vagas. Alguns comentários neste tópico parecem muito intitulados, parafraseados: "você deve implementar este recurso, há usuários que precisam dele!". Esse não é o caso. Podemos considerá-lo e implementá-lo, mas também podemos decidir não fazer nada.

Então, por favor, todos, vamos manter essa discussão produtiva, mesmo que vocês discordem. :)

@ fd0 Perdoe-me por não ser claro. Não exijo ou espero nada de você ou de qualquer desenvolvedor da Restic. É o seu projeto e seu tempo, e você pode trabalhar no que quiser.

O que eu peço é que você considere esse recurso e caso de uso. Se você não estiver interessado em implementá-lo sozinho, tudo bem, e peço que deixe o assunto em aberto para que outros possam discuti-lo e que você considere quaisquer RPs que possam implementá-lo.

O que me oponho são os comentários (não os seus) que sugerem que os usuários que desejam esse recurso não entendem suas próprias necessidades, especialmente quando seguidos por uma recusa em sugerir alternativas. Isso é um ruído rude e inútil.

Para mim, estou usando git-attachment com um controle remoto especial bup. O Annex já suporta criptografar arquivos (que eu desativei, para usar o recurso de desduplicação do bup). E então eu faço backup do repo bup (que é apenas um repositório git sofisticado) para um servidor remoto. Posso, então, excluir o repo bup, que é apenas um cache, e fazer uma restauração via restic, conforme necessário.

Então, basicamente, estou juntando um monte de ferramentas de uso único, no Unix Way (tm), já que cada uma faz bem o seu trabalho. Restic (atualmente estou mudando de duplicidade) faz a desduplicação de bloco de janela deslizante para uma nuvem remota, e isso é tudo que preciso fazer. A criptografia e a desduplicação do bloco local ocorrem em uma camada diferente. Portanto, não quero ter uma senha especificada, nem qualquer criptografia (o que na verdade economiza no uso da CPU).

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

Isso é apenas metade do que eu quero, pois ainda está criptografando, mas com uma senha em branco. Gostaria de recuperar o uso da CPU, se possível.

Esteja ciente de que permitir senhas vazias resolverá a preocupação com a segurança de "senha perdida", mas ainda criptografará todos os dados normalmente.

Hm, qual é a motivação por trás de ainda criptografar com uma senha vazia?

Quero dizer, ao executar o Restic em um hardware de baixa potência, a criptografia adiciona alguma sobrecarga de tempo de execução perceptível.

Edit: Ok, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - especialmente o segundo ponto responde à minha pergunta.

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

O principal problema com esta sugestão é: Simplesmente não funciona, o restic está pedindo uma senha interativamente então:

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

Obrigado, @ fd0 , por reabrir a edição. Eu concordo com @alphapapa , minha intenção não é forçar nenhum desenvolvedor de tempo livre a gastar seu tempo em algo com o qual não se divirta.

Simplesmente não gostamos que outras pessoas nos digam que não entendemos nossas próprias necessidades.

Na minha opinião, a característica mais importante de uma ferramenta de backup é a capacidade de fazer uma restauração em qualquer caso. Embora a segurança tenha uma importância muito, muito alta, depende da situação específica se a segurança dos dados (capacidade de restauração) ou a segurança dos dados (proteção contra acesso não autorizado) tem uma prioridade mais alta.

Claro, você pode decidir livremente desenvolver uma ferramenta apenas para situações em que a segurança é mais importante do que a segurança.

Como @mholt mencionou "Problema XY": O pedido é ser capaz de fazer uma recuperação de desastre sem qualquer conhecimento além de uma documentação restic genérica disponível ao público e, claro, acesso ao próprio repositório.
"Sem qualquer conhecimento" exclui a necessidade ou o uso de gerenciadores de senha.

O motivo pelo qual encontrei esse problema é: _Estou ajudando algumas pessoas com seus PCs em particular. O manuseio de senhas é uma bagunça, tentar ensiná-los a lidar de maneira adequada com as senhas durante a configuração de um backup em drives USB resultará apenas em não criar backups ou em não exibir a senha disponível quando necessário. Eles podem obter ajuda de outra pessoa quando precisarem de uma restauração, então qualquer coisa que eu proponha para mitigar a situação pode ser nula._

No momento, estou salvando a senha em um arquivo de texto na mesma unidade USB do repositório de backup do Restic, o que prejudica completamente a segurança de ter uma senha.
E eu não gosto dessa solução, pois usar uma senha que não fornece nenhuma camada adicional de segurança dá uma imaginação muito errada de segurança.

É claro que estou falando apenas de backups locais pessoais aqui. Para servidores, eu recomendo senhas fortes copiadas para algum armazenamento offline separado.

Acho que outro problema aqui é; se algumas estruturas / APIs permitem senhas vazias e outras não. E é preciso descriptografar uma entrada que foi criptografada por outra API com uma senha vazia. Este é atualmente o meu problema com https://github.com/RNCryptor/JNCryptor

Então, por favor, todos, vamos manter essa discussão produtiva, mesmo que vocês discordem. :)

Depois de ler este tópico, acho a conversa produtiva, porque o resultado foi positivo.

Eu gostaria de lembrar a todos que este é o Github - se você tem uma forte opinião sobre algo e o mantenedor do projeto não está receptivo, fique à vontade para fazer um fork - literalmente leva segundos. Se você não tiver habilidade para fazer a mudança sozinho, peça a outras pessoas para ajudá-lo. Você descobrirá que os mantenedores podem ser mais abertos para aceitar um patch que implemente algo que eles próprios não estariam motivados a implementar.

Pessoalmente, neste caso, acho que impor um preconceito de qual segurança "deveria" ser para todos é um erro. A primeira regra de segurança de dados é que os dados devem ser acessíveis a quem tem direito a eles. Qualquer regra que comprometa a regra nº 1 deve ser considerada com o devido cuidado.

Segurança é um tópico cheio de FUD e políticas orientadas pelo medo, resultando em implementações ingênuas, precipitadas e muitas vezes hipócritas, porque poucos entre nós realmente gostam de pensar sobre todas as coisas que podem dar errado. Menos ainda queremos enfrentar as críticas dos outros quando somos vistos permitindo que as coisas dêem errado.

Alguns erros comuns que vemos todos os dias:

1) Insistir que os dados gravados em uma mídia criptografada em repouso devem ser criptografados, mesmo em um ambiente confiável. Onde termina o medo de interceptação? Por onde começar a confiar que o usuário pode ser potencialmente competente e que adicionar camadas redundantes apenas aumenta o risco de perda de dados?

2) Insistir na senha de um formato específico, ou seja, 8 caracteres com pelo menos uma letra maiúscula, um número e um não alfanumérico - essa era uma prática comum por 20 anos e agora foi desmentida porque a dor ultrapassa o ganho. Em vez disso, devemos insistir em senhas memoráveis ​​e de alta entropia, como xkcdpassword , ou integrar com um gerenciador de senhas (que efetivamente torna todos os principais consumidores dependentes de uma senha mestre SPOF de segurança compartilhada que pode ser usada como spearph - basta pedir COMMODO) ou integrar 2FA (potencialmente melhor dependendo da segurança física do segundo fator, incluindo redundância de chave N + 1).

3) Com uma senha mestra - deixar de armazená-la em cache em uma sessão de modo que o usuário seja forçado a inseri-la tantas vezes ao dia que a própria ação de entrar nela se torna um vetor de ataque notável.

4) Com uma senha mestra - deixar de verificar as políticas e consultar cegamente a senha mestra, de forma que o usuário se acostume a apresentá-la quando não deveria ser necessária, resultando em uma parada crítica para analisar se deve ou não fornecê-la em esta instância.

5) Aplicar uma política de privilégio mínimo a um ponto que os usuários se ressentem e evitem aceitar ou encontrar maneiras de contorná-la, deixando a porta aberta por muito mais tempo do que se houvesse um esquema mais permissivo.

6) Aplicar uma política de privilégio mínimo sem redundância N + 1, também conhecida como falta de considerações de 'continuidade de negócios / "política de homem-chave". ou seja, em vez de bloquear um recurso compartilhado atrás de 2 chaves privadas de forma que só possa ser acessado quando ambos concordarem (quorum de 2), bloqueie-o atrás de quaisquer 2 de 3 chaves privadas. Ninguém vive para sempre.

Sempre que nós, como programadores, estamos implementando um esquema de criptografia de chave única, precisamos considerar a importância da acessibilidade e ouvir as preocupações daqueles que estão dolorosamente cientes das consequências da perda de chave para um esquema de criptografia de chave única.

Também vamos tentar lembrar que tirar coisas dos usuários puramente por medo de uso indevido é fundamentalmente errado - como quase todas as decisões tomadas por medo. Punir a todos porque alguém pode fazer a coisa errada, diminui a sociedade como um todo.

Se você sentir neste momento que discorda desse conceito, respire fundo, conte até dez e, em seguida, considere o seguinte: O que devemos fazer como uma sociedade quando alguém comete suicídio, colocando a cabeça em um saco de lixo com uma lata de borrifar creme de leite e inalar a lata inteira de óxido nitroso? Devemos tirar o creme de chantilly de todos? Sacos de plástico? Respirando? Todas essas coisas podem ser mal utilizadas de forma a causar a morte do usuário.

Em vez do impulso automático de levar as coisas embora, como faríamos com uma criança brincando com fósforos, devemos errar em educar as pessoas a usar essas coisas corretamente. Ou aumente a barreira de entrada de forma que apenas aqueles que RTFM o encontrem.

Foi o que aconteceu no final aqui, e a decisão de aceitar esse resultado não veio até que todas as questões e opiniões já estivessem expressas. Eu recomendo assistir a sessões de Debate Parlamentar nas estações de TV públicas para exemplos de como um debate improdutivo soa, lol. Os participantes aqui foram excepcionalmente respeitosos uns com os outros em comparação.

Lembre-se dos bons utilitários de arquivamento em que a criptografia e a proteção por senha estavam disponíveis apenas como opções explícitas, mas não por padrão. E essa é a lógica certa porque a segurança pode ter muitas soluções externas fora desse escopo de utilidade e porque esse cuidado fica por conta do usuário. O que você faz é apenas fornecer as ferramentas de segurança de escolha dos usuários. Mas o autor prefere cuidar do que o usuário não pede para evitar o uso indevido.

E novamente sobre o tom. Isso é comum no mundo do código-fonte aberto. E é apoiado por algum mecanismo psicológico. Críticas com as quais os autores não concordam são tratadas como uma alegação de passar o tempo livre. E sempre temos que lembrar: não discutimos aqui Seu tempo livre, em vez disso, exploramos Sua criatura genial, sua funcionalidade e a lógica por trás dela. Nunca nos esquecemos de que Você não tem obrigação de atender à nossa demanda e tem pleno direito de não fazer nada. Mas se Você gosta do que faz, pode ser (talvez) porque outros gostem. Portanto, pode haver alguma esperança de que você esteja interessado em atender a demanda de pelo menos a maioria.

PS Todos estes são apenas discurso abstrato e nenhuma ação prática é feita.

Há uma coisa que nunca entendi com a discussão sobre não permitir nenhuma senha para um repositório (assumindo que o contexto @ fd0 escreveu anteriormente, que os dados ainda estarão criptografados); Por que aqueles que "não querem" uma senha simplesmente não usam uma senha fictícia como "1234" ou qualquer outra? Qual é o sentido de escrever um código em restic que remove a senha, quando se você não se importa em ter uma senha, pode apenas usar uma senha fictícia? É uma variável de ambiente ou arquivo de senha de distância, se você achar que é complicado digitá-lo na linha de comando ao executar o restic.

@rawtaz Isso foi respondido em comentários anteriores neste tópico.

Apenas deixe-me dizer que restic init -r foo --no-password é provavelmente um nome de bandeira melhor do que restic init -r foo --allow-empty-password , simplesmente porque o primeiro é mais direto e o último é muito prolixo.

Não consigo ver nenhum bom argumento por que apenas usar uma senha fictícia não é uma maneira perfeitamente viável de fazer isso, em vez de aumentar a base de código remanescente neste tópico. Já vi alguém dizer que pode esquecer a senha "a". Embora isso possa ser verdade, certamente é possível inventar uma senha fictícia simples e lembrar-se disso, ou pelo menos descobri-la novamente quando necessário. Mas, enfim, um sinalizador também funciona bem, estou surpreso com o quão grande este problema parece ser: D

Bem, aqui está um exemplo. Fiz um backup restic há um ano. Script de um
senha fictícia, lida de um arquivo. Não anotei a senha
em qualquer outro lugar. Depois de um ano sem usar aquela máquina, eu completamente
esqueci o processo e a senha - e perdi uma hora tentando
adivinhe a senha antes de eventualmente encontrar (e fazer engenharia reversa)
o script. Totalmente minha culpa, mas ainda - eu não preciso da segurança,
e não quer ser forçado a lembrar uma senha fictícia. E se eu
se não tivesse tido acesso aos arquivos originais, teria sido bloqueado.

TD

Não é uma questão de complicar demais? Uma das senhas mais comuns é 1234. Use-a e você não terá que tentar encontrá-la em algum lugar (assumindo que você não acha que usou uma mais complexa) porque quando você precisa inserir uma senha fictícia, você sabe que é 1234. Mas claro, entendo o que você quer dizer.

Também gostaria de ver uma opção para permitir uma senha vazia (por meio do uso do sinalizador --allow-empty-password , ou talvez algo mais detalhado / exclusivo para destacar o risco, como o sinalizador --dont-blame-nrpe do NRPE).

Meus casos de uso:

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

Eu entendo a necessidade de uma senha longa para garantir a integridade dos dados, bem como a criptografia. Vejo que os arquivos no diretório keys parecem ser um objeto JSON. Talvez uma chave psuedo-aleatória pudesse ser gerada (em vez de nenhuma chave) e armazenada lá? Isso não ajuda os usuários que estão tentando evitar a sobrecarga de criptografia por motivos de desempenho.

• Negócios: temos um repositório contido em um ambiente confiável do qual precisamos "qualquer um" para poder restaurar em uma emergência / desastre sem ter que ter um conhecimento especial (ou seja, uma senha de repositório).

Mas aqueles "qualquer um" já precisam de conhecimentos / instruções especiais. Eles precisam saber como executar o restic para restaurar dados, incluindo qual repositório usar e outras coisas, e então seria incrivelmente fácil incluir uma senha fictícia nessas instruções. Ou eles usariam um script ou automação semelhante que faz a restauração para eles (nesse caso, eles ainda precisam saber / obter instruções de onde ir para usar essa ferramenta), caso em que a senha fictícia seria tratada pelo script . Não importa como você olhe para isso, uma senha fictícia não é um problema. E, falando sério, se todo mundo de repente esquecesse, as pessoas serão capazes de simplesmente adivinhar 1234 ou usar força bruta. Não é um problema: P

• Home: Eu gostaria de fazer um backup de coisas como fotos de família. Eles não são particularmente confidenciais e, no caso de minha morte prematura, minha família precisa ser capaz de acessar esses dados pessoalmente importantes com o mínimo de resistência (_por exemplo, sem ter que encontrar uma senha longa em um cofre, isso está possivelmente fora de uso data ou misturado com outro_).

Espere o que? Por que diabos você iria querer não ter senha, e quando isso não é possível (pelo menos atualmente) usar uma senha fictícia super simples (por exemplo, 1234), e então colocar essa senha fictícia super simples em um cofre ? Isso seria completamente inútil. Coloque em outro lugar, e pelo que vale a pena você provavelmente já tem um monte de outras informações que sua família precisa saber no caso de sua morte, então apenas coloque sua senha fictícia junto com ela.

Finalmente, uma senha fictícia deve ser tão simples e óbvia que não ficará desatualizada e não há necessidade de mais de uma senha fictícia. Portanto, não deve estar desatualizado ou misturado com outro.

Sim, essas sugestões já foram feitas, então estamos andando em círculos agora. Pessoalmente, não são soluções adequadas com as quais estou confortável para meu ambiente e casos de uso.

Você não precisa desse recurso, tudo bem. Isso não significa que os casos de uso de todos os outros são inválidos. Não tenho um uso para o back-end do Amazon S3, mas não o declaro desnecessário, simplesmente não o uso. Se esse recurso for implementado, não custa nada deixar de usá-lo.

Sim, essas sugestões já foram feitas, então estamos andando em círculos agora.

Sim, e honestamente, ainda não vi uma explicação real de por que uma senha fictícia é tão difícil de manusear, sinto que já vi muitas complicações dela.

Pessoalmente, não são soluções adequadas com as quais estou confortável para meu ambiente e casos de uso.

Isso é algo que respeito totalmente. O caso de uso de todos é individual e você tem seu fluxo de trabalho :)

Acho que em algum momento obteremos um --no-password ou similar, com sorte isso resolverá este caso de uso também. Obrigado pela sua contribuição!

Rawtaz escreveu

Apenas deixe-me dizer que restic init -r foo --no-password é provavelmente um nome de bandeira melhor do que restic init -r foo --allow-empty-password , simplesmente porque o primeiro é mais direto e o último é muito prolixo.

Não consigo ver nenhum bom argumento por que apenas usar uma senha fictícia não é uma maneira perfeitamente viável de fazer isso, em vez de aumentar a base de código remanescente neste tópico. Já vi alguém dizer que pode esquecer a senha "a". Embora isso possa ser verdade, certamente é possível inventar uma senha fictícia simples e lembrar-se disso, ou pelo menos descobri-la novamente quando necessário. Mas, enfim, um sinalizador também funciona bem, estou surpreso com o quão grande este problema parece ser: D

Não estou preocupado com o uso / manuseio de senhas fictícias - em vez disso, às vezes estou preocupado com o uso da CPU, tornando o processo de backup mais lento devido à criptografia obrigatória quando está sendo executado em hardware inferior.

Resolver # 1018 (backups não criptografados) também resolveria esse problema - ieeg com um switch --unencrypted vez de --no-password switch.

Na verdade, usei o restic em hardware de baixo custo onde a CPU definitivamente não tinha AES-NI (ou uma extensão semelhante) e onde o backup era vinculado à CPU. Em outro caso, a CPU era um pouco mais poderosa, mas o único disco rígido externo disponível já estava criptografado com LUKS e, portanto, estava vinculado à CPU porque não era poderoso o suficiente para lidar com dois processos de criptografia em paralelo.

Veja também: https://github.com/restic/restic/issues/1018#issuecomment -307549863

Se você se esquecer de como usar o restic, você pode ler a documentação. Se você esquecer o local de um repositório, você pode encontrá-lo. Ou você pode encontrar casualmente um repositório órfão e se perguntando o que há dentro dele. Mas se você esqueceu a senha, você perde seus dados para sempre. E na vida real, você pode esquecer qualquer senha fictícia mais simples. Você pode esquecer tudo que não usa com frequência.

Se você perder a senha de root, pode inicializar com a opção init = / bin / bash e obter acesso total. Embora esse buraco possa ser fechado, ele ainda existe na maioria dos sistemas. Por quê? Porque a perda por indisponibilidade seria mais do que por insegurança nesses casos. Portanto, é uma troca entre segurança e disponibilidade. Para sistemas com requisitos mais elevados, existem soluções especiais, como chaves redundantes, desde segurança e disponibilidade.

resitc não é uma ferramenta de segurança. É uma ferramenta de backup. E, como tal, deve fornecer a própria funcionalidade de backup antes de tudo, e só então segurança. Portanto, a proteção por senha e a criptografia podem ser fornecidas apenas como opções e não devem ser implementadas por padrão.

BTW: os padrões são a marca da qualidade do software.

@vstavrinov Leia a introdução ao restic antes de dizer que não é uma ferramenta de segurança. É uma ferramenta de backup cujo um dos principais recursos é que tenta tornar seus backups seguros. Então, você está muito enganado quando diz que não se preocupa com a segurança.

Mas se você esqueceu a senha, você perde seus dados para sempre.

Sim, e é por isso que você (neste caso tem a opção simples de) usar uma senha fictícia para que possa sempre saber a senha, mesmo que a esqueça.

E na vida real, você pode esquecer qualquer senha fictícia mais simples.

Se você fizer isso, você escolheu uma senha fictícia muito complexa e não é mais uma senha fictícia simples.

Francamente, toda essa discussão está se tornando hilariante e boba. Eu não posso acreditar que as pessoas estão dizendo que uma senha como 1234, que é uma das mais comuns e óbvias, é algo que eles podem esquecer e então não ser capazes de descobrir muito rápido (por exemplo, apenas tentando alguns truques óbvios senhas). Eu diria que você tem que se esforçar muito para não ser capaz de "adivinhar" 1234 quando está nessa situação e, mesmo assim, provavelmente não conseguirá adivinhar.

Mas se você esqueceu a senha, você perde seus dados para sempre.

A Wikipedia pode ajudá-lo: tente as senhas mais comuns em https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

Uma situação em que isso pode acontecer é quando a variável de ambiente RESTIC_PASSWORD não é exportada ou definida como uma string vazia acidentalmente.

É possível para o código verificar se uma senha foi definida como uma string vazia explicitamente ou apenas não foi definida (nenhuma opção de linha de comando especificada, variável de ambiente não definida -> diferente de uma string vazia).

Acho que o usuário deve escolher a senha que deseja escolher.

Resolver # 1018 (backups não criptografados) também resolveria esse problema - ieeg com uma opção --unencrypted em vez da opção --no-password.

A criptografia ainda deve ser obrigatória para proteção contra pesquisa binária em um provedor de hospedagem, independentemente do formato, transmissão por meio de um canal não criptografado com MITM e assim por diante. Embora isso forneça tanta proteção quanto uma senha vazia para ataques direcionados (zero), ainda evita danos colaterais em ataques não direcionados.

@rawtaz

É uma ferramenta de backup cujo um dos principais recursos é que tenta tornar seus backups seguros. Então, você está muito enganado quando diz que não se preocupa com a segurança.

Não muito longe. Indique-me onde digo "não se preocupa com a segurança". Eu não. Você diz o mesmo: "É uma ferramenta de backup". Backup não é segurança, certo? Portanto, o restic não é uma ferramenta de segurança. E "... um dos principais recursos ...". Você está certo de novo: é um recurso. ou seja, a segurança é um recurso, enquanto um backup é uma designação funcional (destino).

@rawtaz

Francamente, toda essa discussão está se tornando hilariante e boba. Não acredito que as pessoas estão dizendo que uma senha como 1234 ...

Não posso fazer nada, mas você também está certo neste caso. O que é bobo é uma discussão sobre uma senha fictícia. Mas acho que o mais importante é entender que a proteção por senha e a criptografia devem ser opcionais. Além de não impor aos usuários recursos extras indesejados, deixando-os a opção de usá-los ou não. E essa é a marca da qualidade do software também.

Mas acho que o mais importante é entender que a proteção por senha e a criptografia devem ser opcionais.

Por quê? Por que "deveria" uma ferramenta de backup não ter criptografia padrão? Só porque é uma ferramenta de "backup"? Você está apenas dizendo isso, mas não há razão para nada disso.

Nenhuma decisão de design pode agradar a todos. Restic _escolhe_ dar grande ênfase à segurança, e usuários como eu _adicionam_ que a criptografia forte seja o padrão.

• Se você não se preocupa com a segurança, _não_ pode usar indevidamente um sistema seguro por padrão. Na pior das hipóteses, você vê alguns erros e tenta novamente com um comando ajustado.
• Se você se preocupa com a segurança, há várias maneiras de usar indevidamente um sistema inseguro por padrão para um efeito catastrófico. Falta um sinalizador e seus dados confidenciais vazam, talvez _irreversivelmente_.

Uma coisa é pedir um sinalizador que pode omitir a senha, mas argumentar que não há criptografia por padrão é um perigoso "vá se ferrar" para todos os usuários existentes que dependem da criptografia do Restic. O potencial para erros catastróficos do usuário é enorme.

@cfbao

Mas acho que o mais importante é entender que a proteção por senha e a criptografia devem ser opcionais.

Por quê? Por que "deveria" uma ferramenta de backup não ter criptografia padrão? Só porque é uma ferramenta de "backup"? Você está apenas dizendo isso, mas não há razão para nada disso.

"opcional" não é o mesmo que "padrão". Padrões como tais podem ser discutíveis. Mas ter opções é mais importante. Embora não tenhamos escolha, não há nada a ver com padrões. Essa é a questão. Primeiro forneça as opções, então faz sentido discutir os padrões.

Neste caso (problema) é muito simples - provavelmente haverá um --no-password ou sinalizador semelhante a restic init (com o padrão ainda sendo que o restic solicita uma senha no init), mas isso é apenas minha opinião sobre a última resposta de @ fd0 . E não há HEC neste momento, não há necessidade de perguntar sobre isso :)

Enquanto isso, use uma senha fictícia :) Suponho que uma implementação adequada inclui a capacidade de remover / cancelar a definição de uma senha / chave que foi usada anteriormente para inicializar o repo, portanto, não se deve ter que recriar o repositório inteiro.

A criptografia é outra coisa, entretanto, e rastreada nessa outra edição.

Não me importo muito com a opção sem senha, mas você estava argumentando sobre o padrão sem criptografia:

Portanto, a proteção por senha e a criptografia podem ser fornecidas apenas como opções e não devem ser implementadas por padrão.

BTW: os padrões são a marca da qualidade do software.

que eu acho perigoso.

Embora eu geralmente concorde com os pontos de @rawtaz , se a discussão for estritamente sobre uma opção sem senha (não alterar o padrão), não tenho muito interesse nisso.

@cfbao

Não me importo muito com a opção sem senha, mas você estava argumentando sobre o padrão sem criptografia:

Portanto, a proteção por senha e a criptografia podem ser fornecidas apenas como opções e não devem ser implementadas por padrão.

Você pode ver mesmo nesta citação que as "opções" são as primeiras e as "padrão" as próximas. E esse é o ponto novamente.

Neste caso (problema) é muito simples - provavelmente haverá um --no-password ou sinalizador semelhante a restic init (com o padrão ainda sendo que o restic solicita uma senha no init), mas isso é apenas minha opinião sobre a última resposta de @ fd0 . E não há HEC neste momento, não há necessidade de perguntar sobre isso :)

Enquanto isso, use uma senha fictícia :) Suponho que uma implementação adequada inclui a capacidade de remover / cancelar a definição de uma senha / chave que foi usada anteriormente para inicializar o repo, portanto, não se deve ter que recriar o repositório inteiro.

Uma solução provavelmente mais simples seria o restic oferecer suporte a uma senha fictícia que tentará abrir um repositório existente se nenhuma senha for especificada pelo usuário.

Com relação ao manuseio de senhas fictícias: Não existe uma senha fictícia clara que funcione para todos. 1234 é uma senha fictícia irritante, pois requer quatro dedos para mover-se e digitar. "asdf" é muito mais rápido de digitar, por exemplo. Além disso, alguns serviços restringem as opções de senha, portanto, apenas números ou apenas quatro dígitos podem não ser possíveis. Portanto, uma solução dentro do restic seria mais amigável. Assim, os usuários só precisariam digitar a senha fictícia uma vez.

Do ponto de vista da segurança por design, fornecer qualquer tipo de senha fictícia é uma má ideia.

IFF alguém realmente deseja contornar a criptografia ou não precisa dela, basta fornecer uma senha consistente. Você não tem que digitá-lo, você pode escrever um script para embrulhar código fixo e rígido para o conteúdo do seu coração lá. Realmente, isso é mais trabalhoso do que fornecer o endereço do repositório ou outras opções de configuração?

Fazer com que o restic tente um conjunto de senhas codificadas falsas ou fictícias é apenas pedir problemas. E se alguma pobre alma escolher uma de suas senhas "mágicas" propostas? Devemos alertá-los para que não escolham nossas senhas de criptografia falsas especiais? "Não, Ted, você não pode escolher SPACECHICKEN como sua senha de repositório, é _especial_." ;)

Estou bem em fornecer uma opção para os usuários darem um tiro no próprio pé com ("--no-repository-password"), mas não acho que o Restic deva ir além disso para apaziguar o pequeno segmento de usuários que desejam segurança REDUZIDA.

Do ponto de vista da segurança por design, fornecer qualquer tipo de senha fictícia é uma má ideia.

Por que é pior do que não permitir nenhuma senha?

IFF alguém realmente deseja contornar a criptografia ou não precisa dela, basta fornecer uma senha consistente. Você não tem que digitá-lo, você pode escrever um script para embrulhar código fixo e rígido para o conteúdo do seu coração lá. Realmente, isso é mais trabalhoso do que fornecer o endereço do repositório ou outras opções de configuração?

Sim, é mais trabalho. Restic seria a solução de backup e sua saída é o repositório. Portanto, o ideal é que o repositório contenha tudo para restaurar o backup. Mas, ao usar um script de invólucro que codifica permanentemente a senha fictícia, significa que esse script precisa ser copiado por outra coisa, caso contrário, o repositório seria inútil.

Fazer com que o restic tente um conjunto de senhas codificadas falsas ou fictícias é apenas pedir problemas. E se alguma pobre alma escolher uma de suas senhas "mágicas" propostas? Devemos alertá-los para que não escolham nossas senhas de criptografia falsas especiais? "Não, Ted, você não pode escolher SPACECHICKEN como sua senha de repositório, é _especial_." ;)

Qual é exatamente o problema? Ted ainda pode escolher essa senha. Significa apenas que o restic o usará convenientemente, se não o especificarem. Restic ainda criptografaria / descriptografaria o repositório da mesma forma como se não fosse uma senha especial.

Estou bem em fornecer uma opção para os usuários darem um tiro no próprio pé com ("--no-repository-password"), mas não acho que o Restic deva ir além disso para apaziguar o pequeno segmento de usuários que desejam segurança REDUZIDA.

Chamar isso de "dar um tiro no próprio pé" é desnecessariamente crítico e também não implica em redução da segurança. Disponibilidade e resiliência contra ransomware devem fazer parte de um conceito de segurança. A falta de capacidade de restaurar um backup devido à falta de acesso à senha criptografada diminuiria a segurança. Armazenar o backup com segurança em um sistema de armazenamento somente acréscimo não diminuiria o nível de segurança aqui.

Why is it worse than allowing no password?

Não tenho certeza de como faria para convencer alguém de que senhas de repositórios codificadas, ocultas e secretas seria uma má ideia. Se você acha que sim, provavelmente não há nenhum argumento focado na segurança que o convença.

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.

Escolhi um exemplo divertido, talvez não devesse. Vamos supor que a senha fictícia que você deseja que o Restic tente secretamente e automaticamente se a descriptografia falhar seja: "12345". Um usuário ingênuo poderia muito bem escolher essa como sua senha. Agora eles têm um repositório que eles acreditam estar criptografado (e meio que está), mas _qualquer pessoa_estic pode descriptografar. Este argumento se aplica a qualquer conjunto de senhas escolhido em seu conjunto codificado. Este é um projeto de segurança fundamentalmente ruim.

Há um termo para o que você está propondo. É chamado de backdoor de criptografia :) Esconder esse backdoor nos documentos pressupõe que todos os leitores lerão totalmente o manual antes de usar o restic. Não serviria às necessidades de mais pessoas fazê-las ler os documentos para determinar como diminuir a segurança caso elas estranhamente desejassem isso?

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.

Se você não acha que a criptografia em repouso é uma política de segurança sólida e optaria por outra coisa, certamente você está em minoria. Esse tipo de padrão inseguro não serve a ninguém e deve ser desencorajado em todos os pontos. Basta olhar para QUALQUER referência de segurança para obter conselhos neste caso. Meu ponto não é o contencioso - estou discutindo a prática padrão da indústria.

Até mesmo o seu exemplo de mídia de armazenamento anexar apenas se beneficiaria muito com a criptografia em repouso. Eu recomendo sinceramente a leitura de um conjunto recente de NIST, ISO 27002, NERC, IEC 62443 ou qualquer outro padrão globalmente aceito para orientação sobre as melhores práticas aqui. Não estamos em um novo território.

Devo também apontar que estamos efetivamente combinando duas questões neste segmento: gerenciamento de chaves e criptografia.

Talvez seja aí que surge a confusão.

Talvez esse problema possa ser resolvido por documentação que diz algo como:

Se você não quiser proteger seu repositório com uma senha, basta usar a string: password

Dessa forma, existe uma maneira bem conhecida de fazer backup / restauração com o restic sem ter que gerenciar nenhuma chave.

Why is it worse than allowing no password?

Não tenho certeza de como faria para convencer alguém de que senhas de repositórios codificadas, ocultas e secretas seria uma má ideia. Se você acha que sim, provavelmente não há nenhum argumento focado na segurança que o convença.

Acho que está faltando um "não" aí ...

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.

Escolhi um exemplo divertido, talvez não devesse. Vamos supor que a senha fictícia que você deseja que o Restic tente secretamente e automaticamente se a descriptografia falhar seja: "12345". Um usuário ingênuo poderia muito bem escolher essa como sua senha. Agora eles têm um repositório que eles acreditam estar criptografado (e meio que está), mas _qualquer pessoa_estic pode descriptografar. Este argumento se aplica a qualquer conjunto de senhas escolhido em seu conjunto codificado. Este é um projeto de segurança fundamentalmente ruim.

Não propus experimentá-lo quando a descriptografia falhar, mas quando nenhuma senha for especificada para a descriptografia. Se alguém escolher uma senha insegura, ela será insegura, independentemente de ser tentada pelo restic diretamente ou por alguém que força a senha bruta. "12345" também é uma senha insegura hoje em dia e não mudaria se se tornasse a senha padrão do restic.

Há um termo para o que você está propondo. É chamado de backdoor de criptografia :) Esconder esse backdoor nos documentos pressupõe que todos os leitores lerão totalmente o manual antes de usar o restic. Não serviria às necessidades de mais pessoas fazê-las ler os documentos para determinar como diminuir a segurança caso elas estranhamente desejassem isso?

Um backdoor de criptografia seria se o restic usasse uma senha padrão além da senha fornecida pelo usuário ao criptografar dados. Minha proposta é tentar uma senha na descriptografia. O usuário ainda escolheria ativamente essa senha incorreta.

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.

Se você não acha que a criptografia em repouso é uma política de segurança sólida e optaria por outra coisa, certamente você está em minoria. Esse tipo de padrão inseguro não serve a ninguém e deve ser desencorajado em todos os pontos. Basta olhar para QUALQUER referência de segurança para obter conselhos neste caso. Meu ponto não é o contencioso - estou discutindo a prática padrão da indústria.

Qual é o padrão inseguro na sua opinião?

Até mesmo o seu exemplo de mídia de armazenamento anexar apenas se beneficiaria muito com a criptografia em repouso. Eu recomendo sinceramente a leitura de um conjunto recente de NIST, ISO 27002, NERC, IEC 62443 ou qualquer outro padrão globalmente aceito para orientação sobre as melhores práticas aqui. Não estamos em um novo território.

A criptografia em repouso não significa que o Restic precise fazer isso. O armazenamento somente para acréscimos ainda pode ser criptografado de outra forma, se necessário. No entanto, haverá algum armazenamento não criptografado, mesmo que seja apenas para a senha. Caso contrário, o conceito de backup dependeria de alguém sempre se lembrando da senha.

cancelando a inscrição neste tópico ...

Vamos apenas deixar assim, está claro que algumas pessoas querem uma opção --no-password para init , e esse é o único assunto. A criptografia ou não é um problema separado.

Apenas um comentário rápido aqui:
Sou um usuário que não se importa com criptografia. Não há nada confidencial sobre meus dados. Preocupo-me com as pessoas capazes de usar em 20-40 anos que não sou eu. Usar apenas rclone é outra alternativa mais pobre.

Restic parece uma boa ferramenta para isso, exceto que exigir criptografia e uma senha significa que preciso levar isso em consideração. Talvez um README no repositório de backup. É mais trabalho e qualquer solução (do meu lado) derrota qualquer criptografia de qualquer maneira.

marca

Obrigado por suas contribuições, acho que coletamos informações suficientes.