 |
Bienvenido a nuestro blog. Suscribirse
Audiencia:
Buscar
Que nadie se entereEstoy enamorado de mi GridPanel
… y no quiero que nadie me lo saque. Por eso voy a encriptar mis contraseñas Hace unas semanas, entre los primeros pedidos de Ideas a la carta, estaba el de registro seguro en el Panel de Control. La idea era interesantísima, y nos llevó a meternos en una de las partes más hardcore de la seguridad informática: encriptación. La Idea Gustavo proponía era usar SSL, es decir HTTPS, muy conocido porque Hotmail, Gmail, Yahoo! y muchos más lo usan para garantizar la privacidad de sus usuarios al ingresar a sus casillas de mail. HTTPS, sin embargo, no se puede usar en este caso, porque precisa un certificado de validez pago que lo extienden organismos dedicados a eso (como Verisign), y ese certificado se extiende una vez por host. Tenemos muchos hosts ¿Cómo hacemos para hacer el login al Grid Panel seguro? Bien, tenemos que encriptar la contraseña antes de mandarla. Googleamos en busca de código libre para poder encriptar con javascript del lado del usuario y después desencriptar con php, usando el algoritmo DES.
Afortunadamente alguien lo había hecho
El dilema surge cuando no sólo Ana quiere mandarle mensajes a Bernardo, sino que Carolina también. Ana y Bernardo podrían compartir su código con Carolina, pero en ese caso, Carolina podría leer los mensajes de Ana, y al revés. Carolina podría tener su propio código con Bernardo, pero si hubiera más personas, Bernardo empezaría a tener que conocer muchísimos códigos, y se confundiría. Peor aún si la gente que le manda mensajes a Bernardo es mucha y cambia constantemente. Recordamos entonces la existencia de unos algoritmos muy chulos que funcionan muy distinto que los tradicionales como DES. RSA, DSA y compañía son algoritmos en los que el mensaje se encripta usando un código y se desencripta usando otro distinto. Y no es nada fácil conocer uno sólo sabiendo el otro. ¿Cómo puede ser? Es por una maravilla de las matemáticas y buena combinación con la computación. Tres científicos (uno por letra) inventaron el RSA, que se basa en la enorme dificultar de factorizar números muy grandes. En definitiva, para romperlo se necesitan siglos de las mejores computadoras del mundo trabajando en conjunto. Lo lamento muchachos, no podemos impedir que sus tataranietos les hackeen el sitio. Ahora sí que soy un playboy!
Bien, bombos y platillos y RSA… ¡Oh! Nos dimos cuenta de un problema. Si Ana encripta su contraseña con nuestra clave pública RSA, nadie la va a poder saber menos el GridPanel. Pero si ella tiene siempre la misma contraseña, y la encripta usando siempre la misma clave, ¡el mensaje resultante es el mismo! Cualquiera que no sea Ana puede enviar ese mensaje encriptado, y el GridPanel, inocente, va a creer que fue Ana. Finalmente hicimos esto:
Rápido y furioso, esto sería:
Una pequeña Odisea
Llegó el momento de escribir el código, así que retomamos nuestro diálogo: Nosotros: ¿Hay código libre de encriptación RSA con javascript y desencriptación RSA con PHP? Google: NO Nosotros: ¿Hay código libre de encriptación RSA con javascript? Google: Sí, acá tenés. Nosotros: ¿Hay código libre de encriptación/decriptación RSA para PHP? Google: Más o menos, acá tenés un poco. Conseguimos una clase Java que hacía la encriptación, la decriptación y la creación de claves. La hicimos compatible con la que bajamos de javascript y la traducimos a php. Tuvimos que estudiar la matemática del RSA (es simple y hermosa). Tuvimos que estudiar un par de funciones de php que nunca se usan. Hicimos potenciaciones con exponentes de 7 dígitos y colgamos varios servidores. Alejandro y Tito (gracias Y lo vamos a liberar GPL nosotros. ¡E hicimos un plugin para WordPress con nuestro sistema!
Si quieren tanto a su WordPress como yo quiero a mi GridPanel, acá está para bajárselo: La instalación es:
Pueden generar sus propias claves RSA o poner la suya si ya tienen una. Lo único: Internet Explorer no va a poder recordar correctamente la contraseña usando este plugin. Tildando la opción “recordarme” en la pantalla de Login, funciona perfecto. No saben lo que me divertí escribiendo ese plugin Ya dejaron 54 opiniones sobre esta nota:ELSERVER SRL no se responsabiliza por las opiniones vertidas en el presente blog sobre personas físicas o jurídicas, siendo las mismas exclusiva responsabilidad de quien las vierte. Asimismo las opiniones dadas por los usuarios del blog no reflejan necesariamente la opinión de ELSERVER SRL. Trackback URI | Seguir comentarios vía RSS Dejá tu opinión!
|
 |
.
!) tuvieron que actualizar fuera de plan la versión y extensiones de PHP5 en la red interna para que dejaramos de colgarla y en todos los servidores del Panel.
Yo amo mi grid panel y mi wordpress así que ya me descargue el plugin!!
Fer sos groso!! Sabelo!
Clap, clap, clap.
Al margen de lo impresionante del desarrollo (y del post), te felicito por ser el priemro en animarte a postear en el blog (sacándonos a Joel y a mi, que ya los tenemos bastante podridos).
Excelente aporte del señor Via Canel al blog de ElServer. Se me escaparon un par de detalles técnicos del asunto, pero no por fallas en la explicación sino por mi propio desconocimiento.
Esmeradísimo post y una gran función que irá haciendo falta a medida que ElServer siga creciendo y se haga más tentador para los malosos de la Web!!
Gracias por mantenernos seguros, informados y sequitos (?!)
Saludos!
DARO
Sole, Nico, Daro
¡¡¡Muchísimas gracias!!!
Como supondrán, tengo la sonrisa grabada a cincel hoy
Cómo decían ustedes “Tantas horas frente al WordPress no fueron en vano” (y frente a las revistas Geek como “Investigación y Ciencia”).
Para ser honesto, no creo que hubiéramos desarrollado esta funcionalidad en mucho tiempo si no fuera por que la propuesta llegó y fue votada en Ideas a la Carta. Como puse en un post anterior, antes básicamente hacíamos lo que se me daba la gana
Nos encanta también la idea de devolver algo a la comunidad y el plugin para WordPress me parece que es un excelente camino.
El código está abierto por lo que solo resta imaginar que re-implementaciones originales van a surgir.
Fer, buenísima la nota. Como te dije “offline”, un golazo.
Una más: el plugin de wordpress amerita un post aparte con un subject acorde. Escribilo y te hago la prensa.
De nuevo, brillante trabajo Fer.
Fer, como te decimos en la oficina con Dolores “…Noo, ahi va corchete o dejale mas sangria…”
realmente es algo impresionante tu laburo y lo haces excelente!! Felicitaciones de corazón y seguí así.
Saludos!
Terrible post!! Mis felicitaciones al Team de Desarrollo de ELSERVER, especialmente a Fernando por toda la descripcion y desarrollo de la nueva funcionabilidad de encriptacion para el GridPanel.
Esto me recuerda al capitulo que homero comparte un cuarto con los universitarios y jugaban D&D.
Es el punto de vista de alguien que no entiende mucho de programación. Esa imagen tenían que ponerla abajo de la de ISIDORO.
¿Se sienten bien? Creo que generaron un mundo paralelo que sólo ustedes entienden. Bien por ustedes.
Que suerte que haya gente así en el mundo para permitirle a la gente que no es así (en este caso yo) poder armar un asadito por hotmail. Sólo “sacamos” un mail, nos inventamos una contraseña que creemos jodidísima de afanar y agregamos contactos de conocidos que hicieron exactamente lo mismo. Los agregamos en un correo, lo mandamos y voilá! Habemus asadum.
Gracias.
Fer: felicitaciones tanto por la noticia como por el post! No conocía estos dotes de redacción, pero sabé que ahora que mkt se enteró, sufrirás las consecuencias! Vamos a tener que sacarle jugo a eso!!!
Felicitaciones, voy a probar el plugin y que mas decir mas felicitaciones por decidir liberarlo!.
Este metodo me suena poco practico desde el punto de vista del cliente y no se porque =(
Digamos, si es el lado del cliente -el navegador, en terminos simples- el encargado de realizar la des/encriptacion, se deja justamente esa area muy vulnerable a cualquier tipo de ataque o snifeo en el mismo cliente. Es como una aplicacion de escritorio vs aplicaciones web.
La diferencia entre este metodo y el SSL es que el SSL no le importa quien o que sea el cliente siempre y cuando tenga la posibilidad de encriptar o desencriptar elementos (la fuerza del cifrado del navegador). Ante un problema con esto, SSL directmente rechaza el envio o recepcion de datos. Sin mencionar que es, al dia de hoy, que ningun ente (fuera de la NSA), ha logrado romper un encriptado de 128 bits.
Si, son muchos hosts para un SSL por host. PERO, con un login centralizado se solucionaria todo. Puede utilizarse URL cloacking para esconder la verdadera direccion del panel con el SSL mientras que la publica sea http://panel.midominio.com. Personalmente, poco me importa si el panel tiene mi nombre de dominio o no, siempre y cuando mis datos permanezan protegidos “como Dios manda”.
Respecto a la velocidad, es claro a estas alturas que el mito de “SSL es mas lento” es mentira. Esto no agrega ni carga de procesador al servidor e ignora completamente al cliente en lo que refiere a des/encriptacion. Por otro lado, una desencriptacion o encriptacion del lado del servidor cada vez que recibe esta tarea es un consumo sustancial multiplicado por miles. ¿Ahondaron en ese tema?.
Cada cual , quizas, tiene sus ventajas. Pero nada supera a SSL, comercial y mundandamente hablando.
Ger,
Es cierto que se podría hacer un login centralizado. No es una mala idea, de hecho, se comentó en la sección de ideas a la carta referida al tema.
Pero en definitiva, a fines prácticos, lo que logramos es lo mismo: la información sensible viaja encriptada.
Sea por SSL o por esta vía de encriptación, el concepto es idéntico: el cliente es el que se encarga de encriptar la información con una llave pública suministrada por el servidor.
¿Si es más seguro o menos seguro?
Contra: encripta en 64 bits
Pro: es una tecnología no estandarizada
Yo creo que a fines prácticos, está más que bien.
Igualmente, si no te conforma, te propongo que sugieras tu idea del SSL con url cloacking en ideas a la carta. Yo la votaría
Gershu, gracias por el aporte.
Previo al desarrollo hubo un pequeño diálogo en la propuesta sobre el tema, y respecto a encarar un login centralizado o no con SSL.
Vale aclarar que aún en el caso de utilizar encriptación SSL, la encriptación de los datos -también- se hace en el cliente antes de ser enviados al servidor.
Si bien se hace en un nivel más amplio (toda la transacción HTTP) está sujeta casi a los mismos peligros locales que una encriptación por RSA/DES. Un sniffer, por ejemplo, vería datos encriptados tanto con SSL como con esta técnica.
SSL no es lento con los equipos de hoy en día, sin embargo para entornos masivos, sí representa una carga de trabajo importante. Los servidores sí deben realizar des/encriptación de los datos tanto con SSL como con nuestro desarrollo.
Las principales ventajas de SSL son la fuerza del encriptado por la cantidad de bits que utiliza, y la ventaja adicional de certificar, en cierta medida, la identidad del sitio protegido.
En nuestro caso no buscábamos validar la identidad del sitio del GridPanel sino solamente proteger uno solo de los datos transmitidos, sin generar la necesidad de instalar múltiples certificados. Y de paso ya que estábamos, porque no el Plugin para Wordpress que es usado por millones y ahora pueden en 2 pasos y gratis agregar muchísima protección a su sitio!
Saludos!
Se lo que es sentirse satisfecho por Desarrollar algo que ves que tiene sentido para mucha gente, verdaderamente, el sentimiento hasta desborda(se escribe así?), en cuanto al desarrollo muy bueno, cuando lo liberan??, hoy vi un pequeño bug, no se si llamarlo así realmente, veo que en el panel figura En-99 null null Cuota No abonada. cuack!
, No sabia lo del Security Socket Layer. :S
Entendí joya lo del RSA y el DSE, me parece interesante que lo publiques, asi sabemos que tan cifradas están las claves. al margen de que en contexto cualquier keyloggers podrían sabotear del lado del cliente, a esto va que en tema de seguridad nunca pero nuca todo va a ser tan seguro como un cliente lo espera.
Es cierto que SSL hace un intensivo uso de procesador en grandes volumenes, motivo por el cual, por ejemplo, Microsoft en Hotmail solo hace la autenticacion de Passport via HTTPS y luego vuelve a HTTP. Idem GMAIL, pero la URL siempre en SSL es “engañosa” porque todo el sistema es via AJAX (MUY probablemente no seguro).
Justamente al tratarse de contraseñas y accesos es el dato mas sensible de todo. Luego, lo que va y viene, a nadie le sirve porque es informacion poco vital, con exepcion del cambio de pass del panel o el pass de las cuentas de usuarios, que Hotmail, Google, etc. SI mantienen bajo SSL.
Ojo, no digo que su sistema no sea viable, al contrario, creo que por la informacion que se intenta proteger, y el volumen de la misma, el metodo que eligieron es excelente. Solo que le tengo un cariño especial a SSL por varias motivos:
- Tiene (como bien alcaran), una encriptacion de 128 bits y hasta 256 (pueden comprarse certificados de este calibre publicamente a varios emisores con estandar RCA).
- Es sencillo por no decir HIPER sencillo tanto para ustedes, como managers del backend, como para el desarrollador que use una API.
- Al dia de hoy (al menos publicamente), no se tienen noticias de que alguien haya logrado decodificar una encriptacion de 128 bits de un SSL, mientras que DES esta quedando bastante viejito (http://lasecwww.epfl.ch/memo/memo_des.shtml) y es por eso que ya existe un reemplazo (llamado AES).
De todos modos creo, como dije, que para lo que lo van a usar alcanza y sobra. Dudo mucho quen “phraker 1337 Pr0 haxx0r c00l supah” user se ponga a romper semejante clave critpografica para lograr acceso a un panel de shared webshoting xD
¡Abrazos!
Es por eso, queridos clientes que siempre deben cambiar sus claves periodicamente!!!!
De hecho una idea que nos anda dando vueltas esa hacer una implementación de este mismos sistema alrededor de una librería de AJAX, de forma de poder hacer (si se quiere) toda la comunicación encriptada sin usar SSL.
AES es el camino que se debería seguir, aunque más que nada porque es “la alternativa natural”. Si bien puse DES en el mensaje anterior, en realidad utilizamos 3DES que es muchísimo más seguro.
Citando un correo de 2001: 3DES es 2^56 veces más dificil de atacar por fuerza bruta que DES.
Si se usaran PCs 100.000.000 de veces más potentes, y 500.000.000 al mismo tiempo, se podría llegar a romper una clave 3DES en el mismo tiempo que una clave DES normal.
Eso fue hace 6 años, con la velocidad de CPU de hoy en día, calculo que con 100.000.000 de PCs sería suficiente ;P
Para este caso en realidad creo que sería más fácil atacar al RSA para conseguir la clave 3DES directamente. O casi.
Técnicamente sería muy sencillo implementar SSL en el GP, el único problema para nosotros es que queremos brindar el mismo servicio para nuestros clientes como para los clientes de nuestros revendedores, y eso forzaría a varios centros de “login unificado” con SSL, cada uno con su propio certificado, a fin de poder mantener el anonimato del prestador. Esa es principalmente la charla que se armó en Ideas a la Carta. Pero no descarto que en algún momento le encontremos la vuelta! (o vendrá TLS con alguna locura?)
Saludos!
Me gusto el articulo y la implementacion. Me parece bueno eso de “retornar” a la comunidad.
Joel en cuanto a los tiempos que vos planteas, por desgracia no hacen falta tantas pc’s, esas pcs que vos describis son “clones” por asi decirlo, hoy con unos 1000 Niagara2 podes hacerlo tranquilamente.
Y no es una locura, como sabras IBM mueve todo a su nueva plataforma coqueta de clusters :]
Por otro lado, linda la seguridad pero me siguen pasando el usuario, clave y otras cosas en base_64(5 veces encodeado mas o menos) por HTTP (Ver mySQL en el panel).
Lo comente antes en una oportunidad, es dañino para los que sufrimos el rigor de un proxy cache
Con algún proyecto de decoding paralelo similar a lo que era Seti@Home podríamos hacer brute-force colaborativos! La verdad que el tema de la criptografía es apasionante y terriblemente extenso.
Por ahora nos centramos únicamente (para este desarrollo) en la clave maestra de acceso al GP, pero si todo sigue bien vamos a ampliar la técnica al resto de los datos sensibles.
Saludos!
los felicito por el trabajo, funciona perfecto.
Buehhhh!! por fin tengo unos minutos de calma para poder dejar un comentario…
Que vengüenza! Soy quien propuso la implementación y aún no he agradecido…
Hola a todos,
Ante todo _felicitarlos_ y _agradecer_ la alternativa que nos dan de escucha a través de la posibilidad de sugerir ideas… Aunque tiene su lado marketinero, no puedo dejar de reconocer que si las propuestas son buenas (como ya le he comentado a su compañera Daniela B.) nos beneficiamos todos.
Fernando, felicitaciones! por la implementación y por liberar el código bajo GPL Excelente!!. Apropósito, nada impide que puedas recibir alguna donación (a no ser que queden los derechos para la empresa…). Esto, por lo que comenta Joel. Al estar el código bajo GPL, lo importante es que es libre de utilizar/mejorar por quién lo desee… no que sea gratis: El Software Libre se trata de Libertad, no de precio!
Gershu: que pena que no hiciste llegar tus comentarios antes… en el hilo de la propuesta… Si bien ya han respondido al respecto, creo que la pricipal traba radica en el uso por los resellers. Algo que también se podría considerar es usar SSL shared, pero como decía en mi propuesta, Uds están mejor capacitados para evaluar la situación (y eso ha quedado demostrado
Para terminar (veo que se esta haciendo largo), me gustaría “aclarar” algo sobre SSL.
Si bien las entidades certificadoras tienen su negocio extendiendo certificados, hay entidades que los dan gratis… De hecho nada impediría que elserver.com implementara esto como servicio para su red de clientes. Ojo! DTO. de MKT: que no hablo de vender certificados
sino de otorgarlos free. Hoy se dispone ampliamente de la tecnología como para fácilmente hacerlo en estos casos: “La privacidad es un derecho, y no tendríamos que pagar por él”…
No se trata de “identificarnos”, sino de proteger nuestros datos de la vista de 3º… Aunque creo que algo de esto se puede vislumbar en la respuesta de Joel:
“En nuestro caso no buscábamos validar la identidad del sitio del GridPanel sino solamente proteger uno solo de los datos transmitidos, sin generar la necesidad de instalar múltiples certificados…”
Igualmente: muy contento con este avance!! Sigan poniéndole pila/investigando la solución de proteger todo el GP!
Un abrazo,
pd/ saludos Alberto! (compañero del lugro
pd2/ Fernando: por favor, en cuanto tengas tiempo subí el plugin a wordpress.org y lo anunciamos por toda inet!
Ya sumo este plugin a mi la lista de cabecera
Joel se podria montar algo entre los clientes o desarrolladores, me gusta la idea de romper :]
PD: saludos de David de Asis (KeRuBiN).
Encima que programas de diez tambien escribis post que te atrapan!! Felicitaciones Fer.
Muy buena nota!!
WOW.
es un shock.
qué capos son.
Max,
sí, se siente muy bien, muy realizado. En cuanto tenga una forma más genérica (ni aplicada al GP ni al WP) lo subimos al wiki con documentación completita.
Gustavo,
En realidad, el código es “propiedad” de ELSERVER, más allá de que mucha parte de él es descargado y por lo tanto GPL de por sí, lo hicimos acá y para el GP. Pero si tenés ganas de hacer donaciones a la empresa, yo te banco!!
Estamos tramitando subir el plugin a wordpress.org. Creo que en los próximos días estará disponible allí.
SebaZ,
Gracias
!!
Sergio,
Gracias!!!
Andres,
Gracias!!!
Y no me canso de agradecer ^^
Muy bueno chicos
la verdad que los felicito…. Muchas gracias por el plugin de wordpress es muy util en estos dias 
Señores, la verdad que esta es una de las cosas que mas me sorprenden de esta empresa. La capacidad de lograr estas locuras y esta comunicación. Felicitaciones de verdad.
De todas formas, me interesa comentar algo con respecto al SSL. El tema del anonimato o no, es igual que el host del DNS que todos utilizamos, que incluso sale cuando se lista el dominio en nic. Bien se podría montar el SSL sobre ese mismo dominio, que si bien no es anónimo, es genérico. De esta forma se logra que no solo la contraseña de login viaje encriptada, sino también las contraseñas que le seteamos a nuestros clientes, o las que configuramos en nuestras MySQL…
Actualización:
El plugin de WordPress ya está disponible en wordpress.org:
Login Encrypt
Saludos!
Impresionante, me saco el sombrero ante estos códigos generados, hacen que el loggeo sea mucho más seguro.
Todo bien con las modificaciones, pero quiero hacer tareas simples como cambiar cuentas de correo, y el panel se tilda, aparecen paginas en blanco, faltan links.
Prefiero un panel html q haga lo q tiene q hacer
chau
Puse millones de todo tipo como:
Probé con todos… pero los acentos no van. Que es lo que hay que poner para evitar millones de &EACUTE.
Muchas Gracias.
mmm parece que no hagarro el html
Lucas, no te sigo bien a que te referís. Es alguna duda técnica ? Contactanos a Soporte Técnico y con gusto lo vemos.
Saludos!
Estaba pensando, pero un ataque del tipo Man-In-The-Middle no puede desencriptar todo esto?
Alejandro, para poder desencriptar la clave es necesario conocer la clave privada del par RSA, que nunca se envía.
Como protección adicional, además, no es la clave lo que se encripta en RSA, sino la llave de 3DES en lo cual está encriptada la clave en si. La llave, asimismo, se genera en memoria del navegador mediante Javascript.
Saludos!
Una pregunta? el “codigo unico 3DES al azar” ; que supongo que es “clave 3DES generada al azar”, es generada en el cliente?? (o sea no la genera el servidor?; el ultimo post parece dar a entender esto). Bueno, si es asi, les informo que este sistema es suseptible a ataques de “replay”; simplemente snifeo “tu clave encriptada con DES” y “codigo unico encritpado con RSA” (refiriendome al esquema gráfico de arriba y se lo reenvio).
Otra cosa, porque utilizaron RSA y no DH o el Gamal; tengo entendido que no son propietarios y seguro que exiten implementaciones open source en javascript.
Otra cosa mas, otra forma de enviar las credenciales de manera relativamete segura es usar una forma de “one-time passwords”; utilizando funciones hash (pero el server tiene que generar un token unico):
por ej:
1) server->clente: en la ventana de login le envia (en un elemento hiden de una form) un token de la forma: token=”fecha actual”+”numero random”
2)cliente -> server:
calcula lo siguiente:
tokYpas=token + password,
passHiden=sha1(tokYpas); (sha1 es una funcion de hash fuerte; exiten una implemtentacion en javascript aca: http://pajhome.org.uk/crypt/md5/
bajo licencia BSD ). Bueno, el cliente le envia al server el nombre de usuario, el token y passHiden (en ningun momento le envia password plano).
3) el server toma el token enviado y verifica que la fecha dentro de limites razonables (digamos dentro de 3 minutos; esta es una ventana suceptible a ataque de replay y es un tradeoff entre la seguridad y la molestia del usuario a que se logee rapido una vez que entra a pagina de login) y si no lo redirige nuevamente a la pagina de login. Si el token no expiro, a partir del nombre de usuario, busca el password real en una base de datos (o donde quiera); lo concatena con el token, y recalcula el hash (en php simplemente usar la funcion sha1); y si el nuevo hash es igual al hash enviado (el passHiden); todo ok, si no error en logeo.
Bueno, si quieren el codigo fuente de un ejemplito simple pidanmelo al mail y se los envio. Tengo entendido que este sistema era el utilizado por yahoo cuando uno no se logeaba en modo “seguro”. Lo que tiene de bueno es que es muy eficiente, es suceptible a ataques de replay, pero solo dentro de la ventana de tiempo. Lo malo es que no autentica al server (como lo hubiera echo ssl) y es suceptible al ataque de fuerza bruta (la debilidad es proporcional a la debilidad del passwrod real). (en este momento se me estan ocurriendo formas de autnticar al server de manera bastante simple… y nada de ssl, pero eso sera en otro momento). Ta luego.
… Aún recuerdo que en el secundario, el flaco que administraba la red de la escuela, guardaba las contraseñas de todos los usuarios en un papelito dentro de un cajón (que para colmo estaba sin llave).
Recomiendo, para aumentar la seguridad de sus servidores, repartan e-ink a todos los usuarios!.
Artículo Vintage: http://www.newscientist.com/article/dn4602.html
PD: Aún sigo usando para generar claves mi viejo programita en QB con un algoritmo misterioso… simplemente pongo algo que me remita al sitio, por ejemplo, et voilá! ya tengo la contraseña
Saludos!
Hola. Una pregunta… se puede manejar el correo desde afuera del webmail?. Digo por ejemplo, quiero hacer algo en php, que me levante los mails, o agregar contactos desde php, y que despues me aparezcan en el webmail. mm.. era mas facil decir , puedo hacer un webmail con php??. Digo, no estoy pidiendo que me digan como hacerlo en php, solo me gustaria saber de donde saco los datos de mi email para procesarlos con php. Bueno, Muchas Gracias.
luks, si. Podés hacerlo conectándote desde PHP al servicio de POP3 o IMAP, y a través del API del GP podés también realizar ciertas funciones avanzadas como realizar altas de usuarios o cambios de clave.
Saludos!
[...] tenemos nuestro propio WordPress hosteado, la cosa cambia. Una opción fácil y simple es utilizar el plugin que liberó la gente del ElServer.com, el cual encripta de manera segura la contraseña cada vez que es enviada, pero ojo que no encripta [...]
Aunque no soy de ElServer.com, los saludo por el buen laburo que hicieron con el plugin de WordPress, y que lo estoy implementando en mi sitio…
Muy bueno el laburo y muy buena la actitud de liberarlo OpenSource aún para quienes no somos clientes..
Saludos… y sigan asi con las historias como la de la creacion del plugin que son muy dinamicas para leer
Atte: leonardo
Leonardo:
¡Muchas gracias!
Justo estoy trabajando en otro plug-in…
Me alegro de que te resulte útil.
Saludos!
molesto yo de nuevo jeje…. si pueden, combinenlo con el anterior comment…
me quede enamorado del login encrypt en wordpress, que no se si alguien puede transformarlo en plugin para vBulletin…
Gracias
Saludos!!
[...] Y lo bueno, es que la gente de ElServer.com lo ensambló como plug-in de WordPress y lo distribuye OpenSource… Si querés saber más, entra aca. [...]
Me surgio una duda :s
¿Que pasa si tengo desactivado javascript en el navegador?
Ups!
Maxi,
La encriptación no va a funcionar :s
Quién desactiva Javascript en el mundo real? je
Veo un problema. Esta claro que nunca se podrá saber la contraseña si alguien intercepta los datos. Esto es debida a que esta doblemente encriptada, aunque se ha demostrado que DES se puede descifrar.
Pero el objetivo de cifrarlo con DES utilizando una clave aleatoria es que se genere siempre un mensaje distinto.
Pero si alguien intercepta un mensaje con los datos que se le manda siempre podrá entrar con esos datos.
Yo sugiero que de lado servidor se genere una clave aleatoria que se concatenará a la contraseña en el lado cliente y se envié cifrado con RSA. Esta clave generada, por ejemplo, tendrá validez 1 minuto. Una vez llegada la información al lado servidor se descifraría con la clave privada RSA y se verificaría que la clave generada aleatoriamente por el servidor es correcta y esta dentro del limite de tiempo.
En resumen se enviara siempre un mensaje distinto y este debe ser siempre verificado en el servidor.
JavieL estoy de acuerdo, simplemente el sistema es suceptible a ataques de replay; si vez mas a arriba ya lo había planteado en mi post.
El problema con tu posible solucíón es que el server debe “mantener el estado”; esto es, debe recordar cual “numero aleatorio le envio al cliente”. Esto puede o no ser un problema, pero es algo que el sistema que plantean no tiene.
La solución que yo planteo es utilizar la hora del día y la fecha(mas un numero aleatorio que no es verificado, solo es usado para darle un poco mas de “entropia” ); de esta manera se evitan los ataques de replay (dentro de un periodo de tiempo configurable) y no es necesario mantener estado en el server.
Mi solución utiliza hashes, pero la utilización de la hora del día y la fecha parece ser fácilmente aplicable al método dado en esta pagina (podría haber ciertos problemas en ambientes con múltiples proxies/servers; debería tener la hora y fecha sincronizadas dentro de lo razonable).
Bueno, primero quiero decir que esto me parece fantástico a nivel de aplicación para los que no quieren pagar un SSL o hacer la verificación del certificado del mismo.
FELICITACIONES y AGRADECIMIENTOS a todos los que lo hicieron posible!!.
Ahora, a nivel de implementación, esta muy bueno para wordpress, pero creo que seria una herramienta potentisima y muy util en OsCommerce, lo cual es lo que yo ando buscando, y con esta idea voy a intentar desarrollar bajo estos conceptos datos.
Aun asi, me gustaria contar con el asesoramiento y opinion (y algun archivito en lo posible) como para no tener que ponerme a “hachear” todo el codigo de Wordpress y adaptarlo a otra necesidad.
De nuevo, muchas gracias Fernando!! =)
Muy bueno el plugin, hace tiempo buscaba una implementacion de RSA entre javascript y PHP.
Tengo un problema quizas me puedan dar una mano.
Lo tengo andando perfectamente sobre mi servidor local con Windows y WAMP5.
Pero en ninguno de los hostings que tengo sobre linux funciona. Y por lo que pude ver supongo que es un problema con los character sets. Ya que los strings se encriptan OK en el navegador y llegan OK al server, pero cuando el server los desencripta, no obtiene los strings originales, y a cambio obtiene otros caracteres, que comunmente he visto cuando el charset es diferente.
He probado poniendo los headers y las tags meta con utf-8, y con otros, inluso con us-ascii, pero siempre falla.
Ustedes con que charset lo tienen andando ? Lo tienen sobre linux ?
Les agradesco si me dan una mano y felicitaciones por el trabajo.
Saludos
Gabriel Badano
Bueno eoncontre el problema despues de mucho probar y buscar las diferencias entre mi server local en windows y mis hostings.
El problema es la precision de los numeros de punto flotante definida en el php.ini del server. Si la precision es menor de 9, las funciones de desencryptado dan chocolate. En mis hostings estaba en 6.
Asique agregue una linea de codigo antes de llamar a estas funciones para solucionarlo y salio con fritas:
ini_set(”precision”,”9″);
Con respecto a la solucion de seguridad en si, le hice un par de cambios para hacerla mas segura. Ya que como dijeron varios en post anteriores, es facilmente hackeable mediante un ataque de replay, ya que la clave DES se genera en el cliente y la clave RSA privada es siempre la misma.
Asique cambie el codigo de forma que la clave aleaoria DES se genera en el server y se envia al cliente, pero cuando vuelven los datos encriptados desencripta con la clave generada que previamente guardo, no con la que viene del cliente, por si ha sido cambiada.
Y lo mas importante, si bien la clave publica del RSA es siempre la misma, la clave privada y el modulo, son generadas por el servidor en cada request del navegador, de forma que siempre esta cambiando para cada login.
Espero comentarios al respecto. Fernando estas ?
Saludos
Hi,
First, nice work! I like it!
Now, my firefox 3.5.1 (win32) goes crazy when I press “Log in”.
It takes all the memory it can, like double (i have 512mb ram, and last time it used 1gb).
In IE7 It says that the script can make the browser unresponsive and I select to stop running it and the login is just fine. Works.
But in firefox 3.5.1 it’s not so easy. At work, I have 2bg RAM and the firefox is for a few seconds unresponsive the mem usage increases for a few times and in the end asks me to stop or to let the script to continue. I click stop and it logs in.
My question is: How do I debug? Is it a known/accepted problem?
Best regards,
Paul
Por que no usar AES en vez de DES?