Foro - Perl en Español

Hola a todos.

Estoy manejando una aplicación en la cual, todo usuario debe registrarse para poder acceder sus datos y la aplicación en general.

Esto lo hago, como es clásico, con una clave de usuario y una contraseña. Ambos campos son char(10) y los guardo en una tabla de usuarios en MySQL.

El problema es que algunos usuarios más avanzados están pudiendo leer las contraseñas de otros usuarios y esto me puede traer problemas en un futuro.

Mi pregunta es si hay algún tipo de campo en especial para guardar contraseñas o si alguien conoce algún truco para guardarlos en una forma más segura.

Espero haber sido claro en mi explicación.

Gracias por adelantado.

Negrazo.

Primero hay que ver de qué forma están accediendo a esas contraseñas.

¿Es accediendo directamente a la base de datos? Entonces el problema es a la hora de filtrar las entradas al programa, para impedir que hagan esas consultas.

¿Están leyendo las contraseñas desde el teclado del ordenador? Pueden haber instalado algún logger o programa espía en el ordenador, que vigila lo que se está escribiendo. Entonces hay que avisar al administrador del sistema para que ponga medidas.

Una buena forma para evitar que puedan leer la contraseña desde la base de datos es... no guardar la contraseña

Me explico: en lugar de guardar la contraseña, guardas el valor de PASSWORD(contraseña) (función MySQL) (el propio MySQL lo hace así). Entonces lo que se guarda es un valor hash que es complicado de sacar. Si alguien se hace con la base de datos, no verá las contraseñas.

Y en la aplicación, a la hora de comprobar la autenticación, te vale con comprobar si el contenido del campo es igual al valor de PASSWORD() de la contraseña que recibimos ( `username' == 'usuario' AND `password` == PASSWORD(contraseña) ).

El problema es... si el usuario pierde la contraseña o se le olvida. Pues no pasa nada: le damos una nueva y actualizamos el campo de la base de datos.

P.D.: los valores hash podrían sacarse por fuerza bruta, por eso cada vez se usan más bits. Una forma de dificultar aún más el procedimiento es la de ofuscar la contraseña ANTES de pasarla por PASSWORD(). Por ejemplo, si la contraseña del usuario es "contra", podemos convertirla en "tMraIcAoPnP" (hemos cambiado el orden de las letras de la contraseña y hemos agregado en posiciones fijas las letras "MIAPP". Y eso lo pasamos a PASSWORD(). Si alguien es capaz de sacar el valor original, le será más complicado saber el orden correcto de las letras y qué letras quitar

Gracias, explorer, por tu respuesta.

A ver si entendí tu propuesta. En lugar del campo char(10) para contraseñas, voy a guardar PASSWORD(contraseña) ¿En dónde se graba dicho campo?

Lo voy a probar y te mantengo informado.

El asunto es que hay algunos reportes, supuestamente confidenciales, donde vienen las contraseñas de todos los usuarios y por allí se está colando la información. Si logro guardar el hash que tu mencionas, pues solo podrán ver caracteres medio raros y ya no habrá problemas.

Gracias nuevamente.
Negrazo.

No, el campo debe seguir siendo de tipo char(). La longitud del campo depende lo que genere PASSWORD().

Luego, a la hora de hacer el INSERT o UPDATE, en lugar de poner la contraseña, se guarda el valor de PASSWORD().

Algo así (no probado):

UPDATE users SET password=PASSWORD(contraseña) WHERE `id`=identificador;

Pues yo recomiendo que... usaras un algoritmo tipo SHA o tipo MD5 para codificar la contraseña, ya que así pues también lo que guarda es un hash o el valor codificado...

Si quieres usar los métodos SHA o MD5 como dice danimera, en MySQL tienes las funciones SHA2() y MD5(), como se comenta en la documentación de MySQL v5.5. Verás ahí que no recomiendan usar PASSWORD(), si no las otras funciones, por ser más seguras.

Gracias, Danimera y explorer.

Ya leí la información de SHA1 y SHA2 y creo que me voy a ir por este camino.

También leí en el Manual de Ref. de MySQL, que el método PASSWORD() lo utiliza el servidor de MySQL para controlar el acceso a sus bases de datos, pero que no lo recomiendan para usarlo en aplicaciones propias.

Saludos desde Guadalajara, México.