Archivos Mensuales: abril 2014

Google compró Android por 50 millones de dólares, Samsung lo rechazó

Google compró Android por 50 millones de dólares, Samsung lo rechazó

 

Imagen

 

Mirar al pasado siempre nos trae noticias curiosas, sobre todo al comprobar el éxito que tienen a día de hoy productos que años atrás eran considerados como rarezas, cosas propias de geekes o, simple y llanamente, locuras sin futuro.

En este sentido hoy destacamos un momento muy importante, aquel en el que Google compró Android allá por 2005, un momento que cambió por completo la historia del sector smartphone y también la historia de Google, todo por “apenas 50 millones de dólares”.

Como sabrá más de uno de nuestros lectores Android fue concebido inicialmente para funcionar como sistema operativo de cámaras digitales, pero no tardó en saltar al sector smartphone.

A pesar del cambio Andy Rubin, co-fundador de Android, se quedó sin fondos para seguir desarrollando su proyecto, así que decidió negociar con Samsung para obtener recursos.

Los ejecutivos de Samsung no lo tomaron en serio, así que Rubin tuvo una reunión con Larry Page, co-creador de Google, y voilá, lo convenció por completo, hasta tal punto que quiso comprar Android de inmediato.

La operación de compra se cerró, como anticipamos, por 50 millones de dólares mas incentivos, una cifra que a día de hoy suena totalmente a ganga, sobre todo si tenemos en cuenta que Android está instalado en el 80% de los dispositivos móviles del mundo.

Sí, a mi también me gustaría saber qué pasó por la cabeza de los ejecutivos de Samsung que rechazaron a Rubin cuando se produjo el “boom” de Android, pero ya se sabe, en el fondo estas cosas son difíciles de preveer.

Anuncios

Samsung Smart Bulbs, las nuevas bombillas inteligentes para casa

Samsung Smart Bulbs, las nuevas bombillas inteligentes para casa

 

ImagenImagen

 

Hace solamente unos días, la compañía surcoreana LG presentaba en sociedad unas bombillas inteligentes denominadas como LG Smart Bulb. Nada más conocerse este anuncio, parece ser que la competencia surcoreana de este fabricante se puso manos a la obra para presentar también sus propias bombillas inteligentes. Y aquí las tenemos: reciben el nombre de Samsung Smart Bulbs, y pertenecen al fabricante Samsung, cuya sede central está ubicada en Corea del Sur. Dejando a un lado los pequeños detalles, estamos ante una bombillas muy similares a las de LG, ya que la intensidad de la iluminación también se controla mediante el teléfono móvil o la tableta.

Las Samsung Smart Bulbs presentan un aspecto convencional en comparación a las bombillas tradicionales, pero es en su interior donde realmente encontramos la “magia” de esta nueva moda de las bombillas inteligentes. A pesar de que estas bombillas se colocan en el mismo orificio que el que podemos encontrar en cualquier lámpara o pared tradicional, el control de la iluminación se realiza directamente a través de una aplicación del sistema operativo Android. Y es este detalle el que hace que nos podamos permitir utilizar la denominación de “inteligentes” a la hora de referirnos a estas bombillas. Mediante la aplicación podemos no solamente regular la iluminación, sino que también podemos programar las bombillas para que se enciendan a una determinada hora del día o incluso encenderlas estando a cientos de kilómetros de nuestra casa (para evitar a los amigos de lo ajeno, por ejemplo).

Samsung no ha facilitado mucha información en relación a este producto más allá de que el usuario tendrá la posibilidad de controlar hasta 64 bombillas desde el móvil, y cada bombilla tendrá una vida útil de aproximadamente 15,000 horas (o 10 años). Datos tales como el precio o la fecha de lanzamiento de estas bombillas son, por ahora, un misterio.

