Restic: Permitir contraseñas vacías

Restic debería permitir contraseñas vacías.

¿Puedes explicar cuál es tu caso de uso? ¿Por qué restic debería permitir contraseñas vacías?

es una decisión de diseño.

De hecho, es. Pero tengo curiosidad por saber qué estás tratando de lograr.

Un problema relacionado es quizás el # 1018

Solo quería hacer una copia de seguridad de algunos directorios temporalmente en mi sistema local como una red de seguridad rápida al cambiar archivos en un directorio. No quería recordar una frase de contraseña o molestarme en ingresar una frase de contraseña cada vez que quiero crear una copia de seguridad. Como acabo de usar a como contraseña, no hay ningún beneficio de seguridad real al usar esta contraseña en comparación con no usar una contraseña en absoluto. Por lo tanto, cualquier sobrecarga baja para recordar o ingresar una contraseña inútil hace que la herramienta sea menos perfecta.

Gracias por la explicación. Me gustaría mantener esta verificación en su lugar, así que cerraré este problema por ahora. No dude en agregar más comentarios. ¡Gracias!

Cuando hablamos de esto hace un tiempo, dijiste que habría una discusión ...
¿Puede explicarnos por qué considera útil esta comprobación? El repositorio aún debe estar encriptado para que luego se pueda agregar una contraseña.

Considero que esta verificación es útil porque, en mi experiencia, la mayoría de los usuarios querrán establecer una contraseña. Aceptar una contraseña vacía, o incluso tener una ruta de código que permita aceptar contraseñas vacías, puede hacer que los usuarios guarden accidentalmente sus copias de seguridad en ubicaciones remotas sin el cifrado adecuado. Una situación en la que esto puede suceder es cuando la variable de entorno RESTIC_PASSWORD no se exporta o se establece en la cadena vacía accidentalmente.

Entonces, en este caso, siento que proteger a los usuarios de un error es mejor que eliminar el pequeño inconveniente de tener que establecer una contraseña :)

Sin embargo, existen soluciones fáciles para esto: use un administrador de contraseñas, use la cadena test , exporte RESTIC_PASSWORD estáticamente a través de un archivo, por ejemplo, en /etc/profile.d , use el nombre del directorio que estás guardando (o el repositorio) como la contraseña ...

Tenga en cuenta que es necesario conocer su contraseña para acceder al repositorio.
Perder su contraseña significa que sus datos se pierden irremediablemente.

¿Cómo puedo evitar que esto suceda si no quiero perder mis datos para siempre?

@LexSong Usa un administrador de contraseñas.

El martes, 03 de julio de 2018 a las 09:56:56 AM -0700, Chenfeng Bao escribió:

@LexSong Usa un administrador de contraseñas.

¿Cómo propones hacer una copia de seguridad de la base de datos del administrador de contraseñas? Vos si
propongo aquí usar un administrador de contraseñas con una base de datos sin un
¿contraseña? ¿Qué administrador de contraseñas admite restic para obtener el
contraseña de?

La gestión de contraseñas es un tema enorme sobre el que no quiero entrar en demasiados detalles en este hilo. Solo señalo que si se hace correctamente, las contraseñas no deberían ser un dolor de cabeza. Hay numerosos recursos en línea.

La base de datos de un administrador de contraseñas ya debería estar correctamente cifrada, por lo que puede colocarla en cualquier lugar que desee sin otra capa de cifrado. También hay muchos servicios de administración de contraseñas basados ​​en la nube, por lo que no tiene que preocuparse por las copias de seguridad.

En cuanto al soporte de restic, puede simplemente poner la contraseña en un archivo de texto plano localmente y usar la opción --password-file . Entonces no es necesario que ingrese la contraseña manualmente. La contraseña en sí también debe colocarse en el administrador de contraseñas para su registro.

Al final del día, siempre hay una contraseña / frase de contraseña compleja que debes memorizar para mantener las cosas realmente seguras.

En realidad, si realmente no desea una contraseña en un repositorio restic, ¿por qué no usar una contraseña ficticia de un solo carácter?

Usar 'a' como contraseña fue en realidad mi solución, pero no me parece adecuado, ya que no puedo estar seguro de recordar haber usado esto cuando veo este repositorio por alguna razón nuevamente en unos años en caso de que olvide eliminarlo cuando Ya no lo necesito más. Por lo tanto, podría tener que implementar algún tipo de fuerza bruta para resolverlo. Todo esto es trabajo que podría evitarse.

En el pasado, ya usaba contraseñas temporales simples en situaciones que me dejaban en este estado cuando protegía temporalmente un disco duro externo con una contraseña para facilitar su eliminación después. Sin embargo, no lo eliminé, así que cuando quise usarlo la próxima vez quise asegurarme de que no hay nada importante en la unidad. Desafortunadamente, la contraseña de mi administrador de contraseñas ya no funcionó porque olvidé actualizarla / eliminarla desde allí. Por lo tanto, cuando pienso en mi yo futuro, parece una buena idea hacérselo más fácil al no crear repositorios restos que no pueda descifrar.

Tengo otra idea, ¿qué tal si restic intentaría usar "restic" como contraseña predeterminada cuando no hay contraseña para acceder a un repositorio y volver a un mensaje de error si no funciona? Entonces los usuarios podrían usar esta contraseña para indicar que no necesitan cifrado y restic la abriría sin magia adicional.

Estoy de acuerdo con los comentarios anteriores para mantener el control de protección contra los errores del usuario.

Restic necesita admitir contraseñas vacías por las razones ya mencionadas. I
específicamente no quiero cifrar mis copias de seguridad locales porque no quiero
perder el acceso a ellos. No quiero arriesgarme a olvidar la contraseña y
no poder restaurar los datos. Este es un riesgo real porque los usuarios normalmente
restaurar muy raramente y, a menudo, ejecutar copias de seguridad desatendidas para las que no
debe ingresar la contraseña, por lo que es más probable que la olvide.

Almacenar la contraseña en un archivo o secuencia de comandos es una solución propensa a errores para
problema que no debería existir.

Estoy de acuerdo en que se debe tener cuidado para evitar la carga accidental
datos no cifrados a repositorios remotos.

Parece que una solución simple sería tener una opción de línea de comando,
--allow-empty-password . Los usuarios pueden configurar ese interruptor en sus scripts y
el valor predeterminado podría permanecer para requerir una contraseña.

Este es un riesgo real porque los usuarios generalmente restauran muy raramente y, a menudo, ejecutan copias de seguridad desatendidas para las que no necesitan ingresar la contraseña, lo que aumenta la probabilidad de que se olviden.

Estas contraseñas de respaldo no están destinadas a ser memorizadas. La única contraseña de cifrado compleja que debe recordar es la de su administrador de contraseñas, que utilizará con frecuencia. Y usted _realmente_ debería usar un administrador de contraseñas.

