El nombre de usuario de dicha cuenta, es uno de los tantos que utilizo en distintos sitios, aunque la clave me parece más bien aleatoria (y la mencionan en el correo que me llega, lo cual me genera un toque más de desconfianza).

Investigué un poco, y me encuentro con que este sitio es un tanto fraudulento… roba (o compra) bases de datos de otros sitios, y luego las utiliza para crear perfiles falsos de usuarios.

Tengan cuidado con este tipo de cosas, ya que el sólo hecho de iniciar una sesión en el sitio ya les da el OK de que tus datos son correos (al menos, el correo). Luego, pueden pasar varias cosas…

• que te pidan cambiar el password, e introduzcas uno que usas en otros servicios (groso error)
• que te pidan actualizar tu perfil, y consigan así más datos sobre vos
• que en las condiciones aceptadas, te comprometas a algo que no puedas cumplir

En fin, simplemente tengan cuidado…

Quizás esta premisa pueda ser cierta en el caso de una gran cantidad de usuarios que normalmente ni se preocupan por lo que tienen en sus máquinas… aunque para nada cierto en el caso de los usuarios de empresas y los que tienen un poco más de idea de informática.

El primer caso, el corporativo, está justificado por el hecho de que normalmente las empresas prefieren delegar este tipo de decisiones al área de seguridad, si la tienen, o de sistemas, en su defecto. Esto se da, más que nada porque las actualizaciones pueden provenir de fuentes seguras… o no (¿o acaso nunca les llegó una presunta actualización de Windows por correo?), y pueden traer mejoras que quizás no cumplan con la política de seguridad de la empresa.

En el segundo caso, el de los usuarios con más conocimientos, es un tanto especial… ya que seguramente querrán tener control sobre todo lo que instalan, y a veces se llega a un borde de paranoia si algo se instaló por sí solo (díganmelo a mí, con mis últimas malas experiencias en Windows unos años atrás).

Ahora sale un nuevo paper que afirma que las actualizaciones silenciosas incrementan la seguridad, enfocándose más que nada en el tema de los navegadores.

La información del paper está buena, aunque nuevamente… no aplica para el total de los casos, ni tampoco para la “gran mayoría”, ya que los usuarios corporativos conforman una gran porción del pastel

Estimado Cliente,

Nosotros hemos determinado eso fue 3 tentativas equivocadas a la entrada en su cuenta bancaria en línea del hostname: 82-76-19-27.rdsnet.ro. Sospechamos que esta tentativa no fue legitimada así, como un meassure de seguridad, nosotros hemos suspendido temporalmente su cuenta. Usted puede reactivar su cuenta, el tiempo que usted desea, verificando sus informaciones personales conectadas a su cuenta bancaria en línea.
Para reactivar su cuenta utiliza por favor el lazo siguiente:

https://www.xxxxxxxxxxx.com/ [borrado, para que no caiga nadie]

Favor de notar:
Su cuenta se quedará suspendió para prevenir el fraude hasta que usted lo reactivará.

Gracias por utilizar servicio de Banca Electrónica.

Me interesaría saber si hay gente que cae en este tipo de cosas, sobretodo con las frases y palabras utilizadas que no tienen coherencia, y que están traducidas de forma literal (lazo = link = enlace; ¿informaciones? != datos; meassure != medida; suspendió != suspendida; etc).

En fin… una pena que no sepan ‘enfocar’ lo que hacen tendrían mejores resultados…

Si alguien recibe esto, y tiene dudas… es FALSO, por lo tanto… no ingresen al enlace en cuestión.

He visto que este problema no tiene una buena solución cuando el usuario ya está registrado, ya que las formas implementadas para exigir que se ‘cambie’ la clave, son un tanto agresivas.
Por un lado, tenemos la petición de renovar la clave cada cierto tiempo. Esto presenta una mejora en seguridad, siempre y cuando el usuario no sea vago/descuidado, ya que supongamos que dicha advertencia le aparece a un usuario de este tipo cuando está apurado… ¿resultado? una clave débil que seguramente será usada para sacar provecho de la cuenta de ese pobre indefenso (esta implementación la he visto en varios sistemas de Home-Banking). También vale mencionar que es bastante molesto, que cada X días, al sistema se le ocurra pedirte que cambies la clave… ¿o no? (fuera de todo aspecto de seguridad… es como si la policía nos exigiera que cambiemos la llave de nuestra casa todos los meses, para evitar robos…).

