Un hash criptográfico es una cadena de números y letras producidos por una función hash criptográfica. Una función hash criptográfica es simplemente un algoritmo, o un conjunto de pasos matemáticos, interpretadas por una computadora. Para comenzar a entender esto, podemos echar un vistazo a título intimidante de este artículo.
#3:
#1 Como curiosidad, aunque los hash en teoría son "irrompibles" (es un algoritmo unidireccional, en teoría de un texto o clave puedes sacar el hash, pero el camino contrario no es posible, en realidad a un hash corresponden muchos infinitos posibles textos originales de distintas longitudes) sin embargo hace poco encontré webs que se dedican a coleccionar pares clave-hash (obtenidos con distintos algoritmos) para que dado un hash, si alguien había almacenado esa misma clave poder obtenerla, claro solo es válido para claves "comunes" pero aun así me sorprendió el método, no es difícil alimentar una base de datos con los hash de diccionarios y de bases de datos de contraseñas ya pirateadas de otros lados con lo que acaban teniendo una relativa efectividad
(esto también era comentario friki )
#14:
#3no es difícil alimentar una base de datos con los hash de diccionarios y de bases de datos de contraseñas ya pirateadas de otros lados con lo que acaban teniendo una relativa efectividad
Efectivamente. Precisamente por ese motivo el almacenamiento de contraseñas se debe hacer con un hash "salteado". Lo que se hace es añadir a la contraseña un elemento aleatorio y después hacer el hash. De esta forma la misma contraseña estará almacenada en dos sitios web con un valor distinto, lo que inutiliza las "rainbow tables".
Ese elemento aleatorio se almacena junto al hash en texto plano ya que es necesario conocerlo para poder verificar la contraseña cuando el usuario la introduce, aplicando el mismo "salteado" y comprobando que los valores coinciden. Que el atacante conozca ese valor aleatorio es irrelevante, ya que el efecto de inutilizar esas "rainbow tables" se consigue igualmente.
#33:
#6 Imagina que las funciones hash son como una batidora. Tú metes cosas, le das al botón, y obtienes un resultado, que siempre es del mismo tamaño, el del vaso de la batidora, y donde lo único que importa es el color. ¿Metes una calabaza y un pepino? El resultado es un naranja blanquecino. ¿Metes fresas y berenjenas? Sale morado rojizo.
Ahora, como es lógico, habrá varias combinaciones que den lugar al mismo resultado. Así, si bates coco, el resultado será del mismo color que si bates nata. Has encontrado una colisión: dos elementos base producen el mismo resultado. Dos entradas producen la misma salida.
Ahora imagina que yo hago un catálogo de todo lo que bato. Cada vez que voy a batir algo, hago una foto a lo que voy a meter, y otra al resultado, y monto un catálogo enorme. Vienes tú y me dices "oye, quiero obtener un resultado azul verdoso, ¿qué meto?". Y yo te digo "pues tal y tal", o "no tengo ni idea, nunca he conseguido ese resultado".
Ahora imagina que por una vulnerabilidad web alguien vuelva en pastebin la base de datos de un banco y, entre otras cosas, contiene una tabla con pares email + hash de contraseña. Si quieres impersonar a alguien, no sabes la contraseña, pero sabes el resultado del hash (que es, simplificando mucho, lo que se usa para autenticar en inernet). Vas a mi catálogo y me preguntas por una entrada (la que sea, te vale cualquiera) a la que al aplicarle la función hash que usa el servidor produzca la salida que has leído de la base de datos. Con esa entrada ya puedes impersonar al usuario en cuestión.
¿Cómo se soluciona esto? Añadiendo, cada vez que bates los ingredientes, un ingrediente extra aleatorio. Esto es lo que se denomina 'salt', como bien dicen por ahí arriba. Así, la contrucción de catálogos es impracticable (ocuparía demasiado tiempo y espacio), pues para cada entrada, tienes que calcular la salida con toooodos los ingredientes extra que existen si queieres obtener un catálogo completo.
Todo esto que te he dicho desde el punto de vista de la autenticación y el almacenamiento de contraseñas. Las funciones hash tienen muchos más usos (por ejemplo, comprobar que algo que te has bajado de internet se ha bajado correctamente y no ha habido errores o intervención de la NSA ). Detección de errores, identificación unívoca, firmas digitales, minado de bitcoins, etc.
#38:
Es interesante, pero creo que mezcla varios conceptos de manera errónea. Primero porque habla de "crackear" hash como si se tratara de funciones de cifrado de donde podemos obtener el texto original a partir de los datos contenidos HASH y esto no es posible.
Un hash en simplemente una operación matemática que convierte un texto como "Hola Mundo" a un número cuyo valor puede estar dentro de cierto rango. Por ejemplo, digamos que me invento una función de "HASH" y le llamo [MENEAMEHASH] que convertirá cualquier texto a un número entre 1 y 9999.
Al pasar mi texto "Hola Mundo" a través de [MENEAMEHASH] digamos que me dá como resultado 1234.
Si paso otro texto como "Adiós Mundo" a través de [MENEAMEHASH] nos da otro número diferente por ejemplo 6339.
Esto resulta muy útil en sistemas de información porque permite por ejemplo autenticar a un usuario a través de un clave sin necesidad de conocer la clave. Así, si un "atacante" obtiene acceso a nuestra base de datos donde almacenamos la información de autenticación, este no podrá ver el texto original que nuestro usuario eligió como clave y utilizarla en otros sistemas donde muy probablemente podría haberla utilizado.
Un buen algoritmo de hash, tiene ciertas características que se explican en el artículo, como por ejemplo el efecto cascada que un pequeño cambio en el texto de entrada provoca una gran variación en el número que se obtiene como resultado luego de aplicar la operación matemática.
Las vulnerabilidades de algoritmos de hash se centran más bien en el algoritmo, esto lo hacen buscando alguna vulnerabilidad en el mismo de tal manera que "fabricando un texto" el resultado se corresponda con el de otro texto diferente o en buscar dentro del mismo hash patrones que podrían darnos pistas sobre qué tipo de datos se utilizó para generarlos.
Por ejemplo digamos que mi [MENEAMEHASH] tiene una vulnerabilidad y digamos que el tercer dígito corresponde al número de vocales en la palabra y el último dígito corresponde al número de caracteres en la entrada:
Significa que si encuentro un hash como el siguiente:
6424
En vez de probar 20,000 palabras de un diccionario para ver si coinciden con el [MENEAMEHASH] de HOLA, podría centrar mi búsqueda únicamente en:
COSA, FOSA, MOZA, HOLA
Reduciendo de manera muy efectiva los tiempos de búsqueda.
En resumen: un HASH es el resultado de una operación matemática muy compleja, que se utiliza entre otras cosas para tareas de autenticación.
#6:
#3 te he votado aunque no me he enterado de nada, para hacerme el listo basicamente
#34:
#32 Pues sí. Una Sapphire Radeon HD 7970 (230€) te calcula unos 8.000 millones de MD5 por segundo, eso son 691200000 millones al día. En 5 días te rompe por fuerza bruta todas las contraseñas de hasta 10 caracteres (minusculas alfanumerico) y luego puedes jugar a algo con la tarjeta
Es interesante, pero creo que mezcla varios conceptos de manera errónea. Primero porque habla de "crackear" hash como si se tratara de funciones de cifrado de donde podemos obtener el texto original a partir de los datos contenidos HASH y esto no es posible.
Un hash en simplemente una operación matemática que convierte un texto como "Hola Mundo" a un número cuyo valor puede estar dentro de cierto rango. Por ejemplo, digamos que me invento una función de "HASH" y le llamo [MENEAMEHASH] que convertirá cualquier texto a un número entre 1 y 9999.
Al pasar mi texto "Hola Mundo" a través de [MENEAMEHASH] digamos que me dá como resultado 1234.
Si paso otro texto como "Adiós Mundo" a través de [MENEAMEHASH] nos da otro número diferente por ejemplo 6339.
Esto resulta muy útil en sistemas de información porque permite por ejemplo autenticar a un usuario a través de un clave sin necesidad de conocer la clave. Así, si un "atacante" obtiene acceso a nuestra base de datos donde almacenamos la información de autenticación, este no podrá ver el texto original que nuestro usuario eligió como clave y utilizarla en otros sistemas donde muy probablemente podría haberla utilizado.
Un buen algoritmo de hash, tiene ciertas características que se explican en el artículo, como por ejemplo el efecto cascada que un pequeño cambio en el texto de entrada provoca una gran variación en el número que se obtiene como resultado luego de aplicar la operación matemática.
Las vulnerabilidades de algoritmos de hash se centran más bien en el algoritmo, esto lo hacen buscando alguna vulnerabilidad en el mismo de tal manera que "fabricando un texto" el resultado se corresponda con el de otro texto diferente o en buscar dentro del mismo hash patrones que podrían darnos pistas sobre qué tipo de datos se utilizó para generarlos.
Por ejemplo digamos que mi [MENEAMEHASH] tiene una vulnerabilidad y digamos que el tercer dígito corresponde al número de vocales en la palabra y el último dígito corresponde al número de caracteres en la entrada:
#32 Pues sí. Una Sapphire Radeon HD 7970 (230€) te calcula unos 8.000 millones de MD5 por segundo, eso son 691200000 millones al día. En 5 días te rompe por fuerza bruta todas las contraseñas de hasta 10 caracteres (minusculas alfanumerico) y luego puedes jugar a algo con la tarjeta
Y ya que estamos con la seguridad en contraseñas, si estas haciendo software la recomendación es que JAMAS USES UNA FUNCION DE HASH así a pelo (ni con salt). Debes usar una Key Derivation Function como bcrypt, scrypt o PBKDF2. Las funciones de hash estan pensadas para ser rapidas, las key derivation functions NO. Por ejemplo usando bcrypt, con la tarjeta de #34 en vez de los 8000 millones por segundo de MD5 te quedas en 10.000 - 20.000
#25#27 a lo mejor es que no todo el mundo aquí es un superjuanker como vosotros, y un poco de divulgación matemática no viene mal a estos seres inferiores.
#1 Como curiosidad, aunque los hash en teoría son "irrompibles" (es un algoritmo unidireccional, en teoría de un texto o clave puedes sacar el hash, pero el camino contrario no es posible, en realidad a un hash corresponden muchos infinitos posibles textos originales de distintas longitudes) sin embargo hace poco encontré webs que se dedican a coleccionar pares clave-hash (obtenidos con distintos algoritmos) para que dado un hash, si alguien había almacenado esa misma clave poder obtenerla, claro solo es válido para claves "comunes" pero aun así me sorprendió el método, no es difícil alimentar una base de datos con los hash de diccionarios y de bases de datos de contraseñas ya pirateadas de otros lados con lo que acaban teniendo una relativa efectividad
#6 Imagina que las funciones hash son como una batidora. Tú metes cosas, le das al botón, y obtienes un resultado, que siempre es del mismo tamaño, el del vaso de la batidora, y donde lo único que importa es el color. ¿Metes una calabaza y un pepino? El resultado es un naranja blanquecino. ¿Metes fresas y berenjenas? Sale morado rojizo.
Ahora, como es lógico, habrá varias combinaciones que den lugar al mismo resultado. Así, si bates coco, el resultado será del mismo color que si bates nata. Has encontrado una colisión: dos elementos base producen el mismo resultado. Dos entradas producen la misma salida.
Ahora imagina que yo hago un catálogo de todo lo que bato. Cada vez que voy a batir algo, hago una foto a lo que voy a meter, y otra al resultado, y monto un catálogo enorme. Vienes tú y me dices "oye, quiero obtener un resultado azul verdoso, ¿qué meto?". Y yo te digo "pues tal y tal", o "no tengo ni idea, nunca he conseguido ese resultado".
Ahora imagina que por una vulnerabilidad web alguien vuelva en pastebin la base de datos de un banco y, entre otras cosas, contiene una tabla con pares email + hash de contraseña. Si quieres impersonar a alguien, no sabes la contraseña, pero sabes el resultado del hash (que es, simplificando mucho, lo que se usa para autenticar en inernet). Vas a mi catálogo y me preguntas por una entrada (la que sea, te vale cualquiera) a la que al aplicarle la función hash que usa el servidor produzca la salida que has leído de la base de datos. Con esa entrada ya puedes impersonar al usuario en cuestión.
¿Cómo se soluciona esto? Añadiendo, cada vez que bates los ingredientes, un ingrediente extra aleatorio. Esto es lo que se denomina 'salt', como bien dicen por ahí arriba. Así, la contrucción de catálogos es impracticable (ocuparía demasiado tiempo y espacio), pues para cada entrada, tienes que calcular la salida con toooodos los ingredientes extra que existen si queieres obtener un catálogo completo.
Todo esto que te he dicho desde el punto de vista de la autenticación y el almacenamiento de contraseñas. Las funciones hash tienen muchos más usos (por ejemplo, comprobar que algo que te has bajado de internet se ha bajado correctamente y no ha habido errores o intervención de la NSA ). Detección de errores, identificación unívoca, firmas digitales, minado de bitcoins, etc.
#9 como bien dice el amigo son conocidas como rainbow tables.
De ahí que sea tan importante las claves largas por una sola razón. Si tu clave es de 3 hasta 6 , 7 dígitos seguro que habrá una rainbow table con tu contraseña en muchos de los algoritmos usados.
Cada vez que aumenta la capacidad computacional de los ordenadores lo que antes una clave de 8 dígitos se consideraba segura ahora no lo es.
#3no es difícil alimentar una base de datos con los hash de diccionarios y de bases de datos de contraseñas ya pirateadas de otros lados con lo que acaban teniendo una relativa efectividad
Efectivamente. Precisamente por ese motivo el almacenamiento de contraseñas se debe hacer con un hash "salteado". Lo que se hace es añadir a la contraseña un elemento aleatorio y después hacer el hash. De esta forma la misma contraseña estará almacenada en dos sitios web con un valor distinto, lo que inutiliza las "rainbow tables".
Ese elemento aleatorio se almacena junto al hash en texto plano ya que es necesario conocerlo para poder verificar la contraseña cuando el usuario la introduce, aplicando el mismo "salteado" y comprobando que los valores coinciden. Que el atacante conozca ese valor aleatorio es irrelevante, ya que el efecto de inutilizar esas "rainbow tables" se consigue igualmente.
#21 Voy a tener que ponerte un cascabel para saber (en que user) andas jajaja ^^ buenas tardes! que esta mañana te he visto pero desde la tablet desayunando y con mis dedacos odio teclear ahi
#3 Buen apunte, pero me llama muchísimo la atención el tachado sobre "infinitos" y que dejes "muchos", porque yo diría que es al justo al revés. A ver si me sale el razonamiento ...
-El conjunto de textos posibles, de todas las longitudes, con un alfabeto concreto tiene tamaño infinito.
-El conjunto de hashes posibles, aunque enorme, tiene un tamaño finito.
-Un hash se podría entender como una función sobreyectiva que te lleva del primer conjunto al segundo (?).
Entiendo que todo esto es posible sólo si hay un número infinito de textos que generan el mismo hash, no?
#15 En cualquier caso "resumen criptográfico". La definición inglesa no lo define para nada como "resumen" sino más bien como trocear o hacer una mezcla.
Y es que un hash en realidad no se parece en nada a un "resumen" ya que no es fiel al contenido original. Es un contenido derivado a través de métodos matemáticos, mientras que cuando nos referimos a "resumen" lo hacemos en base al significado.
#16
Efectivamente, es un resumen criptográfico y se puede elidir perfectamente el adjetivo criptográfico ya que se deriva del contexto.
No es un picado o troceado (y mucho menos una remezcla) ya que el resumen es obtenido en base a una serie de operaciones sobre el texto original (que pueden ser operaciones de troceado, picado o mezclado) y el resultado es un extracto identificador de ese texto, normalmente de una longitud mucho menor al texto original, como un resumen.
#17 Que tenga una longitud menor no lo hace un resumen, como bien apuntas en tu comentario más bien sería un identificador. Un resumen requiere mantener el significado, la esencia, del contenido original y no es el caso.
resumir.
(Del lat. resumĕre, volver a tomar, comenzar de nuevo).
1. tr. Reducir a términos breves y precisos, o considerar tan solo y repetir abreviadamente lo esencial de un asunto o materia. U. t. c. prnl.
2. tr. Dicho del actuante: Repetir el silogismo del contrario.
3. prnl. Dicho de una cosa: Convertirse, comprenderse, resolverse en otra.
4. prnl. C. Rica. Dicho de un líquido: Filtrarse o absorberse.
#19
En la definición que has puesto tienes las acepción 3 que viene a ser lo que hace una función hash. Convertir o resolver una cadena de Bytes en otra.
#30 Solo decir que las rainbow tables a día de hoy estan completamente obsoletas con las GPUs actuales y programas como: http://hashcat.net/oclhashcat/
Las rainbow tables consitian en calcular un monton de hashes, guardarlos en disco y luego comprobar si los que estas buscando estaban en esa tabla, pero hoy en día no tiene sentido generar 4TB de hashes (aproximadamente 100.000 millones de MD5 por poner un ejemplo) cuando en un minuto con una grafica de 200€ los puedes chequear (esos y más).
La pregunta que me hago: ¿Entonces, cuando un webmail guarda la información de cuentas externas (por ejemplo cuando importas otras cuentas POP3 a Gmail), éstas contraseñas externas se guardan en texto plano?
Puede que las guarde cifradas en la base de datos pero la clave de descifrado necesita tenerla disponible cada vez que lee ese contenido, por lo que estará en memoria u otro tipo de almacenamiento, pero sea como fuere el atacante tiene la posibilidad de acceder a esa clave de descifrado.
Comentarios
Es interesante, pero creo que mezcla varios conceptos de manera errónea. Primero porque habla de "crackear" hash como si se tratara de funciones de cifrado de donde podemos obtener el texto original a partir de los datos contenidos HASH y esto no es posible.
Un hash en simplemente una operación matemática que convierte un texto como "Hola Mundo" a un número cuyo valor puede estar dentro de cierto rango. Por ejemplo, digamos que me invento una función de "HASH" y le llamo [MENEAMEHASH] que convertirá cualquier texto a un número entre 1 y 9999.
Al pasar mi texto "Hola Mundo" a través de [MENEAMEHASH] digamos que me dá como resultado 1234.
Si paso otro texto como "Adiós Mundo" a través de [MENEAMEHASH] nos da otro número diferente por ejemplo 6339.
Esto resulta muy útil en sistemas de información porque permite por ejemplo autenticar a un usuario a través de un clave sin necesidad de conocer la clave. Así, si un "atacante" obtiene acceso a nuestra base de datos donde almacenamos la información de autenticación, este no podrá ver el texto original que nuestro usuario eligió como clave y utilizarla en otros sistemas donde muy probablemente podría haberla utilizado.
Un buen algoritmo de hash, tiene ciertas características que se explican en el artículo, como por ejemplo el efecto cascada que un pequeño cambio en el texto de entrada provoca una gran variación en el número que se obtiene como resultado luego de aplicar la operación matemática.
Las vulnerabilidades de algoritmos de hash se centran más bien en el algoritmo, esto lo hacen buscando alguna vulnerabilidad en el mismo de tal manera que "fabricando un texto" el resultado se corresponda con el de otro texto diferente o en buscar dentro del mismo hash patrones que podrían darnos pistas sobre qué tipo de datos se utilizó para generarlos.
Por ejemplo digamos que mi [MENEAMEHASH] tiene una vulnerabilidad y digamos que el tercer dígito corresponde al número de vocales en la palabra y el último dígito corresponde al número de caracteres en la entrada:
POr ejemplo
MITEXTO -> [MENEAMEHASH] -> 3237
HOLA -> [MENEAMEHASH] -> 5424
Significa que si encuentro un hash como el siguiente:
6424
En vez de probar 20,000 palabras de un diccionario para ver si coinciden con el [MENEAMEHASH] de HOLA, podría centrar mi búsqueda únicamente en:
COSA, FOSA, MOZA, HOLA
Reduciendo de manera muy efectiva los tiempos de búsqueda.
En resumen: un HASH es el resultado de una operación matemática muy compleja, que se utiliza entre otras cosas para tareas de autenticación.
#32 Pues sí. Una Sapphire Radeon HD 7970 (230€) te calcula unos 8.000 millones de MD5 por segundo, eso son 691200000 millones al día. En 5 días te rompe por fuerza bruta todas las contraseñas de hasta 10 caracteres (minusculas alfanumerico) y luego puedes jugar a algo con la tarjeta
Y ya que estamos con la seguridad en contraseñas, si estas haciendo software la recomendación es que JAMAS USES UNA FUNCION DE HASH así a pelo (ni con salt). Debes usar una Key Derivation Function como bcrypt, scrypt o PBKDF2. Las funciones de hash estan pensadas para ser rapidas, las key derivation functions NO. Por ejemplo usando bcrypt, con la tarjeta de #34 en vez de los 8000 millones por segundo de MD5 te quedas en 10.000 - 20.000
WTF?! ¿Un artículo sobre un concepto criptográfico más visto que el tebeo y encima en inglés? Y pila de votos.
Relacionado: http://es.wikipedia.org/wiki/MD5#Seguridad
Esto es noticia?
#25 Ya te digo. Igual lo próximo será redescubrir las tablas de dispersión
#25 #27 a lo mejor es que no todo el mundo aquí es un superjuanker como vosotros, y un poco de divulgación matemática no viene mal a estos seres inferiores.
#41 La verdad es que, desde que no hay noticias de medios AEDE, Menéame se ha vuelto mucho más instructivo.
Para auténticos "frikis"
#1 Como curiosidad, aunque los hash en teoría son "irrompibles" (es un algoritmo unidireccional, en teoría de un texto o clave puedes sacar el hash, pero el camino contrario no es posible, en realidad a un hash corresponden muchos
infinitosposibles textos originales de distintas longitudes) sin embargo hace poco encontré webs que se dedican a coleccionar pares clave-hash (obtenidos con distintos algoritmos) para que dado un hash, si alguien había almacenado esa misma clave poder obtenerla, claro solo es válido para claves "comunes" pero aun así me sorprendió el método, no es difícil alimentar una base de datos con los hash de diccionarios y de bases de datos de contraseñas ya pirateadas de otros lados con lo que acaban teniendo una relativa efectividad(esto también era comentario friki )
#3 Me ha encantado. Gracias por aumentar mi cultura
#3 te he votado aunque no me he enterado de nada, para hacerme el listo basicamente
#6 Imagina que las funciones hash son como una batidora. Tú metes cosas, le das al botón, y obtienes un resultado, que siempre es del mismo tamaño, el del vaso de la batidora, y donde lo único que importa es el color. ¿Metes una calabaza y un pepino? El resultado es un naranja blanquecino. ¿Metes fresas y berenjenas? Sale morado rojizo.
Ahora, como es lógico, habrá varias combinaciones que den lugar al mismo resultado. Así, si bates coco, el resultado será del mismo color que si bates nata. Has encontrado una colisión: dos elementos base producen el mismo resultado. Dos entradas producen la misma salida.
Ahora imagina que yo hago un catálogo de todo lo que bato. Cada vez que voy a batir algo, hago una foto a lo que voy a meter, y otra al resultado, y monto un catálogo enorme. Vienes tú y me dices "oye, quiero obtener un resultado azul verdoso, ¿qué meto?". Y yo te digo "pues tal y tal", o "no tengo ni idea, nunca he conseguido ese resultado".
Ahora imagina que por una vulnerabilidad web alguien vuelva en pastebin la base de datos de un banco y, entre otras cosas, contiene una tabla con pares email + hash de contraseña. Si quieres impersonar a alguien, no sabes la contraseña, pero sabes el resultado del hash (que es, simplificando mucho, lo que se usa para autenticar en inernet). Vas a mi catálogo y me preguntas por una entrada (la que sea, te vale cualquiera) a la que al aplicarle la función hash que usa el servidor produzca la salida que has leído de la base de datos. Con esa entrada ya puedes impersonar al usuario en cuestión.
¿Cómo se soluciona esto? Añadiendo, cada vez que bates los ingredientes, un ingrediente extra aleatorio. Esto es lo que se denomina 'salt', como bien dicen por ahí arriba. Así, la contrucción de catálogos es impracticable (ocuparía demasiado tiempo y espacio), pues para cada entrada, tienes que calcular la salida con toooodos los ingredientes extra que existen si queieres obtener un catálogo completo.
Todo esto que te he dicho desde el punto de vista de la autenticación y el almacenamiento de contraseñas. Las funciones hash tienen muchos más usos (por ejemplo, comprobar que algo que te has bajado de internet se ha bajado correctamente y no ha habido errores o intervención de la NSA ). Detección de errores, identificación unívoca, firmas digitales, minado de bitcoins, etc.
no confundir con el hash que pasan los nigas del barrio
#3 las tablas esas se llaman tradicionalmente rainbow tables, cosa que incrementa mi teoría de que ambas palabras hash están muy relacionadas
#9 como bien dice el amigo son conocidas como rainbow tables.
De ahí que sea tan importante las claves largas por una sola razón. Si tu clave es de 3 hasta 6 , 7 dígitos seguro que habrá una rainbow table con tu contraseña en muchos de los algoritmos usados.
Cada vez que aumenta la capacidad computacional de los ordenadores lo que antes una clave de 8 dígitos se consideraba segura ahora no lo es.
#11 http://en.wikipedia.org/wiki/Salt_%28cryptography%29
Con esta simpleza, a la basura las rainbow tables: no te basta con saber el algoritmo, también necesitas obtener el salt o como se genera.
#3 no es difícil alimentar una base de datos con los hash de diccionarios y de bases de datos de contraseñas ya pirateadas de otros lados con lo que acaban teniendo una relativa efectividad
Efectivamente. Precisamente por ese motivo el almacenamiento de contraseñas se debe hacer con un hash "salteado". Lo que se hace es añadir a la contraseña un elemento aleatorio y después hacer el hash. De esta forma la misma contraseña estará almacenada en dos sitios web con un valor distinto, lo que inutiliza las "rainbow tables".
Ese elemento aleatorio se almacena junto al hash en texto plano ya que es necesario conocerlo para poder verificar la contraseña cuando el usuario la introduce, aplicando el mismo "salteado" y comprobando que los valores coinciden. Que el atacante conozca ese valor aleatorio es irrelevante, ya que el efecto de inutilizar esas "rainbow tables" se consigue igualmente.
#3 Para eso existe la sal
(ya lo dijo #14)
#14 Vaya, no se me había ocurrido pensar en esa solución. Gracias por el aporte
#14 Venía a decir lo mismo que tú así que me callo y te positivizo.
#3 ¡Uauuu! Qué divino eres, gansón!
#21 Voy a tener que ponerte un cascabel para saber (en que user) andas jajaja ^^ buenas tardes! que esta mañana te he visto pero desde la tablet desayunando y con mis dedacos odio teclear ahi
#48 Me di por saludada gansón, ese votassso lo decía todo, el que tienes puesto ahora psshhh
#3 Buen apunte, pero me llama muchísimo la atención el tachado sobre "infinitos" y que dejes "muchos", porque yo diría que es al justo al revés. A ver si me sale el razonamiento ...
-El conjunto de textos posibles, de todas las longitudes, con un alfabeto concreto tiene tamaño infinito.
-El conjunto de hashes posibles, aunque enorme, tiene un tamaño finito.
-Un hash se podría entender como una función sobreyectiva que te lleva del primer conjunto al segundo (?).
Entiendo que todo esto es posible sólo si hay un número infinito de textos que generan el mismo hash, no?
#29 Si cierto, lo siento el tachado realmente es de meneame no me di cuenta, cuando en meneame pones algo entre guiones lo deja tachado
asi#1 Pasate por aquí amigo →
http://www.kriptopolis.com/
¡Son todos mú majos!
#7 muito obrigado
#1 Para auténticos "frikis"
O para profesionales de la informática
hash == resumen.
#15 En cualquier caso "resumen criptográfico". La definición inglesa no lo define para nada como "resumen" sino más bien como trocear o hacer una mezcla.
http://www.oxforddictionaries.com/definition/english/hash
Y es que un hash en realidad no se parece en nada a un "resumen" ya que no es fiel al contenido original. Es un contenido derivado a través de métodos matemáticos, mientras que cuando nos referimos a "resumen" lo hacemos en base al significado.
#16
Efectivamente, es un resumen criptográfico y se puede elidir perfectamente el adjetivo criptográfico ya que se deriva del contexto.
No es un picado o troceado (y mucho menos una remezcla) ya que el resumen es obtenido en base a una serie de operaciones sobre el texto original (que pueden ser operaciones de troceado, picado o mezclado) y el resultado es un extracto identificador de ese texto, normalmente de una longitud mucho menor al texto original, como un resumen.
#17 Que tenga una longitud menor no lo hace un resumen, como bien apuntas en tu comentario más bien sería un identificador. Un resumen requiere mantener el significado, la esencia, del contenido original y no es el caso.
resumir.
(Del lat. resumĕre, volver a tomar, comenzar de nuevo).
1. tr. Reducir a términos breves y precisos, o considerar tan solo y repetir abreviadamente lo esencial de un asunto o materia. U. t. c. prnl.
2. tr. Dicho del actuante: Repetir el silogismo del contrario.
3. prnl. Dicho de una cosa: Convertirse, comprenderse, resolverse en otra.
4. prnl. C. Rica. Dicho de un líquido: Filtrarse o absorberse.
#19
En la definición que has puesto tienes las acepción 3 que viene a ser lo que hace una función hash. Convertir o resolver una cadena de Bytes en otra.
#15 #16 Yo siempre lo he llamado "digestión".
Si lo buscas en Google imágenes sale esto, jaja
https://www.google.co.uk/search?q=hash&source=lnms&tbm=isch&sa=X&ei=13BqU9KgDcaHONyngJgB&ved=0CAYQ_AUoAQ&biw=1535&bih=803
Resumiendo, el hash puede ser un algoritmo o la resina de la flores del cannabis y a veces hay errores en el código...
...¿quién no ha roto nunca un plato?
1234 + GATO = G1A2T3O4
Las tablas rainbow, que recuerdo hace unos años cuando usaba el ophcrack.
A día de hoy sigue existiendo, por si alguien le interesa y quiere aprender a saber lo que es una contraseña segura:
http://ophcrack.sourceforge.net/
#30 Solo decir que las rainbow tables a día de hoy estan completamente obsoletas con las GPUs actuales y programas como: http://hashcat.net/oclhashcat/
Las rainbow tables consitian en calcular un monton de hashes, guardarlos en disco y luego comprobar si los que estas buscando estaban en esa tabla, pero hoy en día no tiene sentido generar 4TB de hashes (aproximadamente 100.000 millones de MD5 por poner un ejemplo) cuando en un minuto con una grafica de 200€ los puedes chequear (esos y más).
#31 ¿Por fuerza bruta? ¿tan rápido? que atrasado estoy...
Cuando empiecen a comercializar los procesadores cuánticos van a tener que ponerse las pilas de verdad en tema de criptografia
#32 criptografía cuántica
La pregunta que me hago: ¿Entonces, cuando un webmail guarda la información de cuentas externas (por ejemplo cuando importas otras cuentas POP3 a Gmail), éstas contraseñas externas se guardan en texto plano?
#42 Sí.
Puede que las guarde cifradas en la base de datos pero la clave de descifrado necesita tenerla disponible cada vez que lee ese contenido, por lo que estará en memoria u otro tipo de almacenamiento, pero sea como fuere el atacante tiene la posibilidad de acceder a esa clave de descifrado.
Y si hasheas y creas una tabla royo diccionario (python en sus diccionarios hashea) puedes acceder a sus contenidos con el hash-tag (#)
"Una función hash criptográfica es simplemente un algoritmo, o un conjunto de pasos matemáticos, interpretadas por una computadora. "
Ok, según la definición todo software es una función hash criptográfica.
Interesante para los que no sabemos mucho del tema. Gracias por el aporte!
Yo siempre que leo hash me recuerda lo que aprendí fumando porros: perl, md5, ...
Maldito hashing dinámico que me tuve que estudiar en la carrera!!!
Un ejemplo de uso de un hash: Restringir la ejecución de un programa:
Deshabilitar el uso de Internet Explorer sobre Windows XP
Deshabilitar el uso de Internet Explorer sobre Win...
sysadmit.com