Almacenar la contraseña en un archivo o script es una solución propensa a errores para un problema que no debería existir.

Lo siento, no veo cómo es una solución propensa a errores. Me parece una forma completamente válida de automatizar el cifrado. El problema se resuelve, nuevamente, usando un administrador de contraseñas.

Parece que una solución simple sería tener una opción de línea de comando, --allow-empty-password . Los usuarios pueden configurar ese interruptor en sus scripts y el valor predeterminado podría permanecer para requerir una contraseña.

Esta parece una forma razonable de evitar errores de usuario. Sin embargo, todavía existen preocupaciones con respecto al aumento de la superficie de ataque y deben abordarse con mucho cuidado.

Estas contraseñas de respaldo no están destinadas a ser memorizadas. La única contraseña de cifrado compleja que debe recordar es la de su administrador de contraseñas, que utilizará con frecuencia. Y realmente deberías usar un administrador de contraseñas.

Un administrador de contraseñas no es una solución válida para este problema. El objetivo de hacer copias de seguridad es hacer una copia de seguridad de sus archivos, que incluye la base de datos del administrador de contraseñas . Entonces, ¿cómo recuperaría la contraseña del conjunto de respaldo cuando la contraseña se almacena dentro del conjunto de respaldo cifrado?

Al diseñar un sistema de copia de seguridad, debe planificar para el peor de los casos, que incluye la restauración cuando no tiene nada disponible excepto su copia de seguridad. Lo que evidentemente hace es hacer una copia de seguridad de la base de datos de su administrador de contraseñas por separado de sus copias de seguridad de Restic. Eso está bien para usted , pero no le corresponde imponer ese sistema a otros usuarios. Y es absurdo decir que es necesario un administrador de contraseñas para usar Restic, especialmente cuando ni siquiera está diseñado para integrarse con uno. Si es así, por favor muéstreme la documentación a tal efecto.

Restic, como gran parte del software, está destinado a permitir a los usuarios satisfacer sus necesidades. Sus necesidades no incluyen un escenario de restauración de copia de seguridad completa, nada más que su Restic. Las necesidades de otros usuarios lo hacen. Por favor, no les imponga las necesidades de otras personas.

Esta parece una forma razonable de evitar errores de usuario. Sin embargo, todavía existen preocupaciones con respecto al aumento de la superficie de ataque y deben abordarse con mucho cuidado.

¿Qué preocupaciones específicas ve con respecto a una mayor superficie de ataque causada por la opción --allow-empty-password ?

Esta parece una forma razonable de evitar errores de usuario. Sin embargo, todavía existen preocupaciones con respecto al aumento de la superficie de ataque y deben abordarse con mucho cuidado.

Mi otra idea fue que restic usara una contraseña predeterminada para acceder a un repositorio cuando no se especificó una contraseña, por ejemplo restic . Entonces, la interfaz de usuario para crear un nuevo repositorio no cambia y solo cuando un usuario usa la contraseña predeterminada, restic podrá acceder automáticamente al repositorio y el usuario no necesita recordar la contraseña.

Lo siento, no veo cómo es una solución propensa a errores. Me parece una forma completamente válida de automatizar el cifrado. El problema se resuelve, nuevamente, usando un administrador de contraseñas.

Mientras no haya integración con el administrador de contraseñas, aún existe el peligro de que el valor en el administrador de contraseñas sea incorrecto, desactualizado o se elimine accidentalmente, ya que habrá una copia de la contraseña fuera del administrador de contraseñas.

También me gustaría ver una opción para permitir una contraseña vacía (mediante el uso de la bandera --allow-empty-password , o quizás algo más detallado / único para resaltar el riesgo, como la bandera --dont-blame-nrpe NRPE).

Mis casos de uso:

• Negocios: tenemos un repositorio contenido en un entorno confiable del que necesitamos que "cualquiera" pueda restaurar en caso de emergencia / desastre sin tener que tener conocimientos especiales (es decir, una contraseña de repositorio).
• Inicio: Me gustaría crear una copia de seguridad restringida de cosas como fotos familiares. Estos no son particularmente confidenciales y, en el caso de mi fallecimiento prematuro, mi familia debe poder acceder a estos datos personalmente importantes con una resistencia mínima (_por ejemplo, sin tener que encontrar una frase de contraseña en una caja fuerte, que posiblemente esté fuera de ... fecha o mezclada con otra_).

Entiendo la necesidad de una frase de contraseña para garantizar la integridad de los datos y el cifrado. Veo que los archivos en el directorio keys parecen ser un objeto JSON. ¿Quizás podría generarse una clave pseudoaleatoria (en lugar de ninguna clave) y almacenarse allí? Sin embargo, esto no ayuda a los usuarios que intentan evitar la sobrecarga del cifrado por razones de rendimiento.

@ fd0 ¿Qué opinas de la opción de línea de comandos propuesta --allow-empty-password ? Requeriría frases de contraseña de forma predeterminada, pero permitiría a los usuarios anularlas cuando fuera necesario.

Y considere reabrir este número. Las necesidades de muchos usuarios incluyen la realización de copias de seguridad de archivos no confidenciales sin riesgo de perder el acceso debido a frases de contraseña olvidadas o extraviadas.

Nuevo usuario restiche aquí - ni siquiera he creado mi primer repositorio todavía - pero años de experiencia con otras herramientas - mi favorito es el viejo "dump". Con respeto, esto es una obviedad, por supuesto, se deben permitir contraseñas vacías. Por supuesto, agregue una marca para minimizar el riesgo de error inadvertido, pero no dicte casos de uso a usuarios experimentados (potenciales) que hayan indicado claramente otras necesidades.
Todo lo que intento hacer es hacer copias de seguridad locales por seguridad; la seguridad no es un problema, y ​​es mucho más probable que pierda el rastro de la contraseña que que necesite la copia de seguridad. Y odio a los administradores de contraseñas ...

Tener un requisito de contraseña dificulta la automatización de las copias de seguridad, y la necesidad de proporcionar la contraseña en un env o un archivo de script hace que toda la seguridad sea inútil en primer lugar.

la necesidad de proporcionar la contraseña en un env o un archivo de secuencia de comandos hace que toda la seguridad sea inútil en primer lugar.

Eso no es necesariamente cierto. Hay buenas formas de hacerlo.

Eso no es necesariamente cierto. Hay buenas formas de hacerlo.

Por favor, no repita este argumento aquí. Muchos usuarios necesitan realizar copias de seguridad con contraseña vacía o sin cifrar. Si no eres uno de ellos, bien por ti.

@mholt , ¿alguna recomendación? Estaría más que feliz de hacer una copia de seguridad de mis servidores sin interferencias con la máxima seguridad.

Muchos usuarios necesitan realizar copias de seguridad con contraseña vacía o sin cifrar.