Por otro lado, tenemos simplemente el aviso de renovar la clave, lo cual suele pasar como “parte” del entorno… ya que nadie lo lee. En este caso, se puede mejorar la idea (lo cual no asegura efectividad), dándole un color (siempre el mismo color, no se me pongan creativos, que luego parece un circo) que resalte al mensaje que estamos intentándole dar al usuario, y que este mensaje solo se muestre en pantalla que no estén involucradas en el medio de una transacción… solo al inicio, o al final de esta. Un ejemplo de como no implementarlo… es poner el aviso de cambio de clave durante un proceso “crítico” -para el usuario-, como efectuar un pago (introduciendo clave, numero de tarjeta, etc). Aunque si podemos implementarlo en las pantallas de menú, o aquellas en donde el usuario esté más tranquilo.

Luego, tenemos los intentos más acertados, los que apuntan a solucionar el problema de raíz (que no están exentos de problemas, aunque minimizan la responsabilidad del administrador del sistema).

Uno de estas formas, es permitir que el usuario elija su contraseña -en el formulario de registro-, lo cual puede convertirse en un serio problema de seguridad para él, si el usuario es vago/descuidado (es el más utilizado).

Otra forma, es sugerir al usuario una contraseña, la cual puede parecer mágica, ya que nosotros como administradores estaremos contentos de que el usuario tendrá una contraseña “fuerte”, aunque visto desde el lado del usuario, puede ser inseguro (¿por qué el sistema me sugiere una clave?), y hasta molesto (¿por qué me eligió una clave tan complicada?).

La tercera forma, es muy similar a la primera, ya que consiste en permitir que el usuario elija su contraseña, la primera vez que va a ser uso del servicio. Como habrán notado en este caso, la petición de contraseña no está dada en el registro mismo, sino en el primer encuentro que el usuario tiene con el sistema.

Esta última forma, se puede implementar de dos maneras… una es otorgando al usuario una clave blanca (es decir, vacía), cosa de que cuando haga su primer conexión al sistema, se encuentre con la petición de poner una clave (lo cual puede ser inseguro, si alguien se entera que tal o cual usuario se registró); mientras que la otra es brindarle un enlace para su primera conexión, de modo que en dicho enlace vaya un parámetro de código -aleatorio- (que deberá ser guardado como un campo más en la tabla de usuarios, para verificar luego que sea el mismo)., cosa que no se presente la falla de seguridad anteriormente mencionada en este párrafo (que alguien pruebe y encuentre un usuario nuevo, tomando posesión de la cuenta de este).

El problema es que no siempre podremos brindarle un enlace a un usuario para su primera conexión, dado que el sitio puede estar protegido por .htaccess y la generación de clave “en manos” del usuario es un tanto compleja (dado que el usuario aún no tiene clave, debería ingresar por medio de una página que está fuera de la protección del htaccess, haciendo débil esa parte del sistema); o bien que el sitio se encuentra en una Intranet, por lo que ingresando en el enlace desde fuera de la misma, caemos en la nada. Para estos casos, las otras medidas deberían ser tomadas en cuenta, intentando identificar al usuario medio… ya que si este suele ser vago, entonces deberemos evitar todo intento de complicarle su vida (digamos, que tenga que pensar demasiado).

Para ir cerrando, a modo de prueba, en un sistema basado en Joomla, se modificó el código de cambiar contraseña, para que guarde en un archivo de ‘log’ cuantos cambio ha habido. En un año, y con más de 190 usuarios, solo se cambió una clave… (¿más triste? fue la mía, de Administrador… para probar si funcionaba el log).

Lamentablemente, si queremos velar por la seguridad de nuestros usuarios, debemos enseñarles los problemas que trae la (in)seguridad, o bien, buscar formas de hacerles vivir en un paraíso donde la seguridad misma reine por si sola

