Howto encriptar passwords en la base de datos

El MD5 aplica una función hash unidireccional,y al ser hash unidireccional el MD5 destruye el mensaje, solo tiene una dirección, no hay vuelta atras.

hola bienvenido a sistema

No soy el mas versado en este tema, soy solo un usuario basico de PHP, pero creo que crear un hash sha1 a partir del hash md5 es trabajo de sobra.

Como se dijo mas arriba, el md5 es un hash unidireccional por lo que la unica forma de romperlo es mediante fuerza bruta. Eso si, hay que tener cuidado. Aun cuando el hash destruye el mensaje y crea un hash igualmente fuerte con una contraseña de un caracter que con un mensaje de 256 caracteres, no hay que confiarse y poner una contraseña obvia porque seguira siendo vulnerable a un ataque de diccionario. Si ese fuera el caso, no hay codificacion que sirva: no importa si la almacenas como texto plano, como md5, como sha1 o como sha1 de md5 (o md5 de sha1), un ataque de diccionario la rompe facilmente.

Ahora, si alguien fuera a obtener la contraseña encriptada mediante un exploit o algun otro mecanismo que permita “robarse” la informacion de la base de datos, el hasheo md5 provee suficiente proteccion contra un ataque de fuerza bruta. Ante la poco probable eventualidad que alguien rompa el hash para una contraseña determinada, haberla re-hasheado provee un delta extra de proteccion al hacer que el atacante tenga que invertir tiempo extra en romper el primer hash y luego el segundo. En un buen dia, eso podria significar mucho mas tiempo de procesamiento que el que el atacante promedio esta dispuesto a invertir.
Personalmente he dejado de usar md5 como metodo de hashing debido a que hay sitios en internet que se dedican a generar listas de hashes (con texto plano aleatorio como argumento de entrada) con la esperanza de que ese listado contenga algun hash que puedan llegar a querer revertir. Podria pasar lo mismo con sha1 (aunque entiendo que sha1 genera un hash mas fuerte y por ende requiere mas tiempo atinarle por fuerza bruta), por lo que uso sha1 en lugar de md5

Si te preocupa en demasia la seguridad de tus claves, puedes hacer un doble md5, doble sha1 o, como propones, mezclar ambos. Vas a poder dormir mejor en las noches, aunque la probabilidad que vayas a necesitarlo es minima. (es mucho mejor que en tus sistemas fuerces a los usuarios a tener claves fuertes para reducir la probabilidad de exito en un ataque de diccionario o por fuerza bruta). Como digo, quizas es trabajar de mas, quizas no. Pero si ya lo tienes hecho y el footprint de memoria en tu servidor es bajo, no pierdes nada con dejarlo asi.

Para alguien que preguntaba un par de posts mas arriba como recuperar las claves, lamentablemente con md5 o sha1 no se puede. Si necesitas implementar un sistema que tenga la posibilidad de recuperar contraseñas olvidadas mediante una pregunta secreta o algo por el estilo, te sugiero que ademas de almacenarlas hasheadas para el sistema de autentificacion, almacenes una copia aparte (definitivamente en otra tabla y ojala en otra base de datos, con otro usuario SQL si fuera posible) pero en lugar de hashearla la cifres con la funcion crypt() de php. La forma en que lo hago yo es la siguiente:

*establezco dos bases de datos, una (llamemosla “web”) que es accesible por un usuario sql (“web_user”), donde almaceno las tablas que utiliiza el sitio web incluyendo la que contiene los datos de mis usuarios (incluyendo un campo “username” y un campo “password” hasheado sha1); y otra (llamemosla “interna”) con un usuario (“interna_user”) que en una tabla almacena un listado con los mismos usernames asociados a la contraseña cifrada con crypt().

*La segunda base de datos solo es accesible en caso que alguien busque recuperar su contraseña, en caso contrario no se toca nunca.

*La bondad que tiene crypt es que es reversible. Entonces, si alguien necesita recuperar su contraseña, revierte el crypt y envia por correo electronico la contraseña.

¿por que usar dos bases de datos y dos usuarios distintos? Quizas es paranoia, pero ante la eventualidad que una inyeccion sql o un ataque XSS del que no pueda defenderme bien permita a un atacante rescatar la base de datos web (la unica accesible desde el sitio), el atacante solo va a recuperar los datos hasheados unidireccionalmente, pero yo sigo teniendo la posibilidad de recuperar la contraseña de un usuario olvidadizo. De esta forma no sacrifico la seguridad que me da sha1 ni tampoco la reversibilidad.