Suele ser un problema XY .

@mholt , ¿alguna recomendación? Estaría más que feliz de hacer una copia de seguridad de mis servidores sin interferencias con la máxima seguridad.

Depende en gran medida de su situación específica, modelo de amenaza, entorno, riesgos aceptables y objetivos técnicos y de usabilidad. Así que no, no tengo un conjunto general de recomendaciones para nadie.

Suele ser un problema XY.

Así que no, no tengo un conjunto general de recomendaciones para nadie.

Esa actitud condescendiente no ayuda. Mucho peor que después de decirnos que nuestras necesidades son incorrectas, se niega a ofrecer ningún consejo. Este es un proyecto de software libre, no de Apple, Inc.

Por ejemplo, no necesito ni quiero cifrar mis copias de seguridad locales de mis datos que ya no están cifrados. Si mi disco principal falla y necesito recuperar mis copias de seguridad, la frase de contraseña se almacena dentro del repositorio de copias de seguridad con mis scripts de copia de seguridad y archivos de configuración. Mi principal preocupación es no evitar que otros accedan a estos datos no confidenciales; mi principal preocupación es la fácil recuperación y no quedar bloqueado mis datos.

Este es un caso común para muchos usuarios, y no le corresponde a usted decidir cuáles son las necesidades de los usuarios.

El software existe para servir a los usuarios, no para obligar a los usuarios a aceptar sus demandas.

Gracias por explicar su (s) caso (s) de uso y sus inquietudes nuevamente. Para que conste, creo que son válidos, especialmente el de "contraseña perdida". También creo que una bandera especial para restic init como --allow-empty-password funcionaría (tengo algunas consideraciones para casos de esquina, pero estoy seguro de que se pueden resolver). Por lo tanto, reabriré este problema.

Tenga en cuenta que permitir contraseñas vacías solucionará el problema de seguridad de la "contraseña perdida", pero seguirá cifrando todos los datos como de costumbre.

En una nota diferente, no me gusta el tono en este hilo en absoluto. Eres libre de no usar restic, eso está perfectamente bien. La mayoría de nosotros estamos trabajando en descanso en nuestro tiempo libre. Algunos comentarios en este hilo parecen muy titulados, parafraseados: "debes implementar esta función, ¡hay usuarios que la necesitan!". Ese no es el caso. Podemos considerarlo e implementarlo, pero también podemos decidir no hacer nada.

Entonces, por favor, todos, mantengamos esta discusión productiva, incluso si no están de acuerdo. :)

@ fd0 Perdóname por no ser claro. No exijo ni espero nada de ti ni de ningún desarrollador de Restic. Es tu proyecto y tu tiempo, y puedes trabajar en lo que quieras.

Lo que le pido es que considere esta característica y caso de uso. Si no está interesado en implementarlo usted mismo, está bien, y le pido que deje el tema abierto para que otros puedan discutirlo y que considere cualquier RP que pueda implementarlo.

Lo que me opongo son los comentarios (no los suyos) que sugieren que los usuarios que desean esta función no comprenden sus propias necesidades, especialmente cuando se niegan a sugerir alternativas. Eso es ruido grosero e inútil.

Para mí, estoy usando git-Annex con un control remoto especial de bup. Annex ya admite el cifrado de archivos (que desactivé, para hacer uso de la función de deduplicación de bup). Y luego hago una copia de seguridad del repositorio bup (que es solo un repositorio git elegante) en un servidor remoto. Luego puedo eliminar el repositorio bup, ya que es solo un caché, y realizar una restauración a través de restic, según sea necesario.

Entonces, básicamente, estoy uniendo un montón de herramientas de un solo uso, al estilo Unix (tm), ya que cada una hace bien lo suyo. Restic (actualmente estoy cambiando de duplicidad) realiza la deduplicación de bloques de ventanas deslizantes a una nube remota, y eso es todo lo que necesito que haga. El cifrado y la deduplicación de bloques locales ocurren en una capa diferente. Por lo tanto, no quiero que se especifique una contraseña ni ningún cifrado (que en realidad ahorra en el uso de la CPU).

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

Esto es solo la mitad de lo que quiero, ya que todavía está encriptado, pero con una contraseña en blanco. Me gustaría recuperar ese uso de la CPU, si pudiera.

Tenga en cuenta que permitir contraseñas vacías solucionará el problema de seguridad de la "contraseña perdida", pero seguirá cifrando todos los datos como de costumbre.

Hm, ¿cuál es la motivación detrás de seguir encriptando con una contraseña vacía?

Quiero decir, cuando se ejecuta restic en hardware de baja potencia, el cifrado agrega una sobrecarga notable en el tiempo de ejecución.

Editar: Ok, https://github.com/restic/restic/issues/1018#issuecomment -307549863 - especialmente el segundo punto responde a mi pregunta.

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

El principal problema con esta sugerencia es: simplemente no funciona, restic solicita una contraseña de forma interactiva y luego:

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

Gracias, @ fd0 , por reabrir el problema. Estoy de acuerdo con @alphapapa , mi intención no es presionar a ningún desarrollador de tiempo libre para que dedique su tiempo a algo con lo que no se divierte.

Simplemente no nos gusta que otros nos digan que no entendemos nuestra propia necesidad.

En mi opinión, la característica más importante de una herramienta de copia de seguridad es la capacidad de realizar una restauración en cualquier caso. Aunque la seguridad tiene una importancia muy, muy alta, depende de la situación específica si la seguridad de los datos (capacidad de restaurar) o la seguridad de los datos (proteger contra el acceso no autorizado) tiene una prioridad más alta.

Por supuesto, puede decidir libremente desarrollar una herramienta solo para situaciones en las que la seguridad es más importante que la seguridad.

Como @mholt mencionó "XY-Problema": La solicitud es poder hacer una recuperación de desastres sin ningún conocimiento más allá de una documentación restic genérica disponible públicamente y, por supuesto, el acceso al repositorio en sí.
"Sin ningún conocimiento" excluye la necesidad o el uso de administradores de contraseñas.

La razón por la que encontré este problema es: _Estoy ayudando a algunas personas con sus PC en privado. Su manejo de contraseñas es un desastre, tratar de enseñarles el manejo adecuado de contraseñas mientras configuran una copia de seguridad en unidades USB solo resultará en no crear copias de seguridad en absoluto o en no tener una contraseña disponible cuando sea necesario. Es posible que reciban ayuda de otra persona cuando necesiten una restauración, por lo que cualquier cosa que se me ocurra para mitigar la situación podría ser nula.

En este momento, estoy guardando la contraseña en un archivo de texto en la misma unidad USB que el repositorio de respaldo restic, lo que arruina la seguridad de tener una contraseña por completo.
Y no me gusta esta solución, ya que usar una contraseña que no proporciona ninguna capa adicional de seguridad da una idea de seguridad muy equivocada.

