¿Qué tan segura es la obtención de claves basada en contraseña en el caso de una contraseña larga?

  

El problema en la derivación de clave basada en contraseña (PBKD) es que el atacante puede adivinar la contraseña si esa contraseña es del usuario. Pero en mi caso estoy usando un número largo basado en el sistema (no del usuario) como frase de contraseña. ¿Es esta una manera correcta?

Una contraseña es "una clave secreta que cabe en el cerebro del usuario". El atributo principal de una clave secreta es su secreto, que es una medida de cuánto desconocen los atacantes. En términos generales, los atacantes son (supuestamente) súper inteligentes, por lo que lo único que no saben es la aleatoriedad pura.

El principal problema con contraseñas es que los cerebros humanos no son buenos para almacenar aleatoriedad (también son muy pobres para producir aleatoriedad). Esto es lo que hace que las contraseñas sean débiles: los atacantes pueden intentar encontrar la contraseña a través de "adivinar", lo que básicamente significa probar todas las combinaciones de aleatoriedad compatible con humanos.

PBKDF2, como otras funciones de hashing de contraseña , está pensado para hacer que la debilidad de las contraseñas sea más tolerable, haciendo que cada suposición sea más costosa (tanto para el atacante como para el usuario normal).

Si, en su aplicación, la contraseña no es realmente ingresada por un usuario, sino por una máquina, entonces puede usar una "contraseña" con mucha aleatoriedad (las máquinas son mucho mejores que los humanos para recordar largas secuencias de números aleatorios ), en cuyo punto el hashing de la contraseña puede volverse bastante inútil.

  

¿La modificación de la clave de cifrado en mi código (por ejemplo, desplazar a la izquierda o desplazar a la derecha la clave) ayuda en la seguridad?

Ayuda tanto como bailar con una tetera en tu cabeza mientras cantas la gloria de Huitzilopochtli te ayudará a adivinar los próximos números de lotería ganadores.

(Si Huitzilopochtli realmente se divierte con tu ritual, puede otorgarte algunos beneficios, pero en realidad no es conocido por su sentido del humor).

  

¿Qué hay de almacenar la sal en el código (codificación de hardware)?

El salt tiene sentido junto con el hashing de contraseñas: es uno de los métodos por los cuales las contraseñas (que son inherentemente débiles, ver más arriba) pueden ser toleradas. Si sus "contraseñas" no son realmente contraseñas, entonces el hashing y el salt de las contraseñas son irrelevantes.

A la inversa, cuando una sal es relevante , entonces su punto principal y único nunca se reutiliza, la codificación del sal en el código hace exactamente lo contrario.

Por lo tanto, se puede decir que codificar un valor de sal es una mala idea o una muy mala idea, según el contexto.

Recuerde que la seguridad física es tan importante como la lógica, si su hardware es relativamente seguro (o pesado) y le preocupa que el disco duro sea robado y desencriptado, use información del hardware como números de serie (al menos 2 de ellos, lo cual creo ya lo está haciendo) de esta manera, la unidad no se puede descifrar sin estar dentro del hardware correcto ..

con respecto a las capas y sales adicionales, solo asegúrate de que ofuscas los scripts de cifrado y descifrado, y una sal codificada debería estar bien.

Obviamente, no estoy al 100% en tu escenario, pero dependiendo de cómo funcione el cifrado, el descifrado, etc. en tu caso, depende de lo que sería una sal viable, si puedes hacer que la sal sea dinámica para cada archivo específicamente de alguna manera, esto significaría que incluso si robaran el hardware y adivinaran 1 archivo de sal, no podrían descifrar el resto de los archivos.

Es posible que pueda darte algunas sugerencias si supiera los detalles del escenario, pero a veces no deberías compartir información (ingeniería social)

Espero que esto genere algunas ideas.

Una KDF para fortalecer la contraseña solo es necesaria si la contraseña en sí misma puede ser débil. El primer ejemplo es cuando un humano lo ha generado.

Un KDF repetirá el hash de la contraseña varias veces. Esto significa que un atacante que obtenga acceso a los hashes de la contraseña tendrá que iterar cada contraseña, adivinar ese número de veces, lo que ralentizará su ataque. Esto tiene el mismo efecto que una contraseña segura sin KDF. Esto se debe a que el espacio de teclas adicional que tendría una contraseña con mayor entropía puede tener iteraciones de hash adicionales sustituidas para dar cuenta del tiempo necesario para romper.

Por lo tanto, una contraseña generada por computadora no necesita un KDF para estiramiento de la clave porque simplemente puede generar una clave con suficiente la fuerza por sí misma. Ir a 128 bits de entropía si es posible, generado por un generador de números aleatorios criptográficamente seguro (CSPRNG).

En cuanto a la sal, no necesitas una. 128 bits serían suficientes para asegurar la contraseña contra ataques hash de forma intrínseca. Las tablas del arco iris para cubrir todo el espacio de claves de 128 bits serían demasiado grandes.

Cuando dices "número basado en un sistema largo", ¿qué quieres decir con exactamente? Si la única entrada a su función de generación de clave es una constante estática almacenada en la máquina, entonces su encriptación no hará nada contra un atacante que obtenga acceso a ella. Sin embargo, evitará que se levanten datos y se descifren en una máquina diferente.

La generación de una clave basada en una contraseña suministrada por el usuario garantiza que el atacante necesita información externa para extraer datos del dispositivo. Por supuesto, esto significa que el usuario tiene que elegir una contraseña buena , pero yo diría que es más inteligente que almacenar la contraseña en la propia máquina. Si la contraseña está bien elegida (por ejemplo, una frase de contraseña larga), el atacante no tendrá ninguna posibilidad de adivinarla en mil años.

La elección de la fuente clave dependerá de su caso de uso. Incluso puede optar por una combinación de los dos (por ejemplo, Windows ofrece un servicio de cifrado que se basa en un chip de seguridad en el hardware, así como en la contraseña del usuario).

Las sales se utilizan para hacer que los secretos de hash sean más difíciles de atacar con tablas de hash precalculadas. La aplicación más común es en el almacenamiento de contraseñas. Si un atacante puede preparar una gran lista de contraseñas comunes y sus hashes, entonces puede buscar fácilmente los hashes de contraseña para encontrar equivalentes de texto claro. La adición de un salt a la contraseña y el hashing del resultado hace que esto sea mucho más difícil.

No veo cómo se aplican las sales aquí, sin embargo. Estás cifrando una gran cantidad de datos, no hashing . No hay manera de que un atacante construya una tabla con cada archivo posible y cada versión cifrada posible de él.

Además, las sales no son secretos, ya que deben estar disponibles para acceder a los secretos de acceso . Es posible que pueda ofuscar las sales (utilizando nombres de archivo, por ejemplo), pero recordemos la regla de oro de la seguridad:

La seguridad a través de la oscuridad no es seguridad . Supongamos que el atacante sabe todo excepto la clave.

Esto se aplica también a algunas de las otras cosas que mencionaste, ya que no es bueno jugar con funciones criptográficas al azar.

Construye un sistema robusto, no uno de mala calidad.