Combinando SCRYPT + un corto crc

2

Estoy considerando usar SCRYPT para el almacenamiento de contraseñas. (También estoy abierto a PBKDF2, o bcrypt por sí mismo).

El problema es que no quiero que esto se convierta en un punto potencial para un ataque DDOS, dada la sobrecarga del cálculo real.

Estaba pensando que algo MUY débil con muchas colisiones como una prueba de validez primero (como CRC8) contra SALT + PASSPHRASE podría ser una buena idea. (luego usar una espera antes de devolver la falla para protegerse contra el ataque de tiempo).

Esto supone una longitud mínima de 8, con un requisito de 3 de 4 para:

  • Alpha en mayúsculas
  • Alfa minúscula
  • número
  • no alfanumérico

¿Cuánto reduciría esto realmente la efectividad de SCRYPT en un ataque de fuerza bruta si se comprometieran los datos?

    
pregunta Tracker1 02.02.2015 - 21:42
fuente

2 respuestas

9

No debes meterte con el algoritmo de esta manera. No puedo pensar cuál es el impacto de este método, pero grita inseguridad. Como mínimo, permitiría a un atacante moverse aproximadamente 256 veces más rápido ya que CRC es una función matemática relativamente simple y, por supuesto, más rápida en la parte de la base de datos. Estás a unos cuantos ejercicios de codificación de la pizarra lejos de que alguien descargue todas tus contraseñas si obtiene acceso a la base de datos.

En su lugar, emita un token con una función barata con un prefijo de dirección de cliente o dirección de cliente y solicite ese token con el nombre de usuario y la contraseña. Eso le permitirá limitar la frecuencia con la que realiza el costoso proceso de verificación de contraseña.

    
respondido por el Jeff Ferland 02.02.2015 - 22:19
fuente
3

He subestimado la respuesta de Jeff. Arquitectónicamente, es mejor crear algunas funciones de mantenimiento de puertas independientes que estén vinculadas a la dirección del cliente y que se ejecuten cuando se llama a la pantalla de entrada de inicio de sesión del lado del cliente. Mantenga esto separado de sus rutinas de autenticación. Puede limitar las tasas de prueba o la cantidad máxima de intentos antes de marcar la cuenta de alguna manera, y eso no requiere que muck con el núcleo de la autenticación.

Las implementaciones criptográficas son una función del enlace más débil, y CRC ni siquiera es realmente una verdadera criptografía de hashing primitiva. Es bastante malo en este sentido. El almacenamiento de las sumas de comprobación CRC crea problemas porque permite que un atacante que obtiene la base de datos utilice un proceso en paralelo fácil para reducir el trabajo para atacar cada contraseña en la base de datos. Poner el CRC de la frase salt + pass justo allí con los hashes finales de scrypt funciona para un atacante como una especie de tamiz. El atacante puede ejecutar una rutina rápida que comience un esfuerzo de fuerza bruta sin ningún otro objeto sino para encontrar cadenas que sumen una suma de comprobación al CRC almacenado. Solo las cadenas que pasan este paso de tamiz deben ejecutar el guante a través del hash de scrypt de computación y uso intensivo de memoria. Es aún más rápido si el atacante está ejecutando diccionarios.

    
respondido por el boggart 03.02.2015 - 00:00
fuente

Lea otras preguntas en las etiquetas