¿Puede usar RSA2048 para hash de contraseñas?

Su esquema de hashing propuesto no tiene ninguna ventaja real sobre los esquemas existentes y algunos posibles inconvenientes.

Un esquema de hashing de contraseñas debe tener tres propiedades clave :

• debe ser unidireccional: no hay forma de recuperar la contraseña del hash, la única forma de encontrar la contraseña es adivinarla;
• debe tener sal: cada hash incorpora un valor único para que un atacante no pueda reutilizar los mismos cálculos para atacar muchos hashes;
• debe ser costoso (como mínimo, lento): el cálculo de un hash debe requerir recursos significativos, por lo que los ataques masivos requieren una gran inversión en hardware.

Su esquema propuesto es unidireccional, pero el primer paso de hash con MD5 es suficiente para eso. (Por cierto, aunque MD5 no tiene debilidades conocidas para este caso de uso, está lo suficientemente dañado como para no recomendarlo). Sin embargo, podría sustituir SHA-256 y su pregunta seguirá siendo válida, al igual que mi respuesta. Realizar una operación RSA en la parte superior no mejora este aspecto.

Su esquema propuesto está salado, usando una clave diferente para cada hash. Esta bien. Pero hay una manera más fácil de hacer la salada: básicamente tomas hash (contraseña + sal) en lugar de hash (contraseña). (El demonio está en los detalles, pero me limitaré al resumen de alto nivel aquí.) Así que ya sabemos cómo hacerlo.

Su esquema propuesto no es caro. La capacidad de pago debe ser optimizable, para ir al uso máximo de recursos que se puede barajar en el servidor legítimo que verifica la contraseña y mantenerse al día con la evolución tecnológica (por ejemplo, aumentar el número de iteraciones de 10 ⁵ a 10 ⁶ cada 5 años, ya que las computadoras son ~ 10 veces más rápidas). Una forma sencilla de hacer esto es tomar un hash rápido e iterarlo, lo que requiere un largo cálculo secuencial; esto es lo que PBKDF2 hace. Los esquemas más complejos intentan ser óptimos en el hardware de PC y menos buenos en, por ejemplo, GPU o FPGA; vea ¿Algún experto en seguridad recomienda bcrypt para el almacenamiento de contraseñas? . No está claro cómo se puede ajustar su propuesta para que sea costosa: ¿usar claves RSA más grandes?

Un defecto potencial importante en su propuesta es que la operación RSA principal (exponenciación modular) no tiene buenas propiedades de seguridad cuando se usa directamente, porque está sujeta a relaciones algebraicas como x ^e·y^e = ( x · y ) ^e . Esta es la razón por la que el "cifrado RSA" no es una simple exponenciación , pero en cambio agrega algo de relleno a los datos; OAEP es el estándar moderno. No puede usar OAEP tal como es porque no es determinista: ejecutarlo dos veces en la misma entrada produce diferentes textos cifrados. Es probable que una versión no aleatoria de OAEP funcione, o incluso algún esquema más simple dado que se encuentra en un caso muy especial en el que nunca se descifrará ningún texto cifrado, lo que significa que muchos ataques a los esquemas de cifrado no son aplicables. / p>

Tenga en cuenta que no puede ir tan lejos como para no agregar ningún relleno, no sin restricciones adicionales: y = x e mod n debe incluir el módulo n , de lo contrario, x se puede calcular desde y simplemente tomando e La raíz en los reales. Como se especifica en su pregunta, e no está restringido, lo que permite la opción común de e = 3. Dado que x es un número de 128 bits ( 256 bits si usa SHA-256 en lugar de MD5) y n es un número de 2048 bits, x e no se ajustará, por lo que x se puede recuperar de forma trivial desde y . Todavía hay unidireccional del hash, pero se pierde la salazón que solo fue proporcionada por el paso RSA. Hay soluciones fáciles para este problema, por supuesto: requiere un e suficientemente grande, e incluye una sal en los datos de hash. Pero si tiene que confiar en el resto del diseño, ¿por qué pondría RSA en la mezcla? Esto ilustra el riesgo de agregar más cosas a un algoritmo criptográfico: puede hacerlo más débil incluso si pensaba que estaba agregando una característica de seguridad.

Para resumir:

• Su propuesta carece de una propiedad clave de las funciones de hashing de contraseñas: costo.
• Puede ser posible modificar esta propuesta para tener esta propiedad, pero no está claro cómo.
• Usted agrega un vector de ataque potencial (relaciones algebraicas); existen defensas, pero no está claro lo que está ganando.

  

Suponiendo que estoy trabajando en un entorno que actualmente usa MD5 para hash de contraseñas, y quiero cambiar a algo más seguro.

Si esta es una pregunta práctica, entonces merece una respuesta práctica:

No inventes tus propios esquemas de almacenamiento de contraseñas. Hágalo de acuerdo con las mejores prácticas .

No hay ningún beneficio para su esquema con el uso de las opciones estándar (pbkdf / bcrypt / scrypt / argon2). Hay muchos inconvenientes potenciales de seguridad, además de errores generales en la implementación (ya que usted mismo está construyendo esto en lugar de usar una biblioteca de uso común). Implementar esto en un entorno de producción limita con la negligencia profesional.

Sobre el tema de su seguridad: al menos usted sufre de que sea fácil de paralelizar, por lo que un atacante que haya obtenido un volcado de la base de datos puede hacer el viejo "girar un montón de instancias de EC2" para romper tus hashes Este es el punto detrás de bcypt, pero no parece que hayas abordado eso en absoluto.