Por supuesto, aquí solo estoy hablando de copias de seguridad locales personales. Para los servidores, recomiendo que se copien contraseñas seguras en algún almacenamiento fuera de línea independiente.

Creo que otro problema aquí es; si algunos frameworks / API permiten contraseñas vacías y otros no. Y uno tiene que descifrar una entrada que fue cifrada por otra API con contraseña vacía. Este es actualmente mi problema con https://github.com/RNCryptor/JNCryptor

Entonces, por favor, todos, mantengamos esta discusión productiva, incluso si no están de acuerdo. :)

Después de leer este hilo, encuentro que la conversación es productiva, porque el resultado fue positivo.

Me gustaría recordarles a todos que esto es Github; si se siente muy atraído por algo y el encargado del mantenimiento del proyecto no es receptivo, no dude en hacer una bifurcación; literalmente, lleva unos segundos. Si no tiene la habilidad para hacer el cambio usted mismo, pida a otros que lo ayuden. Descubrirá que los mantenedores pueden estar más abiertos a aceptar un parche que implemente algo que ellos mismos no hubieran estado motivados a implementar.

Personalmente, en este caso, creo que imponer a todo el mundo una idea preconcebida de lo que "debería" ser la seguridad es un error. La primera regla de seguridad de los datos es que los datos deben ser accesibles para quienes tienen derecho a tenerlos. Cualquier regla que comprometa la regla n. ° 1 debe considerarse con el debido cuidado.

La seguridad es un tema que está lleno de FUD y políticas impulsadas por el miedo, lo que resulta en implementaciones ingenuas, apresuradas y, a menudo, hipócritas, porque a pocos de nosotros realmente les gusta pensar en todas las cosas que pueden salir mal. Menos aún queremos enfrentar las críticas de los demás cuando se nos ve que permitimos que las cosas salgan mal.

Algunos errores comunes que vemos todos los días:

1) Insistir en que los datos escritos en un medio que está encriptado en reposo deben estar encriptados, incluso en un entorno confiable. ¿Dónde termina el miedo a la interceptación? ¿Dónde comenzamos a confiar en que el usuario podría ser potencialmente competente y que agregar capas redundantes simplemente aumenta el riesgo de pérdida de datos?

2) Insistir en una contraseña de un formato específico, es decir, 8 caracteres con al menos una letra mayúscula, un número y uno no alfanumérico: esta fue una práctica común durante 20 años y ahora ha sido desacreditada porque el dolor excede la ganancia. En su lugar, deberíamos insistir en contraseñas memorables y de alta entropía como xkcdpassword , o integrarlas con un administrador de contraseñas (que efectivamente hace que todos los consumidores clave dependan de una contraseña maestra SPOF de seguridad compartida que pueda ser atacada, solo pregunte a COMMODO) o integrar 2FA (potencialmente mejor dependiendo de la seguridad física del segundo factor, incluida la redundancia de clave N + 1).

3) Con una contraseña maestra: si no se almacena en caché en una sesión, el usuario se ve obligado a ingresar tantas veces durante el día que la misma acción de ingresar se convierte en un vector de ataque conspicuo.

4) Con una contraseña maestra: no verificar las políticas y consultar ciegamente la contraseña maestra de modo que el usuario se acostumbre a presentarla cuando en realidad no debería ser requerida, lo que hace que deje de analizar críticamente si debe o no proporcionarla en esta instancia.

5) Hacer cumplir una política de privilegios mínimos hasta el punto de que los usuarios la resientan y eviten participar, o encontrar formas de evitarla, dejando la puerta abierta mucho más tiempo que si hubiera un esquema más permisivo.

6) Hacer cumplir una política de privilegios mínimos sin redundancia N + 1, también conocida como falta de consideraciones de "continuidad del negocio / política de hombre clave". es decir, en lugar de bloquear un recurso compartido detrás de 2 claves privadas para que solo se pueda acceder a él cuando ambos estén de acuerdo (quórum de 2), ciérrelo detrás de 2 de 3 claves privadas. Nadie vive para siempre.

Cada vez que nosotros, como programadores, estamos implementando un esquema de cifrado de clave única, debemos considerar la importancia de la accesibilidad y escuchar las preocupaciones de aquellos que son dolorosamente conscientes de las consecuencias de la pérdida de clave para un esquema de cifrado de clave única.

También tratemos de recordar amablemente que quitarles cosas a los usuarios simplemente por temor al uso indebido, es fundamentalmente incorrecto, como casi todas las decisiones que se toman por temor. Castigar a todos porque alguien podría hacer algo incorrecto disminuye a la sociedad en su conjunto.

Si siente en este momento que no está de acuerdo con ese concepto, entonces respire hondo, cuente hasta diez, luego considere esto: ¿Qué debemos hacer como sociedad cuando alguien se suicida metiendo la cabeza en una bolsa de basura con una lata de rociar crema batida e inhalar toda la lata de óxido nitroso? ¿Deberíamos quitarles la crema batida en aerosol a todo el mundo? ¿Bolsas de plástico? ¿Respiración? Todas estas cosas se pueden utilizar de forma incorrecta y provocar la muerte del usuario.

En lugar del impulso instintivo de quitar cosas, como haríamos con un niño que juega con fósforos, deberíamos pecar de educar a las personas para que las utilicen correctamente. O subir el listón de entrada de modo que solo lo encuentren aquellos que RTFM.

Eso es lo que sucedió al final aquí, y la decisión de aceptar ese resultado no llegó hasta que todos los problemas y opiniones ya se expresaron. Recomiendo ver las sesiones de debate parlamentario en las estaciones de televisión públicas para ver ejemplos de cómo suena un debate improductivo, jajaja. Los participantes aquí fueron excepcionalmente respetuosos entre sí en comparación.

Recuerde las viejas y buenas utilidades de archivo en las que el cifrado y la protección con contraseña estaban disponibles solo como opciones explícitas, pero no de forma predeterminada. Y esta es la lógica correcta porque la seguridad puede tener muchas soluciones externas fuera del alcance de esta utilidad y porque este cuidado depende del usuario. Lo que hace es simplemente proporcionar las herramientas de seguridad que eligen los usuarios. Pero el autor prefiere cuidar lo que el usuario no pide para evitar un mal uso.

Y nuevamente sobre el tono. Esto es habitual en el mundo del código abierto. Y está respaldado por algún mecanismo psicológico. Las críticas con las que los autores no están de acuerdo se tratan como una pretensión de dedicar su tiempo libre. Y cada vez tenemos que recordar: aquí no hablamos de Tu tiempo libre, sino que exploramos Tu criatura genial, su funcionalidad y la lógica detrás de ella. Nunca olvidamos que no tiene la obligación de satisfacer nuestra demanda y tiene pleno derecho a no hacer nada en absoluto. Pero si te gusta lo que haces, puede ser (quizás) porque a otros les gusta. Por lo tanto, puede existir alguna esperanza de que esté interesado en satisfacer la demanda al menos de la mayoría.

