algoritmo de generación de contraseña

La respuesta corta es No .

Este es un ejemplo clásico de Seguridad a través de la oscuridad que, aunque puede funcionar, a veces se considera una mala idea porque nunca funciona a largo plazo.

Como en mi respuesta a la otra pregunta, todo se reduce a modelado de amenazas . Considere los siguientes dos escenarios.

1) Los atacantes han descargado una base de datos de nombres de usuario y contraseñas con todas las contraseñas almacenadas como hashes SHA1. Usan tablas de arco iris o un diccionario de contraseñas comunes e intentan romper las contraseñas débiles.

¿Su sistema es más seguro? Sí , es poco probable que csbthaapolteotrerrryseect esté en un diccionario de contraseñas.

2) Los atacantes han descargado una base de datos de nombres de usuario y contraseñas con todas las contraseñas almacenadas como hashes SHA1. Están dirigidos a tú y conocen la función tu , o tal vez tu función se vuelva muy popular (como la de xkcd), por lo que los atacantes ejecutan tu función en su diccionario.

¿Su sistema es aún más seguro? No las personas buscarán csbthaapolteotrerrryseect y contraseñas similares.

El principio de Kerckhoffs se usa a menudo en criptografía y afirma que

  

Un criptosistema debe ser seguro, incluso si todo sobre el sistema, excepto la clave, es de conocimiento público.

Esta es una gran suposición y se usa en el cómic xkcd. Incluso si sabe todo acerca de cómo genero contraseñas (incluida la lista de palabras que uso), todavía hay 2 ^ 44 contraseñas posibles. Además, la gran ventaja del estilo xkcd es que es fácil de recordar y escribir.

  

una función que solo tú conocías

Bueno, tal bestia realmente no existe. Incluso si puede llegar a algún procedimiento de "mezcla" que viva solo en su cerebro, es bastante difícil cuantificar cuánto desconoce ese procedimiento para el atacante. Si dicha función existe como una secuencia de comandos o un archivo ejecutable en algún lugar, o como una descripción textual en alguna publicación de blog o documento de política para los usuarios, es excesivamente optimista creer que el atacante no lo sabe.

Una gran parte de la seguridad de las contraseñas, incluso de la seguridad en general, es saber qué tipo de "seguridad" alcanza realmente. Esto significa medidas, métricas ... Necesita esa información porque esa es la única manera de saber si los controles de seguridad valen la pena. Por ejemplo, una contraseña implica costos, en particular el tiempo empleado por el usuario para escribir esa contraseña. En un contexto empresarial, los costos se traducen en dinero; pero incluso para los individuos privados, los costos existen (por ejemplo, como tiempo empleado o como exasperación acumulada en el software tonto). Tu "función privada" tendrá que ser ejecutada en tu cabeza regularmente. ¿Será suficiente la ganancia en seguridad para compensar el esfuerzo extra? Para responder a esa pregunta, debes saber que "ganar en seguridad" ... y con una "función privada", eso es casi imposible.

Todo el punto de < fuerte> cálculos de entropía es proporcionar una buena medida matemática y confiable de seguridad. La única forma sensata de calcular las entropías es asumir que el atacante sabe todo cuya confidencialidad no se puede cuantificar. Básicamente, no podemos medir razonablemente cuánto es privada una función privada; para una palabra seleccionada al azar en una lista específica, sabemos cuánto desconoce el atacante: el atacante conoce la lista, no el índice seleccionado al azar.

Existe una amplia tradición de generar contraseñas acumulando operaciones semi-mágicas que se supone que "parecen seguras". Por ejemplo, las personas agregarán algunos signos de puntuación porque creen que un '$' o un ';' tiene alguna "seguridad inherente" que es más alta que la de una 'A' o una 'k'. Esto se relaciona con la noción de seguridad como un tipo de mercancía que usted simplemente acumula. Esta es, por supuesto, una manera muy pobre de pensar acerca de la seguridad. Esto sería como garantizar la seguridad de un servidor web contra ataques en línea manteniendo una guardia armada en la sala de servidores, y luego "duplicando la seguridad" agregando otra guardia. Esto sería ridículo, pero cuando se trata de contraseñas, la mayoría de las personas son ridículas.

Entonces, sea inteligente: no confíe en los rituales cuyos beneficios no se pueden medir ni estimar numéricamente.

Desde un punto de vista criptográfico, la gente le dirá que es incorrecto hacerlo. Ciertamente no es "más" o "igualmente" seguro, pero creo que es lo suficientemente seguro.

Desde un punto de vista práctico, para sus contraseñas personales, no siempre es posible recordar contraseñas como A4q!qtrqFET4KmpVW.?T5"r'&141EFQFSq . Si obliga a la gente a hacerlo de todos modos, terminará con notas adhesivas o papeles adheridos a una pantalla. Se puede argumentar que mantener las contraseñas en una nota en su billetera también puede considerarse seguro (simplemente no escriba los nombres de usuario y para qué los usa).

Es importante mantener el secreto de su sistema y no usarlo en exceso, quizás solo para las contraseñas que usa con frecuencia. Si puedes, debes usar un administrador de contraseñas. No debes usarlo para cuentas técnicas.

Otros han abordado el hecho de que estás violando el Principio de Kerckhoffs. Me gustaría sugerir una manera de volver a redactar su propuesta que no lo haga.

Hacer que tu función sea parte de la clave

Si tratamos su "función que solo usted conoce" como parte de la "clave", entonces no es una violación del Principio de Kerckhoff. Es decir, tomamos su "llave" para tener dos partes. La frase de contraseña de entrada, p , y la función secreta, f .

¿Su función es deducible de su salida?

¿Vas a memorizar tanto p como f ? Probablemente. ¿Utilizará un único p y f para cada servicio que utilice? Probablemente no.

Es decir, espero que se sienta tentado a cambiar solo p para diferentes casos mientras reutiliza el mismo f . Esto puede hacerse seguro, pero lo que describe con su ejemplo no lo es. Esto se debe a que si un atacante obtiene un par de sus contraseñas derivadas, diga f ("correcthorse") yf ("batterystaple"), podrán averiguar qué es f .

Corrige haciendo de tu función una función pseudoaleatoria

Entonces, si quieres hacer esto, necesitarás un f que no es deducible del atacante que tiene n de tu contraseña derivada, f ( p1 ) ... f ( pn ). Hay funciones criptográficas que harán esto por ti. HMAC es lo que viene a la mente inmediatamente.

Deje que f (p) = HMAC ("algún secreto constante que solo conozca", p)

De esta manera, un atacante que envejeció de f (p) tendría dificultades para descubrir el secreto constante, especialmente si no supiera p .

Problemas de codificación

Tenga en cuenta que la salida de f (p) no será texto ASCII. Así que necesitarías transformarlo en algo utilizable como contraseña donde lo necesites. Es difícil hacer esto en general. Por ejemplo, si usaste la codificación base64, deberías asegurarte de que el lugar donde estás utilizando la contraseña generada acepte todos los símbolos que pueden aparecer en base64. Del mismo modo, si utiliza una representación hexadecimal, es posible que no obtenga todos los "símbolos" que algunos servicios pueden requerir para una contraseña.

Son estos problemas de codificación por los que este sistema no funciona como un esquema general. Puede usarse y luego manipularse manualmente, caso por caso, pero eso significa que solo puede usarlo en un par de casos.