El Thursday 16 August 2007 10:16:49 Iñaki Baz Castillo escribió:
El Tuesday 14 August 2007 16:42:01 Javier Allende Astigarraga escribió:
Como puedo mejorar la seguridad en el momento de registrarse?? ya he comprobado que con http digest puedo obtener la contraseña
¿Qué es lo que has comprobado? ¿Has mirado cómo funciona el http-digest? Lo que se envía NO es la contraseña, es la respuesta a un desafío en el que el emisor (el servidor) y el desafiado (el llamante) comparten un secreto (la contraseña del llamante). En ningún caso se envía la contraseña en texto plano ni nada similar.
Pero no es imposible sacar la contraseña a partir del hash, ¿no?
Ciao
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
El 16/08/07, Antonio Pardo antonio.pardo@gmail.com escribió:
El Thursday 16 August 2007 10:16:49 Iñaki Baz Castillo escribió:
El Tuesday 14 August 2007 16:42:01 Javier Allende Astigarraga escribió:
Como puedo mejorar la seguridad en el momento de registrarse?? ya he comprobado que con http digest puedo obtener la contraseña
¿Qué es lo que has comprobado? ¿Has mirado cómo funciona el http-digest? Lo que se envía NO es la contraseña, es la respuesta a un desafío en el que el emisor (el servidor) y el desafiado (el llamante) comparten un secreto (la contraseña del llamante). En ningún caso se envía la contraseña en texto plano ni nada similar.
Pero no es imposible sacar la contraseña a partir del hash, ¿no?
Ciao
-- http://debaser.homelinux.com/
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Aupa, Saúl Ibarra escribió:
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta. El SipCrack, lo que hace es lo siguiente, teniendo el reto ,que viene en los paquetes sip como "nonce" (creo), saca el hash para cada una de las contraseñas que le pasas en el diccionario en uno de los parámetros y la compara y cuando una coincide es entonces cuando la da por valida (ojo, que no tiene porque ser la contraseña, podría ser una colisión). Siento la chapa, y espero no haber metido demasiado la pata, un saludo.
El Thu, 16 Aug 2007 15:57:38 +0200 David Santamaria david@irontec.com escribió:
Aupa, Saúl Ibarra escribió:
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta. El SipCrack, lo que hace es lo siguiente, teniendo el reto ,que viene en los paquetes sip como "nonce" (creo), saca el hash para cada una de las contraseñas que le pasas en el diccionario en uno de los parámetros y la compara y cuando una coincide es entonces cuando la da por valida (ojo, que no tiene porque ser la contraseña, podría ser una colisión). Siento la chapa, y espero no haber metido demasiado la pata, un saludo.
si el algoritmo de hash es md5 las posibilidades de colisión creo que andan en torno a 1/2^128
El Thursday 16 August 2007 15:57:38 David Santamaria escribió:
Aupa,
Saúl Ibarra escribió:
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta. El SipCrack, lo que hace es lo siguiente, teniendo el reto ,que viene en los paquetes sip como "nonce" (creo), saca el hash para cada una de las contraseñas que le pasas en el diccionario en uno de los parámetros y la compara y cuando una coincide es entonces cuando la da por valida (ojo, que no tiene porque ser la contraseña, podría ser una colisión). Siento la chapa, y espero no haber metido demasiado la pata, un saludo.
Muy interesante la referencia a la marca de tiempo (caducidad).
Muy buena la explicación :P
Lo cierto es que normalmente las contraseñas las suelen poner demasiado "fáciles", pero la seguridad va en contra de la "usabilidad" (o eso es lo que el usuario entiende.)
El 16/08/07, David Santamaria david@irontec.com escribió:
Aupa, Saúl Ibarra escribió:
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta. El SipCrack, lo que hace es lo siguiente, teniendo el reto ,que viene en los paquetes sip como "nonce" (creo), saca el hash para cada una de las contraseñas que le pasas en el diccionario en uno de los parámetros y la compara y cuando una coincide es entonces cuando la da por valida (ojo, que no tiene porque ser la contraseña, podría ser una colisión). Siento la chapa, y espero no haber metido demasiado la pata, un saludo.
-- David Santamaria Irontec: Internet y Sistemas sobre GNU/Linux http://www.irontec.com +34 944048182
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Hola David,
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta.
Genial y, sobre todo, sencilla explicación! :-)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
El jue, 16-08-2007 a las 18:06 +0200, Jesus Rodriguez escribió:
Hola David,
Nop, yo en el e-Verano les hice una mini-demo de claves "super-seguras". Le puse a un telefono de clave 1234, capture un REGISTER con sipdump (que tiene el texto del desafio y la respuesta) y sipcrack tardó menos de 1 segundo en decirme la clave (haciendo ataque con diccionario).
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta.
Genial y, sobre todo, sencilla explicación! :-)
Será pa ti...pq yo no me enteré de nada XD
Saludos JesusR.
Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305
Users-es mailing list Users-es@openser.org http://openser.org/cgi-bin/mailman/listinfo/users-es
Hola,
No soy un expero, pero aunque no esta la contraseña, esta todo lo que necesitas saber... o eso creo.
La contraseña efectivamente no va ahi, pero no es tan sencillo el asunto. (Espero ser lo menos impreciso posible, aunque se aceptaran todas las correcciones de los RFC readers que hay por aquí :P) En el mecanismo de desafió/respuesta, lo que el Registar envía al UA es un desafió que incluye entre otras cosas una marca de tiempo para que el desafió tenga un periodo de caducidad, el UA al recibir ese reto une su contraseña a ese reto y la "hashea"normalmente con MD5 (el cual tiene colisiones, al igual que todos los mecanismos de HASH) y eso conforma la respuesta al reto que es o que sera enviado (con lo cual, la contraseña nunca viaja a través de la red, en un mecanismo de registro o en un invite). En todo caso, ese hash (respuesta) llega al registar y es el que conociendo el reto y la contraseña aplica el mismo mecanismo que el cliente para crear la respuesta y si su respuesta y la del cliente coinciden es entonces cuando tomo la autenticación como correcta.
Genial y, sobre todo, sencilla explicación! :-)
Será pa ti...pq yo no me enteré de nada XD
La otra opción que tienes es leer las 34 páginas de la RFC2617... perfectamente resumidas en mucho menos por David :-)
Saludos JesusR.
------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr@voztele.com http://www.voztele.com Tel. 902360305 -------------------------------------
sr-users-es@lists.kamailio.org
-
Antonio Pardo -
David Santamaria -
Iñaki Baz Castillo -
Jesus Rodriguez -
Jon Bonilla -
Lukas Sky -
Saúl Ibarra