PD: Todos estos son solo despotricar abstractos y no se pretenden acciones de práctica.

Hay una cosa que nunca he entendido con la discusión sobre no permitir contraseña para un repositorio (asumiendo que el contexto que @ fd0 escribió antes, que los datos aún estarán encriptados); ¿Por qué aquellos que "no quieren" una contraseña simplemente usan una contraseña ficticia como "1234" o lo que sea? ¿Cuál es el punto de escribir código en restic que elimine la contraseña, cuando si no le importa tener una contraseña, puede usar una contraseña ficticia? Es una variable de entorno o un archivo de contraseña de distancia, si cree que es engorroso escribirlo en la línea de comando cuando se ejecuta restic.

@rawtaz Esto ha sido respondido en comentarios anteriores en este hilo.

Solo déjeme decir que restic init -r foo --no-password es probablemente un mejor nombre de bandera que restic init -r foo --allow-empty-password , simplemente porque el primero es más preciso y el segundo es demasiado detallado.

No veo ningún buen argumento de por qué el solo uso de una contraseña ficticia no es una forma perfectamente viable de hacer esto en lugar de aumentar la base de código restic en este tema. He visto a alguien decir que podría olvidar la contraseña "a". Si bien eso puede ser cierto, seguramente es posible inventar una contraseña ficticia simple y recordarla, o al menos descubrirla de nuevo cuando sea necesario. Pero lo que sea, una bandera también funciona bien, me sorprende lo grande que parece ser este problema: D

Bueno, aquí tienes un ejemplo. Hice una copia de seguridad inquieta hace un año. Escrito un
contraseña ficticia, leída de un archivo. No escribí la contraseña
en cualquier otro lugar. Después de un año de no usar esa máquina, por completo
Olvidé tanto el proceso como la contraseña, y perdí una hora tratando de
adivina la contraseña antes de encontrarla (e ingeniería inversa)
la secuencia de comandos. Es mi culpa por completo, pero aún así, no necesito la seguridad,
y no quiero que te obliguen a recordar una contraseña ficticia. Y si yo
si no hubiera tenido acceso a los archivos originales, me habrían bloqueado.

TD

¿No es eso una cuestión de haberlo complicado demasiado? Una de las contraseñas más comunes es 1234. Úsalo y no tendrás que intentar encontrarlo en alguna parte (asumiendo que no crees que usaste una más compleja) porque cuando necesitas ingresar una contraseña ficticia sabes que es 1234. Pero claro, entiendo lo que quieres decir.

También me gustaría ver una opción para permitir una contraseña vacía (mediante el uso de la bandera --allow-empty-password , o quizás algo más detallado / único para resaltar el riesgo, como la bandera --dont-blame-nrpe NRPE).

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

Entiendo la necesidad de una frase de contraseña para garantizar la integridad de los datos y el cifrado. Veo que los archivos en el directorio keys parecen ser un objeto JSON. ¿Quizás podría generarse una clave pseudoaleatoria (en lugar de ninguna clave) y almacenarse allí? Sin embargo, esto no ayuda a los usuarios que intentan evitar la sobrecarga del cifrado por razones de rendimiento.

• Negocios: tenemos un repositorio contenido en un entorno confiable del que necesitamos que "cualquiera" pueda restaurar en caso de emergencia / desastre sin tener que tener conocimientos especiales (es decir, una contraseña de repositorio).

Pero esos "cualquiera" ya necesitan conocimientos / instrucciones especiales. Necesitan saber cómo ejecutar restic para restaurar datos, incluido qué repositorio usar y otras cosas, y luego sería increíblemente fácil incluir una contraseña ficticia en esas instrucciones. O usarían un script o una automatización similar que realiza la restauración por ellos (en cuyo caso todavía necesitan saber / obtener instrucciones sobre dónde ir para usar esa herramienta), en cuyo caso la contraseña ficticia sería manejada por el script. . No importa cómo mire esto, una contraseña ficticia no es un problema. Y en serio, si todo el mundo lo olvida de repente, la gente podrá simplemente adivinar 1234 o usar la fuerza bruta. No es un problema: P

• Inicio: Me gustaría crear una copia de seguridad restringida de cosas como fotos familiares. Estos no son particularmente confidenciales y, en el caso de mi fallecimiento prematuro, mi familia debe poder acceder a estos datos personalmente importantes con una resistencia mínima (_por ejemplo, sin tener que encontrar una frase de contraseña en una caja fuerte, que posiblemente esté fuera de ... fecha o mezclada con otra_).

¿Esperar lo? ¿Por qué diablos querría no tener contraseña, y cuando eso no es posible (al menos actualmente) usar una contraseña ficticia súper simple (por ejemplo, 1234), y luego poner esa contraseña ficticia súper simple en una caja fuerte ? Eso sería completamente inútil. Colóquelo en otro lugar, y por lo que vale, probablemente ya tenga un montón de otra información que su familia necesita saber en el caso de su fallecimiento, así que solo coloque su contraseña ficticia junto con eso.

Finalmente, una contraseña ficticia debe ser tan simple y obvia que no quede desactualizada y no es necesaria más de una contraseña ficticia. Por lo tanto, no debe estar desactualizado ni mezclado con otro.

Sí, esas sugerencias ya se han hecho, por lo que ahora vamos en círculos. Hablando personalmente, no son soluciones adecuadas con las que me sienta cómodo para mi entorno y casos de uso.

No necesita esta función, está bien. Eso no significa que los casos de uso de todos los demás no sean válidos. No tengo un uso para el backend de Amazon S3, pero no lo declaro innecesario, simplemente no lo uso. Si esta función está implementada, no le costará nada no usarla.

Sí, esas sugerencias ya se han hecho, por lo que ahora vamos en círculos.

Sí, y honestamente, todavía no he visto una explicación real de por qué una contraseña ficticia es tan difícil de manejar, siento que en su mayoría he visto complicaciones excesivas.

Hablando personalmente, no son soluciones adecuadas con las que me sienta cómodo para mi entorno y casos de uso.

Esto es algo que respeto totalmente. El caso de uso de todos es individual y usted tiene su flujo de trabajo :)

Supongo que en algún momento obtendremos un --no-password o similar, con suerte eso también resolverá este caso de uso. ¡Gracias por tu contribución!

rawtaz escribió

Solo déjeme decir que restic init -r foo --no-password es probablemente un mejor nombre de bandera que restic init -r foo --allow-empty-password , simplemente porque el primero es más preciso y el segundo es demasiado detallado.