Lo que sí podemos concluir viendo las presentaciones de las bombillas inteligentes de LG y de Samsung es que todo apunta a que finalmente los grandes fabricantes han vuelto a mostrar su interés por la domótica. Dado que hoy en día cualquier usuario tiene un acceso a un teléfono inteligente o una tableta con el sistema operativo Android, los fabricantes tienen la oportunidad perfecta de aprovechar esta presencia de los terminales móviles para integrar el funcionamiento del hogar directamente en el terminal.

Aún así, antes de celebrar el interés de las grandes compañías por el mundo de la domótica debemos esperar a conocer el precio de estas bombillas inteligentes. En el caso de LG, se comenta que el precio de cada Smart Bulb podría ser de aproximadamente 30 euros, lo que resulta bastante razonable teniendo en cuenta la comodidad que supone poder manejar desde el móvil toda la iluminación de un hogar o de una oficina. Si además estas bombillas consiguen ofrecer un consumo de electricidad moderado, probablemente consigan asentarse en el mercado con relativa facilidad.

Descubierta una vulnerabilidad que afecta a todas las versiones de Internet Explorer

Descubierta una vulnerabilidad que afecta a todas las versiones de Internet Explorer

 

Imagen

 

La empresa de seguridad FireEye ha descubierto recientemente una vulnerabilidad en Internet Explorer que da vía libre a ataques “zero-day” (ataques que se producen en cuanto dicha vulnerabilidad es descubierta) al navegador. Afecta a todas las versiones del susodicho desde la 6 a la 11, aunque apunta concretamente a las versiones 9, 10 y 11.

Todos los usuarios que estén ejecutando un Windows que no sea de la gama Server están afectados, por lo tanto es muy probable que lo estés si estás leyendo este artículo desde Windows. El ataque, concretamente, se beneficia de un archivo SWF (Flash) para manipular la memoria que utiliza el navegador. Eso también significa que no estaremos expuestos si no tenemos Flash instalado, aunque Internet Explorer 10 y 11 lo llevan por defecto.

FireEye ya ha informado a Microsoft del problema, y en Redmond lo están investigando para encontrar una solución. No sabemos cómo y cuándo se va a resolver, pero tratándose de un error así no creo que tardemos mucho en recibir una respuesta oficial. De momento ya han hecho gestos más estrictos aumentando las barreras contra el adware.

 

 

Normas de Etiqueta en Internet

 

Normas de Etiqueta en Internet

 

Imagen,

 

Cuando nos comunicamos con otra persona frente a frente o por teléfono, utilizamos gestos, expresiones y/o modulaciones de la voz que ayudan a nuestro interlocutor a interpretar nuestro mensaje. Esas importantes ayudas audio-visuales de la comunicación no están presentes en la comunicación escrita por lo que es más difícil transmitir ciertas ideas, conceptos o sentimientos.

La Netiquette es una serie de reglas de etiqueta que todos debemos conocer y seguir al comunicarnos a través de la red para una comunicación más efectiva y un mejor uso de los recursos y el tiempo. Debido a las características particulares del medio, es necesario utilizar algunos convencionalismos que ya se han establecido para poder comunicarnos efectivamente y evitar malos entendidos, ofender o ser ofendidos, así como un sinnúmero de otras cosas negativas que pueden surgir al no conocerlos.

Además del sentido común, los buenos modales, la cortesía, el respeto, la consideración y la tolerancia, estas son algunas reglas que debemos todos observar al comunicarnos a través de la Red:

1. Tenga siempre en mente que al otro lado de su pantalla hay un ser humano real, con sus propias ideas y sentimientos. Siempre escriba como si ambos se estuvieran mirando a los ojos. Nunca escriba nada que no le diría frente a frente a otra persona. Esta es tal vez la principal regla que deba tener presente siempre.

2. Mensajes enviados a listas de distribución de correo-e serán recibidos por todos los miembros. Mantenga sus MENSAJES PERSONALES a otros miembros EN PRIVADO y envíe a la lista solo aquellos mensajes que desee compartir y sean de interés para todos.

3. Mantenga sus comunicados breves y al grano.

