¿La forma correcta de generar sales de contraseña en PHP 5.3 en Linux dadas mis restricciones?

3

Al examinar el almacenamiento de nuestra base de datos de contraseñas con hash con sales, observo una alta tasa de colisiones de sal, es decir, hay demasiados casos en los que dos filas de tablas tienen la misma sal almacenada.

Una solución es comenzar a generar inmediatamente "mejores" sales a medida que almacenamos nuevas contraseñas con sal y hash.

  • Ejecutamos PHP 5.3 en producción. Eso significa que probablemente no podamos usar bibliotecas que dicen que requieren PHP 5.4+. (Digo "probablemente" porque nuestra integración de CentOS incluye algunas características de PHP 5.4. Estamos investigando la compatibilidad de varias bibliotecas).

  • No tenemos libsodium disponible en este momento.

  • Tenemos las extensiones de PHP mcrypt y openssl instaladas y habilitadas.

  • He leído todas las publicaciones del blog de Scott en Paragonie. El más relevante es Cómo generar de forma segura cadenas aleatorias y enteros en PHP .

Creo que mi mejor opción para crear un salt de contraseña en estas circunstancias es usar mcrypt para obtener bytes de / dev / urandom:

$salt = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM)

suponiendo que 16 bytes son apropiados para la sal. ¡La documentación de PHP ni siquiera dice si ese primer parámetro está en bytes! Pero parece ser así.

Tenemos unas decenas de millones de usuarios, por lo que permitir 100 millones de sales debería ser razonable.

Dadas mis limitaciones, ¿puede alguien sugerir un mejor enfoque que tomar 16 bytes aleatorios de / dev / urandom a través de la extensión mcrypt?

Para estar seguros, también estamos trabajando en otras actualizaciones para mejorar la disponibilidad de la biblioteca, un hash más fuerte, etc. Eso está fuera del alcance de esta pregunta.

    
pregunta Edward Barnard 18.09.2015 - 00:49
fuente

1 respuesta

2

Entonces, ¿qué quieres de tus sales?

  1. Deben ser algo impredecibles para evitar ataques previos al cálculo.
  2. Deben ser globalmente únicos.
  3. Deben ser lo más pequeños posible, ya que debe escalarse mucho.

La única suposición que debes hacer es que /dev/urandom es seguro y al menos proporciona números estadísticamente aleatorios (que debería). Esta es una suposición razonable, ya que de otro modo casi todo el sistema (relacionado con criptografía) en su sistema se rompería, ya que la mayoría de ellos usan /dev/urandom . Además, se debe asumir que mcrypt básicamente solo reenvía el resultado de /dev/urandom .

Para satisfacer la propiedad n. ° 1, debería tener al menos 128 bits (= 16 bytes) de sales, pero esto le dejaría con una buena probabilidad de colisión después de haber observado 2^(128/2)=2^64 de sales, lo que puede ser demasiado pronto. para que usted esté realmente seguro de que son únicos. Por lo tanto, propongo usar sales de 32 bytes (= 256 bits) que tienen una resistencia a la colisión de 128 bits, lo que hace que sea muy poco probable que se reutilice alguna vez y que la sal sea razonablemente pequeña (usted podría también use sales de 512 bits ...).

En lo que respecta al hash de contraseñas, es posible que desee consultar la competencia relacionada .

    
respondido por el SEJPM 18.09.2015 - 21:05
fuente

Lea otras preguntas en las etiquetas