No veo ningún buen argumento de por qué el solo uso de una contraseña ficticia no es una forma perfectamente viable de hacer esto en lugar de aumentar la base de código restic en este tema. He visto a alguien decir que podría olvidar la contraseña "a". Si bien eso puede ser cierto, seguramente es posible inventar una contraseña ficticia simple y recordarla, o al menos descubrirla de nuevo cuando sea necesario. Pero lo que sea, una bandera también funciona bien, me sorprende lo grande que parece ser este problema: D

No me preocupa el uso / manejo de contraseñas ficticias; en cambio, a veces me preocupa que el uso de la CPU ralentice el proceso de copia de seguridad mediante el cifrado obligatorio cuando se ejecuta en hardware de gama baja.

Resolver # 1018 (copias de seguridad no cifradas) también resolvería este problema, es decir, con un interruptor --unencrypted lugar de --no-password .

De hecho, usé restic en hardware de gama baja donde la CPU definitivamente no tenía AES-NI (o una extensión similar) y donde la copia de seguridad estaba vinculada a la CPU. En otro caso, la CPU era un poco más potente, pero el único disco duro externo disponible ya estaba cifrado con LUKS y, por lo tanto, estaba vinculado a la CPU porque no era lo suficientemente potente como para manejar dos procesos de cifrado en paralelo.

Véase también: https://github.com/restic/restic/issues/1018#issuecomment -307549863

Si olvidas cómo usar restic, puedes leer los documentos. Si olvida la ubicación de un repositorio, puede encontrarla. O puede encontrar un repositorio huérfano casual y preguntarse qué hay en el interior. Pero si olvidó la contraseña, perderá sus datos para siempre. Y en la vida real, puede olvidar cualquier contraseña ficticia más simple. Puedes olvidarte de todo lo que no usas a menudo.

Si pierde la contraseña de root, puede iniciar con la opción init = / bin / bash y obtener acceso completo. Si bien este agujero podría cerrarse, todavía existe en la mayoría de los sistemas. ¿Por qué? Porque la pérdida por indisponibilidad sería más que por inseguridad en esos casos. Por lo tanto, es un compromiso entre seguridad y disponibilidad. Para los sistemas con requisitos más altos, existen soluciones especiales, como claves redundantes, que brindan seguridad y disponibilidad.

resitc no es una herramienta de seguridad. Es una herramienta de respaldo. Y como tal, debe proporcionar la funcionalidad de copia de seguridad en sí mismo en primer lugar, y solo luego seguridad. Por lo tanto, la protección por contraseña y el cifrado podrían proporcionarse solo como opciones y no deberían estar en su lugar de forma predeterminada.

Por cierto: los valores predeterminados son la marca de la calidad del software.

@vstavrinov Lea la introducción a restic antes de decir que no es una herramienta de seguridad. Es una herramienta de copia de seguridad cuya característica principal es que intenta hacer que sus copias de seguridad sean seguras. Entonces, estás bastante lejos cuando dices que no se preocupa por la seguridad.

Pero si olvidó la contraseña, perderá sus datos para siempre.

Sí, y es por eso que usted (en este caso tiene la opción simple de) usar una contraseña ficticia para que siempre pueda darse cuenta de la contraseña incluso si la olvidara.

Y en la vida real, puede olvidar cualquier contraseña ficticia más simple.

Si lo hace, eligió una contraseña ficticia demasiado compleja, y en realidad ya no es una contraseña ficticia simple.

Francamente, toda esta discusión se está volviendo hilarantemente tonta. No puedo creer que la gente esté diciendo que una contraseña como 1234, que es una de las más comunes y obvias, es algo que podrían olvidar y luego no ser capaces de descifrar rápidamente contraseñas). Yo diría que tienes que esforzarte mucho para no ser capaz de "adivinar" 1234 cuando estás en esa situación, e incluso entonces probablemente fallarás en no adivinarlo.

Pero si olvidó la contraseña, perderá sus datos para siempre.

Wikipedia puede ayudarte: prueba las contraseñas más comunes de https://en.wikipedia.org/wiki/List_of_the_most_common_passwords#List.

Una situación en la que esto puede suceder es cuando la variable de entorno RESTIC_PASSWORD no se exporta o no se establece en la cadena vacía accidentalmente.

Es posible que el código verifique si una contraseña se estableció en una cadena vacía explícitamente o simplemente no se estableció (no se especificó una opción de línea de comando, la variable de entorno no se estableció -> diferente de una cadena vacía).

Creo que el usuario debe elegir qué contraseña desea elegir.

Resolver el # 1018 (copias de seguridad sin cifrar) también resolvería este problema, es decir, con un conmutador --unencrypted en lugar de --no-password.

El cifrado debería seguir siendo obligatorio para proteger contra la búsqueda binaria en un proveedor de alojamiento independientemente del formato, la transmisión a través de un canal no cifrado con MITM, etc. Si bien esto le brinda tanta protección como una contraseña vacía para ataques dirigidos (cero), aún evita daños colaterales en ataques no dirigidos.

@rawtaz

Es una herramienta de copia de seguridad cuya característica principal es que intenta hacer que sus copias de seguridad sean seguras. Entonces, estás bastante lejos cuando dices que no se preocupa por la seguridad.

No muy lejos. Indícame dónde digo "no se trata de seguridad". Yo no. Dices lo mismo: "Es una herramienta de respaldo". La copia de seguridad no es seguridad, ¿verdad ?. Tan restic no es una herramienta de seguridad. Y "... una de las características principales ...". Tienes razón de nuevo: es una característica. es decir, la seguridad es una característica, mientras que una copia de seguridad es una designación funcional (objetivo).

@rawtaz

Francamente, toda esta discusión se está volviendo hilarantemente tonta. No puedo creer que la gente esté diciendo que una contraseña como 1234 ...

No puedo hacer nada, pero tú también tienes razón en este caso. Lo que es tonto es una discusión sobre una contraseña ficticia. Pero creo que lo más importante es comprender que la protección por contraseña y el cifrado deben ser opcionales. Además de no imponer a los usuarios funciones adicionales no deseadas, dejándoles la opción de usarlas o no. Y esta es también la marca de la calidad del software.

Pero creo que lo más importante es comprender que la protección por contraseña y el cifrado deben ser opcionales.

¿Por qué? ¿Por qué "debería" una herramienta de copia de seguridad no tener cifrado predeterminado? ¿Solo porque es una herramienta de "copia de seguridad"? Solo dices esto, pero no hay razón para esto.

Ninguna decisión de diseño puede complacer a todos. Restic _elige_ poner un gran énfasis en la seguridad, y a los usuarios como yo _ les encanta_ que el cifrado fuerte es el predeterminado.