Lo normal hubiese sido avisarle que podía haber sido víctima de una trampa, pero mi cerebro se puso a pensar en como solucionar el problema… lamentablemente (cuando una idea se me mete en la cabeza, esta difícil que salga… y encima dicen que soy cabezón, así que peor jejej).

Actualmente, estos servicios gratuitos de correo (Hotmail, Yahoo! Mail, GMail, etc), implementan APIs (no todos) que permiten a otros sitios hacer uso de tu lista de contactos, para que puedas invitar “fácilmente” a otros usuarios.

El problema está, en que tenemos que ingresar un usuario y clave, y eso puede o no ser capturado por el sitio que está tratando de hacer la invitación. En el mejor caso, no pasará nada, pero en el peor… podemos llegar a ser víctimas de una trampa, y terminar perdiendo nuestros correos o directamente nuestra cuenta (si cambian la clave o solicitan su eliminación).

Acá tiene tanto culpa el usuario, como la empresa que está de cada uno de esos servicios, ya que el primero es suficientemente “tonto” para caer en la trampa, y las segundas son suficientemente “vagas” como para implementar una solución “segura”.

Todas las soluciones que me pasan por la cabeza, son un tanto incómodas para el usuario, pero si analizamos la incomodidad de copiar y pegar cada contacto, en relación a una “mediana” incomodidad, pasamos al frente.

Veamos algunos ejemplos:

• Al momento de completar los datos en el sitio X sobre nuestra cuenta, solo debería pedirnos el “usuario”. Una vez que envíamos dicho dato, el sistema nos debería avisar que tenemos que abrir nuestra casilla de correo para confirmar la solicitud. Por lo que una vez que ingresamos con nuestro usuario y clave al “sitio de la casilla de correo” (o sea, no a un sitio de terceros posiblemente inseguro), este nos avisaría de que tenemos una solicitud del “sitio X” que está necesitando acceso a “nuestros contactos” o “nuestro calendario” (o lo que sea). De esta forma, una vez que aceptamos… el sitio recibe la autorización (que tendría una vigencia temporal de N minutos), y luego se revoca dicho permiso para que no pueda hacer uso más de nuestros datos.
• Otra forma, sería que al momento de ingresar a nuestra casilla de correo, podamos activar temporalmente el uso de, ya sea, nuestros contactos, calendario, etc… pero ingresando una clave de al menos N dígitos generada por el sistema. De este modo, al ir al “sitio X”, este nos solicitaría nuestro usuario y dicha clave generada, evitando así que este reciba datos sobre nuestra clave real del usuario. El acceso, nuevamente, sería temporal… y limitado a los datos que permitimos en nuestro correo.

Aplicando alguno de estos simples métodos, eliminaríamos gran parte de las trampas que existen en la web, y que permiten el robo de cuentas de correo fácilmente (con las consecuencias que eso puede traer).

En este caso, como dije anteriormente, debemos tener en cuenta de que estamos dejando de lado un poco el aspecto de facilidad, para hacer hincapié en la seguridad.

En fin, tenía que dejarlo escrito… es algo que no puedo implementar por mi cuenta, por lo que no me molestaría que una empresa lo ponga en vigencia… siempre y cuando sea para el bien de todos.

De grande, me di cuenta que ocultando información, en realidad estoy mintiendo, ya que no estoy diciendo lo que sé. No se si es tan malo como dar información falsa (mentira), aunque tiene su daño aparejado.

Un ejemplo que se me viene a la cabeza para que se entienda mejor, es poner a un grupo de 10 personas que están a punto de subirse a un avión para hacer unas pruebas.

Si al grupo lo dividimos en dos partes (A y B), y a una de estas partes (A) les decimos que el avión se va a estrellar, es poco probable que esta parte del grupo se suba al avión (a menos que quieran tentar la suerte, o no crean nada de lo que les decimos).

En este caso, estamos ocultándole información al grupo B, que si bien verá con desconfianza el hecho de que el grupo A no se suba al avión, seguirá bajo las reglas iniciales que les habíamos mencionado… que eran “subirse al avión para hacer unas pruebas”.

Si en cambio, al grupo B le dijésemos que el vuelo del avión va a salir lo más bien (mentira, porque ya sabemos que le sucederá), entonces el resultado sería el mismo.

