Weak Cryptographic Hash: User-Controlled Salt

A las funciones que generan valores de hash, a las que se pasa sal, no se les debe llamar con un argumento de sal contaminado.

Los problemas de Hash criptográfico débil: sal controlada por el usuario se producen cuando:

1. Los datos entran en un programa a través de un origen que no es de confianza.

2. Los datos controlados por el usuario se incluyen en sal o se utilizan completamente como sal de una función de hash criptográfico.

Al igual que muchas vulnerabilidades de seguridad de software, Hash criptográfico débil: sal controlada por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como sal de un hash criptográfico, total o parcialmente.

El problema de tener sal controlada por el usuario es que puede posibilitar diversos ataques:

1. El atacante puede utilizar esta vulnerabilidad para especificar una sal vacía en los datos con hash. A continuación, sería muy sencillo usar su propio hash rápidamente en los datos utilizando distintos algoritmos de hash para filtrar información sobre la implementación de hash empleada en su aplicación. Esto podría facilitar el "descifrado" de otros valores de datos al limitar la variante específica de hash utilizada.
2. Si el atacante puede manipular las sal de otros usuarios, o engañar a otros usuarios para que utilicen una sal vacía, esto podría permitirle calcular "tablas arco iris" para la aplicación y determinar más fácilmente los valores con hash.

Ejemplo 1: el código siguiente utiliza sal controlada por el usuario para el hash de contraseña:

    ...
    salt = getenv("SALT");
    password = crypt(getpass("Password:"), salt);
    ...

El Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular la sal utilizada para aplicar hash a la contraseña modificando la variable de entorno SALT. Además, este código utiliza la función crypt(), que no debería emplearse para el hash criptográfico de las contraseñas. Una vez que se haya distribuido el programa, puede resultar muy difícil deshacer un problema relacionado con sal controlada por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado la sal de un hash de contraseña.

No acepte entradas del usuario para sal en métodos que generen hashes criptográficos.

Los problemas de Hash criptográfico débil: sal controlada por el usuario se producen cuando ocurre lo siguiente:

1. Los datos entran en un programa a través de un origen que no es de confianza.

2. Los datos controlados por el usuario se incluyen en sal o se utilizan completamente como sal de una función de hash criptográfico.


Al igual que muchas vulnerabilidades de seguridad de software, Hash criptográfico débil: sal controlada por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un atacante pasa datos malintencionados a una aplicación, que a continuación se utilizan como sal, total o parcial, de una función de hash criptográfico.

Sal definida por el usuario puede habilitar varios tipos de ataque:

1. Los atacantes pueden utilizar esta vulnerabilidad para especificar una sal vacía en los datos con hash. Luego, pueden usar su propio hash rápidamente en los datos utilizando muchos algoritmos distintos de hash para filtrar la implementación de hash de su aplicación. Esto podría facilitar el “descifrado” de otros valores de datos limitando la variante específica de hash utilizada.
2. Si el atacante puede manipular las sal de otros usuarios, o engañar a otros usuarios para que utilicen una sal vacía, esto les permite calcular “tablas arco iris” para la aplicación y determinar fácilmente los valores con hash.

Ejemplo 1: El código siguiente utiliza sal controlada por el usuario para hash de contraseña:

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  salt := r.FormValue("salt")
  password := r.FormValue("password")
  ...
  sha256.Sum256([]byte(salt + password))
}

El código del Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta funcionalidad puede manipular sal utilizada para aplicar hash a la contraseña modificando la variable de entorno salt. Además, este código utiliza la función hash criptográfico Sum256, que no debería emplearse para hashes criptográficos de contraseñas. Una vez distribuido el programa, resulta muy difícil deshacer un problema relacionado con sal controlada por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado determinó sal de un hash de contraseña.

A los métodos que generan valores de hash criptográficos, a los que se pasa sal, no se les debe llamar con un argumento de sal contaminado.

Los problemas de Hash criptográfico débil: sal controlada por el usuario se producen cuando:

1. Los datos entran en un programa a través de un origen que no es de confianza.

2. Los datos controlados por el usuario se incluyen en sal, o se utilizan completamente como sal en una función de hash criptográfico.


Al igual que muchas vulnerabilidades de seguridad de software, Hash criptográfico débil: sal controlada por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos dañinos a una aplicación, que a continuación se utilizan como sal de una función de hash criptográfico, total o parcialmente.

El problema de tener sal definida por el usuario es que puede posibilitar diversos ataques:

1. El atacante puede utilizar esta vulnerabilidad para especificar una sal vacía en los datos con hash. A continuación, sería muy sencillo usar su propio hash rápidamente en los datos utilizando distintos algoritmos de hash para filtrar información sobre la implementación de hash empleada en su aplicación. Esto podría facilitar el "descifrado" de otros valores de datos al limitar la variante específica de hash utilizada.
2. Si el atacante puede manipular las sal de otros usuarios, o engañar a otros usuarios para que utilicen una sal vacía, esto podría permitirle calcular "tablas arco iris" para la aplicación y determinar más fácilmente los valores con hash.