4. No envíe a la lista anexos (attachments) largos (como archivos gráficos). De así hacerlo, se corre el riesgo de que los mismos no lleguen a su destino. El procedimiento correcto es colocarlos en algún lugar en la red y enviar el URL a la lista para que los interesados puedan accesarlos o describa el documento en la lista indicando que, a solicitud, puede ser enviado en forma directa a los interesados.

5. Al contestar algún mensaje, deje alguna cita para que se sepa a qué se está refiriendo usted, pero, por favor, recorte todo lo demás. Siempre que sea posible conteste al principio y deje la cita al final.

6. Utilice el “Asunto” (“Subject Line”) correctamente, cambiándolo cuando esté contestando algún mensaje cuyo tema ya no es el original.

7. Conozca y utilice las caritas de expresión para ayudar a transmitir algunos sentimientos, particularmente si está utilizando humor o sarcasmo.

8. Nunca conteste un e-mail cuando esté enojado o molesto.

9. Respete las leyes sobre Derechos Reservados.

10. Sea cuidadoso con información personal o privada. No publique a la lista datos de terceros (ej. dirección o número de teléfono).

11. Nunca cite en público correos-e que le fueron enviados en privado.

12. Cerciórese de que esté enviando su correo-e al destinatario correcto cotejando el encasillado de “Enviar a:” (“Mail to”) de su programa de correos ANTES de oprimir el botón de “Enviar” (“Send”)

13. Las letras MAYÚSCULAS se pueden usar para sustituir acentos o para enfatizar, pero NO escriba todo en mayúsculas pues esto se interpreta en la red como que ¡USTED ESTÁ GRITANDO!

Aquí se agrega muy bien. los holaaaaaaaaaaaaaaaaaaaaaaaaaa, estassssssssssssssssssssss, son mega gritos.

14. No utilice la lista para promocionar ni adelantar causas religiosas, filosóficas, políticas, comerciales o para promover su propio sitio web (website).

15. Sea tolerante. Recuerde que el botón de “Borrar” (“Delete”) le permite borrar e ignorar cualquier mensaje indeseado.

16. De sentirse usted ofendido por algo o alguien en la lista dirija sus quejas en privado al ofensor y/o al administrador de la lista.
Alabanzas y felicitaciones en público, criticas y desacuerdos en privado.
Traer asuntos negativos a la lista, en general no resolverá nada y propiciará un clima de debate estéril.

17. Si recibe usted un mensaje de aviso sobre un virus que se contagia por correo-el o algo similar, NO escriba a la lista para alertar a todos los miembros sobre esto. Lo más seguro se trata de uno de tantos “Hoaxes” (falsas alarmas) que abundan en la red. Notifique sólo a los Administradores y ellos investigarán. De ser necesario, ellos pasarán su aviso a la lista.

18. No es aceptable el uso de vocabulario obsceno o “picante” en los comunicados a la lista. Sin embargo, por consenso general se permite el uso de palabras “fuertes” en chistes, siempre y cuando el “Tema” (“Subject”;) especifique claramente que se trata de un Chiste y en el texto se haga una advertencia y se deje un espacio razonable (varias líneas en blanco) que le permitan borrarlo antes de leerlo a personas sensibles a este tipo de vocabulario.

19. Cuando uno ingresa a una nueva cultura (y el ciberespacio tiene su propia cultura) es susceptible de cometer algunos errores sociales. Quizás se pueda ofender a personas sin querer hacerlo, o tal vez pueda malinterpretarse lo que otros dicen tomando represalias cuando no fue lo que se quiso decir. Para empeorar las cosas, a alguien en el ciberespacio le puede ser muy fácil olvidar que está interactuando con otras personas “reales”, no sólo con caracteres en una pantalla, sino “caracteres”; humanos.

