Cita:
Empezado por Lepe
Las contraseñas se debería hacer un hash en lugar de cifrar... me explico:
Se hace así porque no hay posibilidad de "desencriptar" y como dato sensible que es, nadie debería saber qué contraseña usa el usuario o el administrador del programa.
|
No. Casi-correcto, pero casi-correcto en seguridad es igual a incorrecto
.
Cuando hay que proteger un dato? Se encripta. Hashear hace parte del proceso en algunas formas, pero un hash no es seguro.
Un hash es:
https://en.wikipedia.org/wiki/Hash_function
Cita:
|
A hash function is any function that can be used to map data of arbitrary size to data of fixed size.
|
Es posible deducir el valor de un hash? Por supuesto. De hecho se hace TODO EL TIEMPO. Le suenan las "hash tables"?.
Asi que luego piensan: "Claro hombre, es que hay que saltear!". Y si se pega/copia sin pensar un ejemplo en la web, puedes terminar con algo errado:
https://en.wikipedia.org/wiki/Salt_(cryptography)
Código:
A new salt is randomly generated for each password. In a typical setting, the salt and the password are concatenated and processed with a cryptographic hash function
Noten que menciona: Por cada password, saltear (muchos ejemplos tienen un salt global), y que se debo usar un hash criptografico (ie: probado para encriptar).
Por lo tanto "hash sin cifrar" es todo lo contrario de lo que se debe usar para guardar un password.
P.D: Para los que no estan al tanto: PBKDF2, bcrypt, scrypt son los que se pueden usar. Utilizar una libreria confiable hecha por expertos. JAMAS hacer "encriptacion" de tipo casera en un entorno serio de produccion. Si leen este mensaje en unos meses, es probable que todas o algunas de las funciones mencionadas dejen de ser seguras! Siempre chequea cuando es cosas de seguridad y no creas ciegamente lo que te dicen, aun cuando lo diga YO!
----
Tener usuario/clave NO ES SEGURIDAD.
Autenticación, autorización, privacidad, integridad, seguridad son conceptos relacionados pero diferenciados.
----
Hacer una app segura es basicamente decir que es una app *correcta*. Por ejemplo, las injecciones SQL existen porque se usan cadenas de texto cuando realmente se quiere decir fragmentos de un lenguaje SQL. Osea, es una falla de asignar el tipo errado al dato.
De igual manera, mantener la privacidad/integridad de la informacion es lo mismo que hacer una app *correcta*. Si es posible acceder a los datos remotamente, y se cree que "mis claves tienen hash salteados!" es lo que lo hace seguro, es asignar el acceso errado al dato.