http://es.wikipedia.org/wiki/Algoritmo_MD5
Aqui dice como se calcula un MD5.
basicamente, tu password viaja en texto plano hasta el servidor. El servidor la toma, la encripta en MD5 y Compara con el hash (o contraseña ya encriptada cuando te registraste). Si coinciden, tu contraseña es correcta, sino, te tira para atras...
Si alguien tuviese acceso a tu hash, y lo intentara enviar.. se enviria el hash.. pero ese hash seria re-encriptado dando otro hash.. con muy altas probabilidades de que NO coincida. Y te tira para tras...
si no le pifio, reitérese si no le pifio. si alguien tiene un hash o md5 podría llegar a ser capaz de dar con otra palabra qeu genere el mismo hash (de suponer que conoce el algoritmo de hashing usado, claro).
Ezequiel1414 escribió:
Igual sigue el mismo problema, el usuario y contraseña viaja en texto plano. Si estas conectado a traves de un acceso inalambrico te pueden capturar los paquetes con el air-crack de una manera MUY sencilla.
Pero si queres enviar los datos con un certificado SSL es realmente muy costoso. Por lo que vi no bajan de los 200 u$s (los baratos).
Entonces me queda la duda, porque no usan algun algoritmo de incriptacion en el cliente y luego lo decriptan cuando llega al server?. Hay algoritmos de licencia publica que no pasan las 20 lineas de codigo. Por ejemplo el TEA (<a>)
encriptado o no, volves a qeu si algun nabo ve qeu envias y lo envía él, aunque te hayas tomados dos años para generar la supre clave del lado cliente, ya la tiene y punto. O sea, o se envia por tunel o no tiene mucho sentido.
pd: por las dudas, la seguridad _no es_ mi dominio principal (tendré un dominio principal? y que no sea dns?... )
pd2//edit: estem... señores, este foro no contiene secretos avismales sobre la raza alienígena (ups, se me escapó, no lean eso...), es más... es un espacio que -segun creo- se funda sobre los mismos valores de confianza que nutrieron las primeras ideas e implementaciones de internet . Serenos, aunque se dé la probabilidad (calcúlela) de que alquien con tiempo libre, con mucho tiempo libre, se dedique a algo así, es más qeu solucionable desde el staff que tenemos, por ende, serenos.
Para lo único que podría servir un password es para entrar a otro servicio que tengas en otro lugar.
Con un hash eso no se puede... a menos que tengas tan mala leche que los dos utilicen exactamente el mismo algoritmo de cifrado sin aplicar ningún tipo de semilla. Infinitos passwords que matcheen en este foro no sirven para nada más allá del mismo foro.
Si sucediera eso, creo que sería lisa y llanamente mala leche...
-----
Por otro lado...
Suponiendo que se quieran enviar datos, textos, cosas de mayor importancia que una simple clave de Foro. (Sigo con la idea de que te traés algo de entre manos)
Yo creo que la movida está en las "Firmas Digitales"...
(Usa Hashes, pero además se necesita de Claves Públicas y Claves Unicas para decriptarlo. Ni idea de la implementación.)
Si bajas algo ilegal, participas en un foro ilegal (no sé porque se me vino a la mente cierta palabra.. ), tenga el sitio o no ssl, se sabe, quedan registros que te conectaste desde x hasta y. Encuentran y.. y fuiste.
notienes forma de esconderte y/o escapar.. the big brother is watching u
encriptado o no, volves a qeu si algun nabo ve qeu envias y lo envía él, aunque te hayas tomados dos años para generar la supre clave del lado cliente, ya la tiene y punto. O sea, o se envia por tunel o no tiene mucho sentido..
No entiendo que queres decir bien. Te referis a que alguien intercepte tus paquetes, LOS DESENCRIPTE, cambie el mensaje y lo vuelva a enviar encriptados?
Si lo decís así, el intruso necesitaría un laburo importante para poder desencriptarlo y hay muchos algoritmos comunes que se saben que son muy jodidos de romper. En definitiva, seria mas fácil encontrarte en la facultad y bajarte los dientes hasta que le des tu pass.
Si decís solamente que alguien intercepte los paquetes, que NO los desencripte y mande despues lo que se le antoja, eso es otro tema, pero igualmente, no obtendria tu password que es creo a lo que apunta Ezequiel (creo ).
Con respecto a lo que dice JuanC de que los Hash son seguros... no, no lo son
En realidad depende de para que los quieras usar. En este caso, solo sirve para que un supuesto intruso no obtenga tu password verdadera, pero eso no le impide entrar a tu cuenta.
Pero eso no significa que sean (las funciones de Hash) una herramienta de seguridad por si mismas, porque de hecho no lo son.
Me parece que no se implementa porque quien lo tiene que implementar no tiene ganas de gastar SU tiempo en hacer algo al pedo, lo que me parece totalmente justificado si tienen en cuenta que no son ustedes los que tienen que sentar el traste a programar/probar/etc.
Es un rompedero de huevos injustificado, es mas probable que te vean tipear la pass, que te pongan un keyloger o que te caguen por otro lado (y que tengas la misma pass aca tmb) antes de que alguien te capte un paquete en una red wi-fi para molestarte en el foro de la facultad...
_________________ Cantando con Windows:
Código:
C:\>If you're happy and you know it, syntax error!
Syntax error
C:\>If you're happy and you know it, syntax error!
Syntax error
C:\>If you're happy and you know it, and you really want to show it, if you're happy and you know it syntax error
Syntax error
C:\>
En la pagina principal del foro, donde esta la caja para hacer el login, no esta en HTTPs. Por lo tanto, aclaro que no tengo ni idea, ¿los nombres de usuario y contraseña viajan <b>sin</b> encriptacion por la web?
Más allá de que creo que entre todos te respondieron más o menos todo, hago una respuesta más o menos global.
En primer lugar, no existe un sitio donde la autenticación se haga en HTTPS. O todo el sitio es HTTPS o todo el sitio es HTTP. Son dos protocolos distintos, son dos puertos distintos, y son dos servidores distintos. Si te autenticaste por HTTPS, la cookie que te ponga dicho sitio, no puede leerse desde el servidor HTTP. (Sí tenés servicios mixtos donde podés navegar HTTP antes de autenticarte, pero una vez autenticado, o es todo HTTP o todo HTTPS).
Ofrecer una versión HTTPS del sitio no debería ser muy complejo (bah, ahora en DreamHost no tengo ni idea, pero en cualquier servidor es trivial); es simplemente generar un par de claves (por cierto, Pepperz era un Debian ) y forzar a navegar sobre claves. Ahora sí, si bien generar un par de claves es inmediato, el autenticar dicho certificado sale plata. GoDaddy tiene autenticaciones de menos de los 200 dólares que mencionan, pero, de todos modos, no justifica pagar ni un peso por ello. Navegadores nuevos, como IE7 o FF3, no te dejan navegar una página que no tenga un certificado validado por un organismo de confianza... por lo que ponerle HTTPS al foro, implicaría que, a menos que editaran la política de confiabilidad para Foros-FIUBA a manopla (para FF3 son 3 pantallas en las que intentan disuadirte por todos los modos de que si no sabés lo que estás haciendo, por favor, canceles) el sitio no sería navegable.
Por otro lado, sí, el password viaja en texto plano. Como el password del servidor IRC, como el password del Messenger, como el password del correo de FIUBA (salvo que fuerces HTTPS y autorices el certificado vencido que usan), como toda tu navegación en Hotmail, etc.. La mayor parte de las comunicaciones web viajan desencriptadas, y eso no implica ningún riesgo. Foros-FIUBA no es una página de homebanking, y el escenario de sniffeo que plantean es totalmente desproporcionado para lo que es este foro. Yo esperaría con una probabilidad mucho más alta, que estén usando una máquina con un keylogger instalado, o que estén infectados por un troyano, o que alguien haya vulnerado su sistema y se haya afanado sus claves de encriptación... que alguien revise todo el tráfico para encontrar un post puntual en el que envían su password, lo guarda, y después lo usa maliciosamente, me parece totalmente improbable.
Y si alguien llegara a robarles el usuario, nos mandan un mail y se soluciona en 5 minutos.
Por otro lado, vuelvo a insistir: No sean imbéciles de utilizar un solo password maestro para todo. Yo puedo dar fé de que estadísticamente, el 10% de la gente se suscribe a cualquier cosa con el mismo password del mail desde el cual se está suscribiendo. Yo en Foros-FIUBA confío porque conozco sus fuentes, espero que ustedes también confíen que la parte de login en el foro es vanilla con respecto a la versión oficial de phpBB (por otro lado, insisto, sus passwords no nos sirven de nada para lo administrativo dado que somos administradores); pero no pueden pretender que el 100% de los sitios de la red tienen algo de seguridad en caunto al guardado de contraseña y que eso no lo van a usar para joder después.
encriptado o no, volves a qeu si algun nabo ve qeu envias y lo envía él, aunque te hayas tomados dos años para generar la supre clave del lado cliente, ya la tiene y punto. O sea, o se envia por tunel o no tiene mucho sentido..
No entiendo que queres decir bien. Te referis a que alguien intercepte tus paquetes, LOS DESENCRIPTE, cambie el mensaje y lo vuelva a enviar encriptados?
Si lo decís así, el intruso necesitaría un laburo importante para poder desencriptarlo y hay muchos algoritmos comunes que se saben que son muy jodidos de romper. En definitiva, seria mas fácil encontrarte en la facultad y bajarte los dientes hasta que le des tu pass.
Si decís solamente que alguien intercepte los paquetes, que NO los desencripte y mande despues lo que se le antoja, eso es otro tema, pero igualmente, no obtendria tu password que es creo a lo que apunta Ezequiel (creo ).
Con respecto a lo que dice JuanC de que los Hash son seguros... no, no lo son
En realidad depende de para que los quieras usar. En este caso, solo sirve para que un supuesto intruso no obtenga tu password verdadera, pero eso no le impide entrar a tu cuenta.
Pero eso no significa que sean (las funciones de Hash) una herramienta de seguridad por si mismas, porque de hecho no lo son.
Me parece que no se implementa porque quien lo tiene que implementar no tiene ganas de gastar SU tiempo en hacer algo al pedo, lo que me parece totalmente justificado si tienen en cuenta que no son ustedes los que tienen que sentar el traste a programar/probar/etc.
Es un rompedero de huevos injustificado, es mas probable que te vean tipear la pass, que te pongan un keyloger o que te caguen por otro lado (y que tengas la misma pass aca tmb) antes de que alguien te capte un paquete en una red wi-fi para molestarte en el foro de la facultad...
Por lo menos cumple la función(?), y se nota que para eso es bastante bueno.
(Por algo en muchos casos se usa el Hashing combinado con algún otro tipo de seguridad)
Más allá de que no sea seguro como lo decís, siempre es mejor que enviar un texto sin ningún tipo de codificación.
-----
Cuando se compara el Pass que se "hasheo" con el que está en la DB:
¿Se comparan hashes o cada uno de los textos que generó el hash? (Debe ser lo mismo, aunque comparar el hash seguramente es más rápido - 1 sola comparación del hash, contra las "n" comparaciones de claves generadas por el hash)
No volvió más el muchacho...
El que lo conozca que le avise a la "División de Delitos Informáticos." (No che... No es la DDI)
Edad: 87
Registrado: 30 Jul 2007
Mensajes: 1510
Ubicación: Violando tus prejuicios
Carrera: Electrónica y Informática
Sebastian Santisi escribió:
En primer lugar, no existe un sitio donde la autenticación se haga en HTTPS. O todo el sitio es HTTPS o todo el sitio es HTTP. Son dos protocolos distintos, son dos puertos distintos, y son dos servidores distintos. Si te autenticaste por HTTPS, la cookie que te ponga dicho sitio, no puede leerse desde el servidor HTTP. (Sí tenés servicios mixtos donde podés navegar HTTP antes de autenticarte, pero una vez autenticado, o es todo HTTP o todo HTTPS).
En una epoca gmail usaba, a veces, https para loguearte y dps http... es google, todo lo puede .
Sebastian Santisi escribió:
Por otro lado, sí, el password viaja en texto plano. Como el password del servidor IRC, como el password del Messenger, como el password del correo de FIUBA (salvo que fuerces HTTPS y autorices el certificado vencido que usan), como toda tu navegación en Hotmail, etc.. La mayor parte de las comunicaciones web viajan desencriptadas, y eso no implica ningún riesgo. Foros-FIUBA no es una página de homebanking, y el escenario de sniffeo que plantean es totalmente desproporcionado para lo que es este foro. Yo esperaría con una probabilidad mucho más alta, que estén usando una máquina con un keylogger instalado, o que estén infectados por un troyano, o que alguien haya vulnerado su sistema y se haya afanado sus claves de encriptación... que alguien revise todo el tráfico para encontrar un post puntual en el que envían su password, lo guarda, y después lo usa maliciosamente, me parece totalmente improbable.
De hecho, si se encripta el hash como propuso el que armo el thread, no se mejora nada. La única forma de mejorar algo es usando https y/o en vez de usar md5 usar sha2.
Ahora me voy al debianday, después si me acuerdo intento explicar porque no aporta nada encriptar el hash de la manera que propuso Eze.
Salud!
_________________ LA UNIÓN EN EL REBAÑO OBLIGA AL LEÓN A ACOSTARSE CON HAMBRE.
Es buscando lo imposible que el hombre ha siempre realizado y reconocido lo posible. Aquellos que sabiamente se han limitado a lo que les pareciera posible no han dado un solo paso adelante - Mijail Bakunin
La teoría política no es una ciencia enigmática cuya jerarquía cabalística manejan unos pocos iniciados, sino un instrumento de las masas para desatar la tremenda potencia contenida en ellas. No les llega como un conjunto de mandamientos dictados desde las alturas, sino por un proceso de su propia conciencia hacia la comprensión del mundo que han de transformar - John William Cooke
Personally I'm in favor of democracy, which means that the central institutions in the society have to be under popular control. Now, under capitalism we can't have democracy by definition. Capitalism is a system in which the central institutions of society are in principle under autocratic control. Thus, a corporation or an industry is, if we were to think of it in political terms, fascist; that is, it has tight control at the top and strict obedience has to be established at every level -- there's a little bargaining, a little give and take, but the line of authority is perfectly straightforward. Just as I'm opposed to political fascism, I'm opposed to economic fascism. I think that until major institutions of society are under the popular control of participants and communities, it's pointless to talk about democracy. - Noam Chomsky
En una epoca gmail usaba, a veces, https para loguearte y dps http... es google, todo lo puede .
Es lo mismo que actualmente sigue haciendo Hotmail...
Los tipos tienen implementado un servidor especificamente para logueos (Passport en el caso de Microsoft); todos los servicios postean sobre el servidor de login, el cual usa HTTPS y después redirigen a los sitios destino, que son HTTP. La cookie de login no te la pone el servidor de login, sino que genera una clave que vos posteás sobre el sitio destino y el sitio destino utiliza por detrás para chequear server to server que realmente estés logueado (onda LDAP).
Es cierto, en esos sitios, el posteo exacto del login pasa por HTTPS... pero no todo tu tráfico de información posterior (o sea, no pueden ver tu password, pero sí pueden ver el contenido de todos los mails que leas). Ahora sí, el hash que se genera, el cual te deja entrar libremente al sitio destino porque se asume como un login válido, sí viaja en texto plano, y sí puede ser interceptado. No sería mucho trabajo hacer algún programita que capture esos hashes y no los postee en el navegador destino, pudiendo robar la identidad.
Por lo que decís Google ahora lo maneja todo por HTTPS... si van a Hotmail, van a ver que salvo el post contra Passport, el resto es HTTP.
Para aquellos moderadores que salieron con los tapones de punta, no me importa ni me interesa si me roban la contraseña del foro.
La cosa es que queria hacer una web con login seguro, y por todos lados vi que se necesitaba https. Pero como ustedes no lo usaban, me dije "capaz ellos encontraron la manera de hacer que sea seguro sin la necesidad que sea https". Entonces cree un tema para preguntarles si efectivamente es seguro, y ver como hicieron
Para aquellos moderadores que salieron con los tapones de punta, no me importa ni me interesa si me roban la contraseña del foro.
No es que salieron con los tapones de punta (O por lo menos no creo que lo hayan querido hacer)...
Solo aclararon pautas y medidas de seguridad mínimas que debería tener cada usuario.
Solo es un consejo no usar la misma contraseña para todo sitio habido y por haber, y no fue solo para vos el mensaje, fue para todo aquel que lo leyera, ya que en ningún lado especificaste que tenías miedo de que te roben el pass.
Ya que estás podrías decir que tipo de "seguridad" pensas implementar en tu sitio (Ya que tiraste el pie) así por lo menos el tema queda completo/cerrado (Es una opinión)
Para aquellos moderadores que salieron con los tapones de punta, <b> no me importa ni me interesa si me roban la contraseña del foro</b>.
Para nada, como dice JuanC; la respuesta acerca de contraseñas es para todos... y también corre para tu proyecto .
Ezequiel1414 escribió:
La cosa es que queria hacer una web con login seguro, y por todos lados vi que se necesitaba https. Pero como ustedes no lo usaban, me dije "capaz ellos encontraron la manera de hacer que sea seguro sin la necesidad que sea https". Entonces cree un tema para preguntarles si efectivamente es seguro, y ver como hicieron
El punto principal es: La seguridad absoluta en internet no existe. Podés tener cosas más seguras que otras, pero no hay nada infaliblemente seguro.
Utilizar técnicas de encriptación para algo del estilo del login de un foro, es algo totalmente injustificado... es más probable que nos hackeen el foro completo y se roben todos los datos a que alguien intercepte esos datos en el camino intermedio .
De lo que contenga la página web que querés hacer dependerá si necesitás usar HTTPS o no... son muy pocas las cosas que realmente lo necesitan; y la idea es más bien crear una sensación de falsa seguridad.
Lo que se dice infalible, nada es infalible... más allá de que determinadas maneras de encriptación sean más o menos seguras.
Para la discusión encriptación versus hashes; la gracia del hash es que es un camino sólo de ida, por lo que los datos de origen están seguros. La encriptación tiene que ser desencriptable por el receptor en destino, por lo que es un camino de dos lados, y como camino de dos lados, se puede y es necesario desencriptar.
Por supuesto, preocupate por el tema si sos una minita famosa que está sacándose fotos sensuales con su celular, o si estás jugando con tu cuenta bancaria .
Ver tema siguiente Ver tema anterior Podés publicar nuevos temas en este foro No podés responder a temas en este foro No podés editar tus mensajes en este foro No podés borrar tus mensajes en este foro No podés votar en encuestas en este foro No Podéspostear archivos en este foro No Podés bajar archivos de este foro
Todas las horas son ART, ARST (GMT - 3, GMT - 2 Horas)
Protected by CBACK CrackerTracker 365 Attacks blocked.