• Si no le importa la seguridad, _no_ puede_ hacer un mal uso de un sistema seguro por defecto. En el peor de los casos, verá algunos errores y volverá a intentarlo con un comando ajustado.
• Si le preocupa la seguridad, hay muchas formas de hacer un mal uso de un sistema inseguro por defecto con un efecto catastrófico. Falta una bandera y sus datos confidenciales se filtran, tal vez _reversiblemente_.

Una cosa es pedir una bandera que pueda omitir la contraseña, pero argumentar que no hay cifrado por defecto es un peligroso "jodido" para todos los usuarios existentes que confían en el cifrado de Restic. El potencial de errores catastróficos del usuario es enorme.

@cfbao

Pero creo que lo más importante es comprender que la protección por contraseña y el cifrado deben ser opcionales.

¿Por qué? ¿Por qué "debería" una herramienta de copia de seguridad no tener cifrado predeterminado? ¿Solo porque es una herramienta de "copia de seguridad"? Solo dices esto, pero no hay razón para esto.

"opcional" no es lo mismo que "predeterminado". Los incumplimientos como tales pueden ser discutibles. Pero tener opciones es más importante. Si bien no tenemos otra opción, no hay nada que ver con los valores predeterminados. Ese es el punto. Primero brinde opciones, luego tiene sentido discutir los valores predeterminados.

En este caso (problema) es bastante simple: probablemente habrá un --no-password o un indicador similar en restic init (siendo el valor predeterminado que restic solicita una contraseña al iniciar), pero esto es solo mi opinión sobre la última respuesta de @ fd0 . Y no hay ETA en este punto, no es necesario preguntar sobre eso :)

Mientras tanto, use una contraseña ficticia :) Supongo que una implementación adecuada incluye la capacidad de eliminar / desarmar una contraseña / clave que se usó anteriormente para iniciar el repositorio, por lo que no debería tener que volver a crear todo el repositorio.

Sin embargo, el cifrado es otra cosa y se rastrea en ese otro problema.

No me importa demasiado la opción sin contraseña, pero usted estaba argumentando que no hay cifrado predeterminado:

Por lo tanto, la protección por contraseña y el cifrado podrían proporcionarse solo como opciones y no deberían estar en su lugar de forma predeterminada.

Por cierto: los valores predeterminados son la marca de la calidad del software.

que encuentro peligroso.

Aunque generalmente estoy de acuerdo con los puntos de @rawtaz , si la discusión es estrictamente sobre una opción sin contraseña (sin cambiar la predeterminada), no tengo mucho interés en ella.

@cfbao

No me importa demasiado la opción sin contraseña, pero usted estaba argumentando que no hay cifrado predeterminado:

Por lo tanto, la protección por contraseña y el cifrado podrían proporcionarse solo como opciones y no deberían estar en su lugar de forma predeterminada.

Puede ver incluso en esta cita que las "opciones" son las primeras y las "predeterminadas" son las siguientes. Y ese es el punto nuevamente.

En este caso (problema) es bastante simple: probablemente habrá un --no-password o un indicador similar en restic init (siendo el valor predeterminado que restic solicita una contraseña al iniciar), pero esto es solo mi opinión sobre la última respuesta de @ fd0 . Y no hay ETA en este punto, no es necesario preguntar sobre eso :)

Mientras tanto, use una contraseña ficticia :) Supongo que una implementación adecuada incluye la capacidad de eliminar / desarmar una contraseña / clave que se usó anteriormente para iniciar el repositorio, por lo que no debería tener que volver a crear todo el repositorio.

Una solución probablemente más simple sería que restic admita una contraseña ficticia que intentará abrir un repositorio existente si el usuario no especifica ninguna contraseña.

Con respecto al manejo de contraseñas ficticias: No existe una contraseña ficticia clara que funcione para todos. 1234 es una contraseña ficticia molesta ya que requiere cuatro dedos para moverse hacia arriba y escribir. "asdf" es mucho más rápido de escribir, por ejemplo. Además, algunos servicios restringen las opciones de contraseña, por lo que es posible que no sea posible utilizar solo números o solo cuatro dígitos. Por lo tanto, una solución dentro de restic sería muy fácil de usar. Entonces, los usuarios solo tendrían que escribir la contraseña ficticia una vez.

Desde la perspectiva de la seguridad por diseño, proporcionar cualquier tipo de contraseña ficticia es una mala idea.

Si alguien realmente quiere eludir el cifrado o no lo necesita, simplemente proporcione una contraseña coherente. No tiene que escribirlo, puede escribir un script para ajustar el código rígido y resticido al contenido de su corazón allí. Realmente, ¿es más trabajo que proporcionar la dirección del repositorio u otras opciones de configuración?

Hacer que restic pruebe un conjunto de contraseñas codificadas falsas o ficticias es solo buscar problemas. ¿Qué pasa si algún pobrecito elige una de sus contraseñas "mágicas" propuestas? ¿Les advertimos que no elijan nuestras contraseñas especiales de cifrado falsas y ficticias? "No Ted, no puedes elegir SPACECHICKEN como tu contraseña de repositorio, es _especial_". ;)

Estoy de acuerdo con ofrecer una opción para que los usuarios se disparen en el pie con ("--no-repository-password") pero no creo que restic deba ir más allá para apaciguar al pequeño segmento de usuarios que Deseo seguridad REDUCIDA.

Desde la perspectiva de la seguridad por diseño, proporcionar cualquier tipo de contraseña ficticia es una mala idea.

¿Por qué es peor que no permitir ninguna contraseña?

Si alguien realmente quiere eludir el cifrado o no lo necesita, simplemente proporcione una contraseña coherente. No tiene que escribirlo, puede escribir un script para ajustar el código rígido y resticido al contenido de su corazón allí. Realmente, ¿es más trabajo que proporcionar la dirección del repositorio u otras opciones de configuración?

Sí, es más trabajo. Restic sería la solución de respaldo y su salida es el repositorio. Entonces, idealmente, el repositorio contendría todo para restaurar la copia de seguridad. Pero cuando se usa una secuencia de comandos de envoltura que codifica la contraseña ficticia, significa que esta secuencia de comandos debe ser respaldada por otra cosa, de lo contrario, el repositorio sería inútil.

Hacer que restic pruebe un conjunto de contraseñas codificadas falsas o ficticias es solo buscar problemas. ¿Qué pasa si algún pobrecito elige una de sus contraseñas "mágicas" propuestas? ¿Les advertimos que no elijan nuestras contraseñas especiales de cifrado falsas y ficticias? "No Ted, no puedes elegir SPACECHICKEN como tu contraseña de repositorio, es _especial_". ;)

¿Cuál es exactamente el problema? Ted aún puede elegir esta contraseña. Solo significa que restic lo usará convenientemente si no lo especifica. Restic aún cifraría / descifraría el repositorio de la misma manera que si no fuera una contraseña especial.

