¿Se está agregando el texto sin formato a la sal igualmente seguro que al agregar la sal con el texto sin formato

Sí, básicamente no hay una diferencia de seguridad en lo que estás haciendo, ya que el resultado tendrá la misma "fuerza" de hash.

Operativamente, aunque los dos métodos devolverán hashes completamente diferentes, lo que podría ser un problema si va a usar esto para autenticarse en un sistema diferente. Agregar la sal es la forma convencional de hacerlo, si la invierte, tendrá problemas de compatibilidad.

Si tiene que lidiar con esta pregunta, es más probable que no cometa un gran error: está lanzando su propio código de hashing de contraseñas . Esto es malo, porque:

1. El hashing de contraseñas es un tema complicado en el que la mayoría de las personas se equivocan;
2. Estaría reinventando la rueda, en lugar de utilizar una función de hash de contraseña dedicada conocida y estudiada como PBKDF2 o bcrypt .

Estas últimas funciones generalmente tienen interfaces que se parecen a esto:

• Argumentos:
  • contraseña de texto sin formato
  • sal
  • factor de costo
• Volver:
  • Una etiqueta de verificación de contraseña

Toman la contraseña y salt como argumentos separados, por lo que no es necesario que adjuntes uno a otro en ningún orden. De hecho, ninguno de ellos agrega la contraseña y el salt de ninguna manera que sugieras.

Es, suponiendo que el hash es de la cadena completa . Mira lo que sucede cuando usas una función hash de contraseña que solo usa los primeros 8 caracteres de su entrada (esta es la función hash de contraseña Unix 'tradicional' (con salado)):

$ mkpasswd -s -S 00 <<<salt.password
002y63GMEzTFg
$ mkpasswd -s -S 00 <<<salt2.password
00OHzu67zQp/Q

Bien: esos dos son diferentes.

$ mkpasswd -s -S 00 <<<password.salt
00xQPHYlVDIw6
$ mkpasswd -s -S 00 <<<password.salt2
00xQPHYlVDIw6

Oops.

Tenga en cuenta que estoy pasando una sal fija a mkpasswd ; esto es para que su sal generada aleatoriamente no interfiera con el principio que estoy demostrando con salt y salt2 antepuestos o agregados a la contraseña.

N.B. No estoy sugiriendo que nadie use realmente la antigua función crypt() para las contraseñas de hash, en parte debido al problema de truncamiento que se muestra aquí, pero también porque la sal es demasiado corta, el hash resultante es demasiado corto y el algoritmo es mucho demasiado rápido para el hardware actual (una función de hash de contraseña debe ser lenta, para dificultar el craqueo, pero no tan lenta como para frustrar a los usuarios legítimos).