Ejemplo 1: el código siguiente utiliza sal controlada por el usuario para el hash de contraseña:

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']
  salt = os.environ['SALT']

  hash = hashlib.md5("%s:%s" % (salt, password,)).hexdigest()
  store(username, hash)
...

El código del Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular la sal utilizada para aplicar hash a la contraseña modificando la variable SALT. Además, este código utiliza la función hash criptográfico md5(), que no debería emplearse para hashes criptográficos de contraseñas. Una vez que se haya distribuido el programa, puede resultar muy difícil deshacer un problema relacionado con sal controlada por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado la sal de un hash de contraseña.

A los métodos que generan valores de hash criptográficos, a los que se pasa sal, no se les debe llamar con un argumento de sal contaminado.

Los problemas de Hash criptográfico débil: sal controlada por el usuario se producen cuando:

1. Los datos entran en un programa a través de un origen que no es de confianza.

2. Los datos controlados por el usuario se incluyen en sal, o se utilizan completamente como sal de una función de hash criptográfico.

Al igual que muchas vulnerabilidades de seguridad de software, Hash criptográfico débil: sal controlada por el usuario es un medio para lograr un fin, no un fin en sí mismo. En su raíz, la vulnerabilidad es sencilla: un usuario malintencionado pasa datos malintencionados a una aplicación, que a continuación se utiliza como sal en un hash criptográfico.

El problema de tener sal definida por el usuario es que puede posibilitar diversos ataques:

1. El atacante puede utilizar esta vulnerabilidad para especificar una sal vacía en los datos con hash. A continuación, sería muy sencillo usar su propio hash rápidamente en los datos utilizando distintos algoritmos de hash para filtrar información sobre la implementación de hash empleada en su aplicación. Esto podría facilitar el "descifrado" de otros valores de datos al limitar la variante específica de hash utilizada.
2. Si el atacante puede manipular las sal de otros usuarios, o engañar a otros usuarios para que utilicen una sal vacía, esto podría permitirle calcular "tablas arco iris" para la aplicación y determinar más fácilmente los valores con hash.

Ejemplo 1: el código siguiente utiliza sal controlada por el usuario para el hash de contraseña:

    ...
    salt = req.params['salt']
    hash = @userPassword.crypt(salt)
    ...

El código del Example 1 se ejecutará correctamente, pero cualquier persona con acceso a esta función podrá manipular la sal utilizada para aplicar hash a la contraseña modificando el parámetro salt. Además, este código utiliza la función String#crypt(), que no debería emplearse para el hash criptográfico de las contraseñas. Una vez que se haya distribuido el programa, puede resultar muy difícil deshacer un problema relacionado con sal controlada por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado ha determinado la sal de un hash de contraseña.

No acepte entradas del usuario para sal en métodos que generen hashes criptográficos.

Los problemas de Hash criptográfico débil: sal controlada por el usuario se producen cuando ocurre lo siguiente:

1. Los datos entran en un programa a través de un origen que no es de confianza.

2. Los datos controlados por el usuario se incluyen en sal o se utilizan completamente como sal de una función de hash criptográfico.


Al igual que muchas vulnerabilidades de seguridad de software, Hash criptográfico débil: sal controlada por el usuario es un medio para lograr un fin, no un fin en sí mismo. En esta vulnerabilidad, un atacante puede pasar datos malintencionados a una aplicación, que a continuación se utilizan como sal, total o parcial, de una función de hash criptográfico.

Sal definida por el usuario puede habilitar varios tipos de ataque:

1. Los atacantes pueden utilizar esta vulnerabilidad para especificar una sal vacía en los datos con hash. Luego, los atacantes pueden usar su propio hash rápidamente en los datos utilizando muchos algoritmos distintos de hash para filtrar la implementación de hash de su aplicación. Esto podría facilitar el "descifrado" de otros valores de datos limitando la variante específica de hash utilizada.
2. Si un atacante puede manipular las sales de otros usuarios, o engañar a otros usuarios para que utilicen un una sal vacía, esto le permite calcular "tablas arcoíris" para la aplicación y determinar fácilmente los valores con hash.

Ejemplo 1: El siguiente código utiliza una sal controlada por el usuario para derivar una clave de cifrado:

let saltData = userInput.data(using: .utf8)

sharedSecret.hkdfDerivedSymmetricKey(
    using: SHA256.self,
    salt: saltData,
    sharedInfo: info,
    outputByteCount: 1000
)

El código del Ejemplo 1 se ejecutará correctamente, pero cualquier persona con acceso a esta funcionalidad puede manipular sal utilizada para derivar la clave de cifrado modificando el valor userInput. Una vez distribuido el programa, resulta muy difícil deshacer un problema relacionado con sal controlada por el usuario, dado que probablemente no habría forma de saber si un usuario malintencionado determinó sal de un hash de contraseña.