20. Todo el mundo fue un novato (newbie) alguna vez, muchos de ellos no tuvieron la oportunidad de leer el Netiquette. Por lo tanto, cuando alguien cometa algún error sea bondadoso con él. Quizás si el error es mínimo no sea necesario mencionar nada, siempre piense dos veces antes de reaccionar. Tener buenos modales no nos da derecho a corregir a los demás. Si se decide informar a alguien de algún tipo de error, hágalo cortésmente y si es posible enviando un e-mail privado en lugar de hacerlo público enviándolo a la lista o grupo de discusión. Dé a la gente el beneficio de la duda, asuma que el otro no sabía algo mejor y por sobre todas las cosas no sea arrogante.

21. Los anteriores lineamientos aplican igualmente a Foros, correo-e, listas de distribución de correo electrónico, salones de charla (chat rooms), Libros de Invitados y en general a todos los servicios que el Internet nos brinda.

La falla de seguridad informática de OpenSSL

openssl-logo

 

Heartbleed. Habrás visto esta palabra en los días pasados. Se trata de una falla de seguridad informática potencialmente catastrófica de OpenSSL, una de las implementaciones del protocolo que garantiza conexiones seguras; por ejemplo, cuando hacés home banking o comprás algo online. Afectó a más o menos un 17% de los sitios Web que ofrecen conexiones HTTPS y a muchos programas que requieren cifrado; por ejemplo, las redes privadas virtuales (o VPN). Se originó en un error de programación, un error simple y accidental que está a años luz de las psicodélicas teorías conspirativas que oí estos días, pero que podría haberse evitado.

Todo lo anterior es verdad. Pero sólo una parte de la verdad, que se usó para estigmatizar a OpenSSL y al software de código abierto en general. Antes de entrar en los detalles técnicos, me gustaría mostrar la otra cara de esta cuestión.
DEMASIADAS LÍNEAS

OpenSSL es un proyecto de código fuente abierto que se distribuye sin cargo y depende de donaciones para funcionar. Es usado por centenares de miles de sitios, incluidos los de algunas de las compañías más poderosas del planeta. No obstante, el equipo permanente de OpenSSL está compuesto por (sentate, de ser posible) 4 voluntarios, tres ingleses y dos alemanes, más 11 desarrolladores. Robin Seggelmann, un colaborador asiduo que había “corregido docenas de errores en OpenSSL”, según me contó uno de mis entrevistados, incorporó, en la víspera del año nuevo de 2011, el error que ahora llamamos Heartbleed. ¿Lo hizo adrede?

De ningún modo. Errores como el Heartbleed se producen todo el tiempo en programación. Fue uno de esos deslices que cualquiera de nosotros comete muchas veces en la vida, de posibles consecuencias catastróficas, pero de factura grosera. Basta ver el código donde reside la falla para descubrir que si Seggelmann hubiera querido hacer daño, hubiera introducido algo mucho más sutil.

Lo que ocurrió es que nadie vio el error. ¿Por qué? Porque el software de OpenSSL tiene unas 430.000 líneas de código. Líneas que no están en español o en inglés, sino en C, un lenguaje de programación cuya lectura es mucho menos intuitiva que la de los idiomas naturales. Una coma mal puesta puede hacer que todo ande mal

Así que lejos de acusar al equipo de OpenSSL deberíamos asombrarnos de que no haya ocurrido algo así antes. Por su parte, las compañías que usan OpenSSL con fines comerciales se harían un favor donando dinero al proyecto. Sería mucho más económico que lo que podría haberles costado el Heartbleed.

Es más, la depuración del código de OpenSSL suele recaer en los miembros principales. Son sólo cuatro, como dije, así que cada uno debería revisar más de 100.000 líneas de código. Si acaso -y la comparación es caprichosa, pero no disparatada- una línea de código equivaliese a una línea en una página de un libro, estamos hablando de repasar 6 millones de caracteres. El equivalente a 2 Biblias completas. Cada uno.

