2007-07-10

Md5 vs Sha1

He leído con cierto interés un artículo de Joan Garnet sobre la seguridad cliente servidor en entornos Mysql/php. La implementación que defiende Joan plantea la encriptación de los datos con sha1 y esto me ha hecho preguntarme el porqué no con md5 ( práctica muy habitual en el mundo del php). Así que me he puesto a rebuscar en google y veo que md5 es algo más vulnerable. No sólo por que utiliza claves más pequeñas. Sino por que al ser durante muchos años el más implementado en la mayoría de aplicaciones web y de otros ámbitos las contraseñas podrían estar comprometidas.

Me explico: MD5 (acrónimo de Message-Digest Algorithm 5, Algoritmo de Resumen del Mensaje 5) encripta una palabra de forma que no se pueda desencriptar ( en teoría hace años, no en la actualidad... aunque se necesita mucho de todo para romper un md5).

Supongamos que pongo como contraseña la palabra pepe.

md5(pepe)='926e27eecdbc7a18858b3798ba99bddd'

Has aquí todo bien. Lo normal, es que guardemos el contenido encriptado en un campo de nuestra base de datos. Si algún espabilado logra romper nuestra seguridad y mostrar el contenido de la base de datos sólo podría ver la clave encriptada... pero como un hábil cerrajero, hay gente que tiene elaboradas bases de datos con posibles contraseñas encriptadas. Una simple compración entre su base de datos y la nuestra y casi seguro que podría entrar con algun nombre de usuario.

Así que a utilizar sha1, que es de 160 bits y almacenar en la base de datos algo que tras un proceso nos revele la clave encriptada. Nunca se debe almacenar la clave encriptada así tal cual... como el sha1 la trajo al mundo.

7 comentarios:

Anónimo dijo...

Esta buenisimo lo que decís. de hecho yo estoy usando sha(ya noe s sha1 en mysqL) guardando sha("atributo o pass").

Ahora, uns consulta... como podría un hacker hacer entrar el sha si:

1.diseño el sistema(bah yo estoy haciendo de escritorio, no se si la web con su diagrama de cajas es tan distinto) como para que la aplicacion conectada con el dbms(en este caso mysql), pida "select nombre from usuario where pass= sha('"+atributo guardado de la aplicacion+"') quiere decir que en el rs.fisrt del conj de resultados-tupla(resultset) este me volveria a encriptar lo que me robe el "hacker"... entonces... asi las cosas (¿podría entrarme si me esta sobreencriptando el programa lo encriptado?) ¿o debería desencriptar si el programa de por si lo encripta...
muchisimas gracias por el aporte.

2.- Todavia no hice nada web- en la web no se podría realizar el diseño anterior con una minima conexion a bd de la aplicacion para que por php o html o asp o lo q sea se conecte al conj de resultados(resultset) y de ahi haga el "sha("atributo o pass")??? Muchisimas gracias, y por favor, cualquier aporte me ayuda. La verdad que soy muy ignorante en esto. Gonzalo

avanzaweb dijo...

En el punto 1 llevas un gran lio. Lo que yo aconsejo en este post es que debes guardar la contraseña en forma encriptada en tu bd. El hacker que te entre verá la forma encriptada. Lo que le dará más trabajo.

Hacer dos encriptaciones no lo aconsejo ya que se suele perder seguridad.

el sha(clave) lo puedes hacer con php. Es lo que debes hacer.

Espero haberte respondido adecuadamente.

Anónimo dijo...

Usted comentó acerca de que podrían entrar en la base de datos nuestra, luego comparar con la de ellos y podrían entrar como algún usuario registrado... no crees que si ya han entrado a nuestra base de datos no perderán el tiempo comparando nada, ¿para qué?, sería muy ilógico ya que si tienen nuestra base de datos ya no hay nada que hacer.

avanzaweb dijo...

No es ilógico. En nuestra base de datos están las contraseñas guardadas encriptadas. Con esa contraseña no pueden entrar como usuario. Necesitan desencriptarla y la mejor forma de hacerlo es comparando con una bd de contraseñas comunes a las que se les ha pasado la misma encriptación.

Anónimo dijo...

Pero si ya han entrado pueden substituirlas(normalmente) por las claves que quieran(evidentemente encriptandolas para que la aplicación no falle).

Anónimo dijo...

Hacer 2 encriptaciones (cifrado) es bueno, pero haciendo lo siguiente:
1- tomas la palabra y la cifras (usa SHA, no MD5).

2- Echale SALT a la contraseña. Consiste en una cadena adicional al inicio o al final de la contraseña ya cifrada.

3- Vuelve a cifrar la nueva contraseña. así al momento de usar algún metodo para descifrar contraseñas como Rainbow tables o Lookup tables sea muchisimo mas dificil.

NanoZero dijo...

Buena entrada, estaba buscando algo de información respecto a SHA1 y precisamente aquí la encontré


gracias