La desinformación o la mentira, entonces, pasan a tener un peso muy similar ante un grupo de personas de iguales condiciones (en una situación dada), dado que ambas producen efectos similares (en este caso, que pasen de largo todos los del grupo B).

Por tanto, si en algún momento piensan que dejar pasar “un dato” es bueno para su entorno… piénsenlo dos veces, quizás estén metiendo en problemas al grupo afectado… sin intención.

Nota: Si, está relacionado con la entrada anterior…

Si no entienden inglés… bueno, que quieren que les diga

El RFID es útil… pero no para cualquier caso… y menos cuando algunos de estos casos involucran que podamos perder nuestra identidad o ser víctimas de un robo ‘virtual’…

[Nota: Léase membresía como el usuario que paga por tener acceso a contenido, no se si estará bien dicho... pero con esa palabra lo manejan varios]

Tiene un sitio con contenido de alto voltaje, por lo que si bien sus miembros pagan muy bien… también la tasa de “piratería” del contenido es altísima… lo que termina regulando la balanza para que no te llenes de plata… (y en algunos casos, te quedes debiendo dinero al servidor, porque te excediste en tráfico).

El asunto pasa porque me comentó que tenía X cantidad de miembros registrados (pagando), y estos consumían alrededor de 50MB de tráfico diario cada uno en promedio, lo cual es altísimo si consideramos que no todos visitarán el sitio todos los días…

Tras analizar sus estadísticas de conexiones, me encuentro que un mismo usuario tenía conexiones desde Rusia, Japón, Estados Unidos, Argentina, Paraguay, etc… lo que me llevó a pensar:

• tiene una máquina de teletransportación y no nos dijo nada…
• ha compartido su usuario y clave con otras personas
• le han robado los datos

Ante la ridiculez de la primera premisa, y al no poder desconfiar del miembro, pasamos a activar el switch de clave… el cual consiste básicamente en resetear la clave, de modo que en la próxima conexión, deba insertar una nueva clave, seguida de la clave que usaba hasta ese momento.

La situación llevó a que en menos de 48 horas, el usuario nos estuviese contactando por “problemas de acceso a su cuenta”.

En la respuesta, le comentamos de la cantidad de conexiones que actualmente tenía esa cuenta… y le envíamos un enlace para resetear la clave por medio del correo (lo cual hace que si o sí la persona que hace el cambio, sea la dueña de la cuenta).

Santo remedio, las conexiones de dicho usuario bajaron a un nivel normal… pero nos quedaba el resto… ya que el tráfico de otros usuarios seguía siendo notable (en este caso, habíamos tomado solo al líder en consumo… pero había otros casos para destacar).

Aplicamos la misma idea para otros tres miembros, logrando el mismo resultado.

Al no poder desconfiar de los miembros (aunque ninguno de estos respondió al correo cuando se les sugirió de que otras personas usaban la cuenta, lo que nos deja un margen de sospecha), pasamos a implementar un medio más duro de cara a los miembros… previo aviso por correo… donde ahora les permitimos comprar servicios adicionales (no pregunten jeje) con los datos (de su tarjeta) ingresados en su momento al registrarse, sin mediación de clave (anteriormente se comenzaba el pedido, el usuario lo aceptaba por correo y luego se hacía efectiva la compra).

El nuevo sistema, entonces… permite que cualquiera que tenga acceso a la cuenta, compre servicios adicionales… lo cual ha producido una caída “notable” de tráfico en general, ya que hemos hallado el talón de aquiles de la situación…

Si el usuario paga por una cuenta, y la comparte… es muy probable que sus datos terminen en manos de alguien que no confía, por lo que se pone en riesgo a sí mismo, al poder terminar pagando por servicios que otro contrató. En el caso de que la cuenta de un usuario sea robada, este tendrá que comenzar a cuidar más sus aspectos personales… y en todo caso, terminar quejándose a su empresa de crédito.

La solución es un poco drástica, pero ha dado resultado… y aquellos usuarios que no llevaban a cabo acciones que rompían las reglas de membresía, no han sido afectados para nada.

En todo caso… solo quería compartir una solución que me pareció intresante, por si tienen algún sitio que tenga un problema similar…

