¿Debes hacer público el algoritmo?

Tratar de ocultar los detalles de la implementación (como el algoritmo de hash que usa) para preservar la seguridad es la definición de seguridad en la oscuridad . Existe un amplio consenso de que la oscuridad no debe ser su única línea de defensa.

Si necesitas mantener tu algoritmo hash en secreto, lo estás haciendo mal y debes elegir un mejor algoritmo hash. Cuando usas un buen algoritmo, no hay razón para no decírselo al mundo, ya que de todos modos no podrán romper tus hashes.

También tenga en cuenta que en su caso la sal lo regalará. Si alguien se apodera de su base de datos, podrá leer qué algoritmo se utilizó a partir de eso. Por lo tanto, la oscuridad no hace que la fuerza bruta sea más difícil aquí. La publicidad de un esquema débil, sin embargo, podría alentar a los atacantes. Una fuerte podría tener el efecto contrario. El punto que Mike Goodwin señala en su respuesta también debe tenerse en cuenta.

¿Es segura crypt ()?

La pregunta relevante es, por lo tanto, si crypt() es lo suficientemente seguro. Echemos un vistazo al manual de PHP :

  

password_hash() usa un hash fuerte, genera una sal fuerte y aplica rondas adecuadas automáticamente. password_hash() es un envoltorio simple crypt() y es compatible con hashes de contraseña existentes. Se recomienda el uso de password_hash() .

     

Algunos sistemas operativos admiten más de un tipo de hash. De hecho, a veces el algoritmo basado en DES estándar es reemplazado por un algoritmo basado en MD5.

  

El crypt() basado en DES estándar devuelve la sal como los dos primeros caracteres de la salida. También solo utiliza los primeros ocho caracteres de str , por lo que las cadenas más largas que comienzan con los mismos ocho caracteres generarán el mismo resultado (cuando se usa la misma sal).

La función utiliza diferentes algoritmos según cómo se formatee la sal. Algunos de los algoritmos son muy débiles, y los fuertes pueden no estar disponibles en todos los sistemas. Entonces, dependiendo del algoritmo utilizado, hay una serie de problemas aquí:

• Para algunos algoritmos, crypt() solo aplica una ronda de hash. Eso es demasiado rápido y permitirá un ataque de fuerza bruta.
• En algunas circunstancias, crypt() usará MD5, que se sabe que es débil.
• El uso exclusivo de los primeros ocho caracteres anula completamente los beneficios de las contraseñas largas.

Por lo tanto, sugiero que cambie a password_hash() . Te permite usar bcrypt, un algoritmo probado y comprobado. Entonces puedes decirle al mundo con orgullo sobre tu esquema de hash.

@Anders tiene razón en que la seguridad a través de la oscuridad no es seguridad en absoluto.

Habiendo dicho eso, la publicación de los detalles de la implementación proporciona información a los atacantes que podrían usar si se descubren vulnerabilidades en su implementación en el futuro o si el atacante tiene vulnerabilidades de día cero.

Piénselo de esta manera: muchas pruebas de penetración comienzan con una fase de reconocimiento que descubre protocolos, tecnologías y versiones en uso. Esta información se usa para intentar explotaciones conocidas, si las hay.

Si este tipo de información es útil para los examinadores de lápiz, también es útil para los atacantes. ¿Por qué hacer sus vidas más fáciles haciendo parte de su trabajo para ellos? En igualdad de condiciones, es probable que se centren en los sistemas que les facilitan las cosas antes que los que los hacen trabajar más duro.

En general, a menos que haya algún beneficio claro para usted o su empleador al publicar los detalles técnicos, los mantendría en privado. Trabaja sobre una base de necesidad de saber.

Sin embargo, solo para repetir, para evitar votos negativos: estoy completamente de acuerdo en que la seguridad a través de la oscuridad no es seguridad en absoluto ;-p

No solo puede usted, absolutamente debería .

El principio de Kerckhoff dicta que lo único válido para la seguridad de su sistema es la clave secreta , y que cualquier sistema seguro debe diseñarse con la noción de que "el enemigo conoce el sistema" se supone que es verdadero desde el principio.

Por lo tanto, según el principio de Kerckhoff, compartir los detalles del sistema no puede hacer que sea menos seguro, porque debes asumir por adelantado que el enemigo ya conoce el sistema, porque los malos están dispuestos a piratear y cometer espionaje. Para acceder al funcionamiento de la misma. Sin embargo, lo que puede hacer es ayudar a que su sistema más sea seguro al compartirlo con los buenos, expertos que podrían analizarlo y revisarlo. Si hay vulnerabilidades, tanto los buenos como los malos los encontrarán, pero los malos no los compartirán contigo para que puedas solucionarlos.

Por lo tanto, si desea que su sistema sea seguro, no puede permitirse que no comparta cómo funciona.