saludos!

Es indiscutible, que todo lo que tenga que ver con algoritmos ya conocidos, y peor aun si se cuenta con el codigo fuente a la mano de dichos algoritmos, la seguridad esta realmente comprometida, lo mejor que se puede hacer en estos casos, y que es dificil o imposible para los queridos y amados hakers, crakers, lamers y todo lo relacionado, romper la seguridad de mi siguiente propuesta:

1.- Se puede seguir generando los passwords con los algoritmos que ustedes gusten o se acomodden mejor. Solo que hay que insertar entre los hashes generados bytes aleatorios en ciertas posiciones, no importa en cuales posiciones, siempre y cuando ustedes recuerden o sepan donde se encuentran esas inserciones y las puedan retirar para sus respectivos procesamientos.

2.- No limitar a cierto numero de posisiones los campos de nuestras bases de datos que contengan nuestros passwords, esto con la finalidad de poder colocar nuestro hash con más bytes (las insersiones de bytes aleatorios en posiciones especificas de nuestro hash q nosotros solo sabemos) no importa que la longitud de nuestro hash cresca al doble o triple, la idea es confundir, de tal forma que los amantes de la descodificacion puedan tomar un hash limpio para porcesarlo y descifrarlo.

3.- Cuando hagamos nuestra sopa, tanto con los bytes verdaderos de nuestro hash en cuestion como con los falsos bytes al azar, tendremos un hash inreconocible e indecifrable, muy dificil de separar y cotejar por quienes no conozcan el proceso, en caso de que se roben la base de datos.

4.- Podemos hacer las cosas aun más dificiles para los “hakers”, si nosotros creamos nuestros propios algoritmos que recodifiquen la cadena (sopa de bytes), ya sea recorriendo los bytes a la izquierda x posiiones o la derecha o sumarlos o restalos o lo que se les ocurra, obviamente que tenga reversa para poder recuperar la caddena sopa de bytes y retirar los bytes que insertamos al azar en las x posiciones para finalmente obtener nuestro hash totalmente limpio.

5.- Tratandose de seguridad no importa cuanto trabajo y tiempo se tenga que hacer para lograrla (ya que los amados hakers lo invierten sin importar cuanto trabajo se tenga que hacer para loc¿grar desvelar uno o dos hash’s), al fin y al cabo quien hace el trabajo es la computadora y aveces invertimos mas recursos en cosas bobas como hacer codigos que según la hora del dia les diga a los usuarios “buenos dias o buenas trades o buenas noches”… o que se yo!

6.- Tambien hay que preocuparse de gran manera de la forma en como el usuario (cliente) envia su clave a nuestro servidor ya que si permitimos que la envien tal cual; alguien la puede tomar durante el trayecto hacia el server y pues de nada sirve la tanta seguridad que haya en nuestro servidor. Por ahi anda un codigo en java que cifra y manda la clave ya cifrada desde la computadora del usuario (un hash md5) y obviamente hay que hacer nuestra amada e irreconocible y confundible sopa de bytes para enviarlos desde la pc del usuario en cuestion a nuestro servidor. De esta manera los “mirones” o peor aun los osos hormigueros “snifers” no sabran que hacer con nuestra sopita, jijiji.

7.- Y finalmente, hay que recomendar o forzar, mejor aún, a que nuestros usuarios utilicen tanto letras minisculas como mayusculas, numeros y algunos simbolos especiales (obviamente en sopa “mezclados” jejejeje) para sus claves. Esto permitira generar hashes más robustos y dificiles de “romper” por fuerza bruta.

Saludos desde México.
Daniel Solís.
DESISCOM… Milenio!

Existen bases de datos, que apartir de un HASH se puede obtener el string original sin cifrar, sobre todo si la password es una frase comun como “qwerty” o “123456″ googleando se encuentra mucho.

Independientemente de que se encripte o no la contraseña, el primer paso según mi opinión es escoger una que cumpla unos criterios básicos de seguridad. La podemos crear nosotros mismos aporreando el teclado, pero teniendo en cuenta que cuantos mayor número y variedad de carácteres, más seguridad tendremos. También hay páginas que te las generan automáticamente según los criterios que quieras (yo las uso mucho para mis desarrollos): http://www.safepasswd.com, o su versión en español http://www.clavesegura.org.