Sí, por supuesto, existen herramientas para verificar de forma automática la presencia fallas como el Heartbleed. ¿Por qué no usaron algo así? Posiblemente porque Seggelmann escogió un pésimo momento para enviar su código: las 8 de la noche del 31 de diciembre de 2011. Ser pocos no sólo significa mucho trabajo para cada uno, sino también que muchas decisiones se toman sin supervisión. Ésta fue una de ésas.

Por añadidura, como señala John Levine en su artículo para CircleID, escribir y depurar software de cifrado es mucho más arduo que hacerlo con programas convencionales. En una aplicación convencional sólo hay que verificar que haga lo que debe hacer y que reaccione de manera controlada ante los errores humanos más comunes (por ejemplo, que pongas letras en un campo que alimenta una variable numérica). En el peor de los casos, una falla hará que el programa se cuelgue.

Con el software criptográfico hay que probar que haga bien su tarea y, además, corroborar que todos los posibles escenarios anómalos no revelen lo que se intenta cifrar.

Una cosa más. El Heartbleed no sólo es un error muy grave, sino también muy insidioso: explotarlo no deja rastros (o son muy sutiles e indirectos). Pero entre que se lo detectó, salió el parche y se corrigieron los sistemas más relevantes pasó poco más de una semana. Es un récord, pero un récord al que el open source está habituado. Nadie dijo nunca que el código fuente abierto previniera los errores, sino que los corrige a una velocidad que el código cerrado sólo puede soñar.
¿QUÉ ES EL HEARTBLEED?

Cuando te conectás al banco o a un sitio de comercio electrónico o entrás en Facebook, Twitter o Gmail, la dirección Web cambia del HTTP normal a HTTPS. La S es por secure, seguro en inglés. Esto significa que se ha puesto en marcha un protocolo llamado TLS (cuyo antecesor se llamaba SSL; de allí OpenSSL), que cifrará el tráfico de datos entre tu dispositivo y el servicio Web. TLS viene de Transport Layer Security y OpenSSL es una de las varias implementaciones que existen de este protocolo. Es también la más popular, y por un motivo muy sencillo: es gratis, incluso para fines comerciales.

Si tu máquina y el servidor Web pasan un rato largo sin intercambiar datos, la sesión segura caduca. Para evitar esta clase de situaciones, Michael Glenn Williams propuso hace dos años la extensión conocida como Heartbeat (latido, en inglés), mediante la RFC 6520.

Heartbeat hace algo conceptualmente muy sencillo: durante la sesión envía regularmente pequeños paquetes de datos al servidor seguro, que responde con los mismos paquetes. De este modo ambas partes mantienen abierta la sesión. Adicionalmente, Heartbeat informa al servidor el tamaño del paquete que le está enviando. Por ejemplo, 8 bytes (8 caracteres).

¿Dónde estuvo el error? Las versiones 1.0.1 a 1.0.1f de OpenSSL no verificaban que se informara correctamente el tamaño del paquete enviado. Así, un atacante podría enviar un paquete de 8 bytes pero informar un tamaño de hasta 65.536 bytes (un entero de 16 bits). La respuesta del servidor contendría, entonces, no sólo los 8 bytes enviados por el atacante, sino otros 65.528. ¿De dónde saldrían esos caracteres adicionales que el servidor, engañado, envía como respuesta? De lo que está en ese momento en la memoria del programa. Como es una sesión segura, es probable es que allí se encuentren contraseñas y claves criptográficas. Digo es probable porque el fragmento de memoria es copiado al azar.

Ya saben lo que se puede hacer con las contraseñas. Bueno, lo de las claves criptográficas es mucho más serio, porque si capturaste tráfico de un sitio, podés decodificarlo con esas claves. Llegado el caso, también pueden secuestrarse sesiones activas en una VPN. Ayer se supo que habían conseguido quebrar la doble autenticación y el control antifraude de una VPN por medio del Heartbleed, según la compañía de seguridad Mandiant.
“EL AUTOR RECIBIÓ MAILS HOSTILES”