[Nota: si son usuarios de dicho sitio (ya que les llegó un correo con aviso), no se las agarren conmigo... ya que a mi me consultan por soluciones en vista de los interéses del cliente...]

En algunas páginas antes de la misma entrada, el autor asegura no tener ninguna relación con dicha empresa… pero… conoce como funciona el sistema por dentro (ya que es cerrado) o cree en lo que un mensaje dice en pantalla (y eso si que es ser iluso).

Hasta que el producto no sea abierto, es difícil que alguien pueda garantizar que no envía información privada… incluso cuando se analizan los datos enviados… ya que tranquilamente se pueden enviar datos cifrados que nadie entendería.

Es como meter la mano dentro de una caja negra -llena de vidrios-, y esperar que cuando saquemos la mano, esta esté intacta…

En fin…

Muchas veces cuando veo como la gente actúa con alarmismo ante algunos problemas, me supone pensar que esas personas no analizan que pasaría si el problema nunca hubiese sido reportado.

El caso más cercano que conozco, es el de la vulnerabilidad en la creación de llaves seguras, de hace algunos meses atrás (en Debian, creo), que llevó a muchos a hablar de inseguridad y hacerlo de forma -bien amarilla-. Ahora bien, el problema se encontró y se solucionó… del mismo modo que cuando me avisaban que tenía el cierre abierto, me fijaba… lo subía y listo.

El tema es cuando nadie te avisa que tenés el cierre abierto… sea porque nadie te quiere y desean que pases vergüenza, nadie se anima porque podés llegar a tomarlo para mal, o bien porque nadie se fija en vos.

Esta situación, llevada a la realidad me permite decir que aquellos que se alarman y están con otros panatalones puestos… seguramente sufren del “nadie te avisa”.

El primer caso, cuando nadie te avisa para que pases vergüenza, podemos verlo como una forma de sacar provecho de una persona. Si cambiamos a esa persona, por una organización que tiene un software (cerrado) con vulnerabilidades, nos encontramos que el provecho puede ser más que una simple risa… puede significar desde una extorsión a la misma por revelarle la falla, hasta un simple compra-venta a quien más ponga para revelarle la falla (lo que sería similar a chusmearle a otro que tenés el cierre abierto).

En el segundo caso, cuando nadie se anima a decirtelo, es porque tu historial de reacciones quizás no sea tan bueno (sos un calentón, tomás todo para mal, etc). Esto, llevándolo a una empresa (nuevamente, de SW y código cerrado) podría ser en cambio por la típica de querer meter juicio a todo aquel que reporta un error… algo que normalmente es mal visto por la comunidad de seguridad, y que lleva a que estos ‘investigadores en Infsec’ nunca reporten sus hallazgos… extendiendo la vida de una vulnerabilidad, hasta que alguien de la empresa encuentre el error… o que la misma cambie su actitud ante esta comunidad.

El tercer caso, es tan bueno como malo… ya que si nadie se fija en vos, entonces por más que tengas el cierre abierto, nadie lo va a notar. Aunque… vale mencionar, que este caso es hipotético, ya que si alguien se puede reir de vos… seguramente lo hará. Viéndolo desde una perspectiva de empresa, esto significaría un producto que no logró aceptación por parte del mercado… y que posiblemente siga con errores hasta que realmente -alguien le de bola-. Es malo porque nadie usa tu producto, pero es bueno porque nadie explota los errores (dado que el objetivo potencial es demasiado reducido como para ser rentable al investigador de seguridad).

En fin, la idea general…. si un error pasa X años y alguien lo encuentra (y soluciona), produce mejores resultados que un error que pasa inadvertido y/o que alguien lo encuentra pero nunca soluciona (porque nadie te quiere, todos te temen, o nadie te conoce… como dije anteriormente).

En otras palabras, la diferencia entre las vulnerabilidades del software cerrado y abierto, es que este último no tendrá personas que teman… y el público que “no te quiera” seguramente será una mínima proporción del público que te banque. En el peor caso, si nadie te conoce… difícilmente el proyecto siga en pie por mucho tiempo… ya que no tendrá comunidad, y sin comunidad… un proyecto de código abierto, no existe.

Nota: ahora miren para abajo… y revisen si su cierre está abierto… no vaya a ser que…