Estoy de acuerdo con ofrecer una opción para que los usuarios se disparen en el pie con ("--no-repository-password") pero no creo que restic deba ir más allá para apaciguar al pequeño segmento de usuarios que Deseo seguridad REDUCIDA.

Llamar a esto "dispararse en el pie" es innecesariamente crítico y tampoco implica menor seguridad. La disponibilidad y la resistencia frente al ransomware deben formar parte de un concepto de seguridad. La falta de capacidad para restaurar una copia de seguridad debido a la falta de acceso a la contraseña de cifrado reduciría la seguridad. Almacenar la copia de seguridad de forma segura en un sistema de almacenamiento de solo adición no disminuiría el nivel de seguridad aquí.

Why is it worse than allowing no password?

No estoy seguro de cómo podría convencer a alguien de que las contraseñas codificadas, ocultas y secretamente probadas contra los repositorios serían una mala idea. Si cree que lo son, es probable que no exista un argumento centrado en la seguridad que lo convenza.

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.

Elegí un ejemplo entretenido, quizás no debería haberlo hecho. Supongamos que su contraseña ficticia que desea que se reste a probar en secreto y automáticamente si falla el descifrado es: "12345". Un usuario ingenuo podría muy bien elegir eso como su contraseña. Ahora tienen un repositorio que creen que está encriptado (y más o menos lo está) pero que _cualquier persona_ restic puede desencriptar. Este argumento se aplica a cualquier conjunto de contraseñas que elija en su conjunto codificado. Este es un diseño de seguridad fundamentalmente malo.

Hay un término para lo que propones. Se llama puerta trasera de cifrado :) Ocultar esa puerta trasera en los documentos supone que todos los lectores leerán completamente el manual antes de usar restic. ¿No serviría a las necesidades de más personas hacerles leer los documentos para determinar cómo disminuir la seguridad si extrañamente lo desearan?

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 no cree que el cifrado en reposo es una política de seguridad sólida y optaría por otra cosa, ciertamente se encuentra en la minoría profunda. Este tipo de incumplimientos inseguros no le sirven a nadie y deben desalentarse en todo momento. Solo es necesario consultar CUALQUIER referencia de seguridad para obtener consejos en este caso. Mi punto no es polémico, estoy defendiendo la práctica estándar de la industria.

Incluso su ejemplo de agregar solo medios de almacenamiento se beneficiaría enormemente del cifrado en reposo. Recomiendo encarecidamente leer un conjunto reciente de NIST, ISO 27002, NERC, IEC 62443 o realmente cualquier estándar aceptado a nivel mundial para obtener orientación sobre las mejores prácticas aquí. No estamos en un territorio nuevo.

También debo señalar que estamos combinando efectivamente dos cuestiones en este hilo: administración de claves y cifrado.

Quizás ahí es donde surge la confusión.

Quizás este problema se pueda resolver con documentación que diga algo como:

Si no desea proteger su repositorio con una contraseña, simplemente use la cadena: password

De esa manera, existe una forma bien conocida de lograr una copia de seguridad / restauración con restic sin tener que administrar ninguna clave.

Why is it worse than allowing no password?

No estoy seguro de cómo podría convencer a alguien de que las contraseñas codificadas, ocultas y secretamente probadas contra los repositorios serían una mala idea. Si cree que lo son, es probable que no exista un argumento centrado en la seguridad que lo convenza.

Supongo que te falta un "no" allí ...

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.

Elegí un ejemplo entretenido, quizás no debería haberlo hecho. Supongamos que su contraseña ficticia que desea que se reste a probar en secreto y automáticamente si falla el descifrado es: "12345". Un usuario ingenuo podría muy bien elegir eso como su contraseña. Ahora tienen un repositorio que creen que está encriptado (y más o menos lo está) pero que _cualquier persona_ restic puede desencriptar. Este argumento se aplica a cualquier conjunto de contraseñas que elija en su conjunto codificado. Este es un diseño de seguridad fundamentalmente malo.

No me propuse probarlo cuando falla el descifrado, pero cuando no se especifica una contraseña para el descifrado. Si alguien elige una contraseña insegura, es insegura independientemente de que restic la haya intentado directamente o de que alguien forzara las contraseñas. "12345" también es una contraseña insegura hoy en día, y no cambiaría si se convirtiera en la contraseña predeterminada para restic.

Hay un término para lo que propones. Se llama puerta trasera de cifrado :) Ocultar esa puerta trasera en los documentos supone que todos los lectores leerán completamente el manual antes de usar restic. ¿No serviría a las necesidades de más personas hacerles leer los documentos para determinar cómo disminuir la seguridad si extrañamente lo desearan?

Una puerta trasera de cifrado sería si restic usara una contraseña predeterminada además de la contraseña proporcionada por el usuario al cifrar datos. Mi propuesta consiste en probar una contraseña en el descifrado. El usuario aún elegiría activamente esta contraseña incorrecta.

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 no cree que el cifrado en reposo es una política de seguridad sólida y optaría por otra cosa, ciertamente se encuentra en la minoría profunda. Este tipo de incumplimientos inseguros no le sirven a nadie y deben desalentarse en todo momento. Solo es necesario consultar CUALQUIER referencia de seguridad para obtener consejos en este caso. Mi punto no es polémico, estoy defendiendo la práctica estándar de la industria.

¿Cuál es el valor predeterminado inseguro en su opinión?

Incluso su ejemplo de agregar solo medios de almacenamiento se beneficiaría enormemente del cifrado en reposo. Recomiendo encarecidamente leer un conjunto reciente de NIST, ISO 27002, NERC, IEC 62443 o realmente cualquier estándar aceptado a nivel mundial para obtener orientación sobre las mejores prácticas aquí. No estamos en un territorio nuevo.

El cifrado en reposo no significa que Restic deba hacerlo. El almacenamiento de solo anexo aún se puede cifrar de alguna otra manera si es necesario. Sin embargo, habrá algo de almacenamiento no cifrado, incluso si es solo para la contraseña. De lo contrario, el concepto de copia de seguridad dependería de que alguien siempre recordara la contraseña.

anulando la suscripción a este hilo ...

Dejémoslo así, está claro que algunas personas quieren una opción --no-password para init , y de eso se trata este problema. El cifrado o no es un tema aparte.

Solo un comentario rápido aquí:
Soy un usuario al que no le importa el cifrado. No hay nada sensible sobre mis datos. Me importa que las personas que no sean yo puedan usar en 20-40 años. El simple hecho de usar rclone es otra alternativa más pobre.

Restic parece una buena herramienta para esto, excepto que el cifrado obligatorio y una contraseña significa que debo tener eso en cuenta. Quizás un archivo README en el repositorio de respaldo. Es más trabajo y cualquier solución (de mi lado) derrota cualquier cifrado de todos modos.

Marcos

Gracias por sus contribuciones, creo que hemos recopilado suficiente información.