Hablé esta semana con Michael Williams, que propuso originalmente la extensión Heartbeat, sobre cuya historia me dijo: “Originalmente se llamaba d-mobi y era una modificación de DTLS (Datagram Transport Layer Security). Su función es permitir movilidad punto a punto basada en una identidad segura, en lugar de basarse en una dirección IP. Esto se hizo para ayudar en la transición de celulares a computadoras móviles, eliminando el problema de pasar de un operador a otro, cambiar de Wi-Fi a datos celulares, etcétera. Heartbeat permite que la conexión se mantenga abierta punto a punto incluso si no ha habido datos fluyendo durante un tiempo”.

Respecto del error, Williams me dijo: “Uno de los coautores de Heartbeat [Robin Seggelmann] le dio su código [el que contenía el error] a un voluntario muy senior de OpenSSL. Pero esto ocurrió en unos días muy complicados, justo en las vísperas de año nuevo, y el código fue chequeado sin usar las herramientas que prueban si existe esta clase de errores triviales, errores que ocurren todo el tiempo”.

También intenté hablar con Robin Seggelmann, pero por toda respuesta llegó un cordial mensaje de Alexia Sailer, encargada de comunicaciones corporativas de Telecom de Alemania, donde ahora trabaja Seggelmann, diciéndome que debido a la cantidad de solicitudes ya no podía dar más reportajes. Antes de eso, Seggelmann había hablado con The Guardian y con The Sidney Morning Herald.

Williams reconoció, además, que Seggelmann había recibido una cantidad de mails hostiles, algo que para él “carece de sentido”.

CÓMO PROTEGERSE

En los papeles, Heartbleed es una pesadilla. Quienes lo calificaron como el peor desastre de seguridad en la historia de Internet no exageraban (el criptógrafo Bruce Schneier, entre otros).

En la práctica ocurrieron varias cosas, al menos hasta ahora. Primero, que explotar el Heartbleed es muy complicado. Es más probable que estén en riesgo los gobiernos y las grandes empresas, con redes gigantescas, que vos en tu casa (más consejos, abajo). Segundo, OpenSSL y los principales actores de Internet -incluidos los bancos, desde luego- respondieron en tiempo y forma.

Leyendo sobre todo esto encontré, en la semana, un artículomenos apocalípticosobre Heartbleed , cuyo autor, Steven Bellovin, es profesor de Ciencias de la Computación en la Universidad de Columbia, una de las más prestigiosas en el campo de la seguridad informática.

Me puse en contacto con Bellovin para consultarlo sobre cuáles son los riesgos del Heartbleed para el resto de nosotros y qué hacer para mantenernos razonablemente a salvo. Esto es lo que hablamos.

-Tenés una mirada muy realista del Heartbleed, y hasta ahora tuviste razón, no se produjeron grandes incidentes.

-La seguridad es, en el fondo, un asunto práctico. La pregunta que les enseño a mis estudiantes que deben hacer primero es: ¿Qué están tratando de proteger y contra quien? Ésa es la esencia de lo que publiqué acerca del Heartbleed: para la mayoría de las personas no constituye una amenaza seria.

-¿Por qué no?

-Porque se necesita un adversario realmente poderoso para usar las credenciales robadas. Si hacés home banking desde tu casa, probablemente no estás en riesgo. Ahora, si lo hacés desde un hotspot [un Wi-Fi abierto en un aeropuerto, por ejemplo], es un asunto diferente.

-¿Lo que querés decir es que un atacante puede obtener claves criptográficas, pero encontrará mucha dificultad para usarlas?

-Así es. Puesto de otra forma: vos podés tener una copia de la llave de mi casa, pero estás en la Argentina, no te va a servir de mucho. Incluso si estuvieras en el área de Nueva York, donde resido, todavía tendrías que encontrar mi casa. Sí, podrías lograrlo, pero probablemente, no. Probablemente no es lo mismo que definitivamente, pero es una manera de evaluar los riesgos.

-¿Qué debería hacer un usuario normal, sin formación en sistemas o en ingeniería, para protegerse del Heartbleed?

-Primero, si tenés un sistema vulnerable (el Heartbleed puede afectar también a las máquinas cliente, aunque ese es, según entiendo, un problema mayormente de Android), tenés que obtener el parche de parte del fabricante del dispositivo. Segundo, cambiar tus contraseñas críticas: todas las financieras más la del correo electrónico. ¿Por qué la del correo? Porque tu cuenta de correo es la que se usa para recuperar todas las otras contraseñas, cuando las perdés o te las olvidás. El que la tenga puede robarte muchas otras cuentas.

-Decías que los hotspots abiertos son también un problema.

-Sí, porque, por razones técnicas, es mucho más fácil desviar el tráfico de datos allí que hacerlo con el de tu casa.

-¿Pensás que el error que cometió Robin Seggelmann fue accidental?

-Sí, definitivamente. Un backdoor insertado deliberadamente por una agencia de inteligencia habría sido mucho más sutil. Hace muchos años lideré un equipo que auditaba un sistema importante que pensábamos que había sido saboteado. Pues bien, encontré dos errores separados, ninguno era dañino por sí mismo. Pero juntos podían causar problemas bajo ciertas condiciones. Y todavía hoy ignoro si aquellos dos errores fueron deliberados.

-¿Creés, entonces, que no va a haber incidentes graves causados por el Heartbleed?

-No, no creo que vaya a pasar nada grave, y la mayoría de los sitios ya han instalado los parches necesarios. Puede haber problemas -arrestaron a alguien en Canadá que trató de explotar este error, tengo entendido-, pero en general creo que el riesgo era menor desde el principio y que las partes involucradas respondieron rápida y apropiadamente.

-¿Cuál es, en tu experiencia, el error más común que cometemos con nuestras contraseñas?

-El mayor error que comete el público es reutilizar contraseñas. (Para los programadores, la regla número 1 es: No inventes tu propia criptografía. Se trata de un campo realmente sutil, pero ése es el consejo para el personal técnico.) En cuanto a las contraseñas en sí, elegir una que sea robusta y anotarla o usar un administrador de contraseñas, los hay muy buenos. El consejo de no anotarlas en papel es usualmente equivocado. Lo correcto sería No anotes tus contraseñas donde alguien interesado en robártelas podría verlas. Por ejemplo, la clave de tu home banking en un papelito junto a tu computadora es una mala idea. Pero podés anotarla en un cuaderno y guardarlo en un cajón bajo llave. A todos nos han dicho que elijamos contraseñas robustas y que no las anotemos en papel. Pero ese consejo tiene 35 años de antigüedad, cuando pocas personas tenían más de una cuenta. El mundo ha cambiado, ahora tenemos docenas de cuentas, y el consejo debe cambiar también.

***

Así que, administradores de sistemas, a parchar. Creo que durante las próximas semanas aparecerán varios informes de ataques mediante Heartbleed. Y, como me dijo un amigo por Twitter, también es probable que muchos ataques causados por otros motivos sean atribuidos al Heartbleed.

El resto de nosotros, a cambiar contraseñas. Un buen administrador de claves aquí. Y evitemos los Wi-Fi abiertos para sesiones HTTPS.

Información adicional y herramientas

* Laextensión antiphishing de Netcraft ahora permite, en Chrome y Opera, determinar si el sitio que estás visitando es vulnerable al Heartbleed
* La absolutamente genial (bueno, nos tiene acostumbrados) descripción del Heartbleed de XKCD
*Link al aporte de Seggelmann que contenía el error. Puede verse la fecha y hora en que se subió el código con la falla: 31 de diciembre de 2011 a las 19,59.
* Como habrán notado los especialistas, la explicación que di más arriba sobre el Heartbeat y el Heartbleed deja de lado asuntos importantes, aunque excesivamente técnicos (como la gestión de memoria). Para ellos, dos sitios con análisis más profundos del Heartbleed, incluido el código fuente del error  y del parche.