Vigilancia de seguridadContraseñas y tarjetas de crédito, parte 1
Jesper M. Johansson
Contenido
Consejos de seguridad no procesables
No procesables e incorrectos
Consejos incomprensibles
Trampas de la autenticación de sitios basada en imágenes
Hace poco, la Universidad de Minnesota se puso en contacto conmigo para entrevistarme para su revista. Al parecer, querían publicar un artículo acerca de varios alumnos muy brillantes. Como no encontraron ninguno, en su lugar, decidieron entrevistarme a mí. La entrevistadora me preguntó en qué trabajo y dediqué unos minutos a intentar describirle el software
de infraestructuras de seguridad. Entonces, ella exclamó: "¡Qué complicado suena! Para mí, la seguridad trata de contraseñas y tarjetas de crédito".
Reflexioné durante unos minutos acerca de esta reacción, y me di cuenta de que tenía bastante razón. La seguridad sí que trata de contraseñas y tarjetas de crédito. Por lo menos, así es como lo percibe el usuario final. Los que trabajamos en ello, pensamos que la seguridad trata de algoritmos de cifrado, de si Kerberos es mejor que TLS o NTLMv2, de las ventajas de WS*, si se deberían aleatorizar los hash de contraseña y otras cuestiones esotéricas de las que nos encanta hablar. Es cierto que nuestra perspectiva es muy diferente y mucho más profunda que la de los usuarios finales, pero no nos hemos dado cuenta de algo fundamental: la seguridad, en la opinión de aquellos para los que trabajamos, trata de contraseñas y tarjetas de crédito.
Ya, todos los temas esotéricos que tanto nos gusta discutir y todas esas nuevas tecnologías que nos encanta inventar sirven para proteger los datos del usuario final. Aun así, creo que nos hemos perdido por el camino. Nosotros, la subcultura de la seguridad del mundo de la TI, existimos para cumplir una necesidad específica de nuestros clientes: la necesidad de mantener sus datos seguros. Eso, evidentemente, incluye la garantía de que se pueden usar todos los activos de TI sin riesgo alguno. En esencia, de eso se trata.
En artículos anteriores, dejé claro que nadie compra un equipo para poder ejecutar software de antivirus. Un usuario adquiere un equipo para usar sistemas de banca en línea, divertirse con juegos para PC, escribir mensajes de correo electrónico, hacer los deberes o alguna otra función primaria. Del mismo modo, ninguna empresa recurre a un grupo de seguridad de TI simplemente para implementar NTLMv2. Las empresas hacen uso de grupos de seguridad de TI para que protejan los activos de la organización, lo que permite a las grandes compañías usar sus recursos de TI sin riesgo alguno y alcanzar sus objetivos empresariales.
Nuestro único propósito es servirles.
Por lo tanto, cabe preguntar si actualmente estamos haciendo un buen trabajo a la hora de ofrecer servicios. ¿O quizá, por el contrario, estamos entorpeciendo las cosas en lugar de ayudar? ¿Nos están ayudando los legisladores y reguladores a entorpecerlo todo? No estoy convencido de que toda esta nueva tecnología que estamos estableciendo ayude realmente a los usuarios finales. Por lo tanto, me gustaría investigar algunas áreas en las que, como proveedores mundiales de TI, estamos causando más daño que beneficio.
A veces, da la sensación de que la mayoría de los consejos de seguridad y gran parte de la tecnología que ofrecemos a nuestros usuarios no son procesables, son incorrectos, incomprensibles o (en la mayoría de los casos) una combinación de los tres. En esta serie de tres partes, trataré algunos de los modos en que confundimos a los usuarios al aconsejarles o al implementar tecnologías culpables de alguno de los tres cargos anteriores.
Consejos de seguridad no procesables
Una de las mejores maneras de confundir a un usuario es proporcionarle consejos de seguridad que no se pueden aplicar. También se le pueden proporcionar consejos incorrectos. La Figura 1 ilustra una parte bastante conocida de un dispositivo de comprobada eficacia, teóricamente correcto y completamente inútil.
Figura 1 Consejo de seguridad no procesable (haga clic en la imagen para ampliarla)
¿Ve donde pone que use una contraseña distinta para cada cuenta que tenga en línea? Hace treinta años, esta recomendación tenía sentido. El número de usuarios de Internet por aquel entonces era de unos pocos cientos. Se trataba de personas muy inteligentes que no elegían buenas contraseñas. Desgraciadamente, este consejo se ha mantenido hasta hoy día y se repite una y otra vez. No se ha hecho ningún esfuerzo para adaptar este consejo al uso actual de la informática.
¿Cuántas cuentas tiene en línea? Yo tengo alrededor de 115, sin contar aquellas de las que no realizo ningún seguimiento. El consejo de la Figura 1 no sólo sugiere que debo tener 115 contraseñas diferentes, sino que también debo cambiarlas cada 30 o 60 días. Dicho de otra manera, tengo que cambiar de 2 a 4 contraseñas al día. Haga los cálculos: también significa que tendría entre 690 y 1380 contraseñas en un solo año.
Aunque el personal técnico que ofrece este consejo pueda inventarse cuatro buenas contraseñas al día y mantener 115 en la memoria a corto plazo, seguro que el 99,99 por ciento de las personas que usan Internet no podrán hacerlo.
Puede que el consejo de usar diferentes contraseñas sea correcto desde un punto de vista puramente teórico, al igual que el consejo de cambiar las contraseñas cada 30 o 60 días. Sin embargo, este consejo no es procesable. Dado el número de contraseñas que tienen los usuarios hoy en día, simplemente no pueden seguir este consejo sin ningún tipo de ayuda, ya sea mediante papel o software. Veamos el siguiente ejemplo.
No procesables e incorrectos
El consejo que se muestra en la Figura 2, que proviene del sitio web de uno de los principales bancos del mundo, no es procesable y tampoco es correcto. La información que se ofrece bajo el encabezado que sugiere a los usuarios la lectura de los consejos sobre contraseñas equivale exactamente a "contraseñas diferentes en todos los lugares". También se recomienda que "nunca las escriba".
Figura 2 Consejo no procesable e incorrecto (haga clic en la imagen para ampliarla)
Así que ahora tengo 115 contraseñas diferentes, tengo que inventarme cuatro nuevas cada día y no puedo escribirlas. Durante un tiempo, pensé que esto era una estupidez, ya que me resultaría imposible acordarme de todas las contraseñas. Luego me di cuenta de que todo el mundo es exactamente igual que yo. Básicamente, un ser humano es incapaz de recordar 115 contraseñas. Somos capaces de recordar y procesar alrededor de siete bloques de información: así es como estamos programados. Si seguimos la mayoría de los consejos de contraseñas que hay en Internet, eso ni siquiera basta para una sola contraseña (consulte "El número mágico siete más o menos dos: algunos límites de nuestra habilidad para procesar la información", de George A. Miller, disponible en musanim.com/miller1956).
Desgraciadamente, en lo referente a los consejos para las contraseñas, nuestra industria suele engañar a los usuarios con bastante regularidad. Si la subcultura de la seguridad dice a los usuarios que deben usar una contraseña diferente para cada cuenta, entonces también debemos decirles cómo tienen que hacerlo: registrando y almacenando dichas contraseñas en algún lugar seguro. Escríbalas en un trozo de papel, use un documento protegido o una herramienta especializada, como PasswordSafe (sourceforge. red/proyectos/passwordsafe). Así de claro: o registramos todas las contraseñas o usamos la misma en todos los lados. De hecho, en una encuesta reciente, se descubrió que el 88 por ciento de los usuarios tienen la misma contraseña en todos los sistemas en los que deben autenticarse (consulte msnbc.msn.com/id/24162478).
Es obvio que el consejo de no escribir las contraseñas ha contribuido a que se dé esta tendencia. Lo que debemos hacer es enseñar a los usuarios el modo de administrar sus contraseñas (y otros datos confidenciales) de manera eficaz, en lugar de enseñarles a no administrar la información en absoluto. Seguro que habrá menos posibilidades de que comprometan la seguridad de sus credenciales.
Consejos incomprensibles
Las dos primeras figuras repiten un consejo que funcionaba en los años 60, 70 y 80, cuando los usuarios estándar aún no se conectaban a Internet ni usaban servicios basados en web. A día de hoy, nadie se ha quejado de este tipo de consejo porque se ha aceptado de forma generalizada.
Este tipo de consejo confunde a los usuarios y les hace sentirse culpables por tener que almacenar sus contraseñas en algún lugar. Los profesionales de la seguridad perjudican a los usuarios al ofrecerles este tipo de consejo en lugar de ayudarles a hacer lo que deben. Después de todo, los usuarios no son responsables de averiguar el modo en que deben administrar su seguridad. Eso corresponde a los profesionales de la seguridad. Debemos ofrecer a nuestros usuarios formas aceptables de administrar todas sus cuentas en línea. Sin embargo, dado que la mayoría de las indicaciones ofrecidas se limitan a repetir los mismos consejos anticuados, los usuarios recurren a post-its o a hojas de cálculo para registrar todas sus contraseñas.
Como mecanismo de autenticación, las contraseñas tienen muchísimo potencial. Sin embargo, el problema principal de las contraseñas es que los seres humanos son terribles a la hora de recordarlas. En lugar de intentar resolver un problema de naturaleza humana, el mundo de la TI se empeña en inventar todo tipo de mecanismos para reemplazar las contraseñas o, lo que es aún peor, aumentarlas. Lo único que se consigue con esto es confundir aún más a los usuarios.
Imagine mi sorpresa la última vez que utilicé un cierto sitio de servicios financieros y me presentaron una pantalla de inicio de sesión que contenía un solo cuadro de texto para el nombre de usuario (vea la Figura 3).
Figura 3 ¿Dónde escribo la contraseña?
Al principio, pensé que me encontraba en algún tipo de sitio web malintencionado. Luego, validé el sitio rápidamente. Este paso fue bastante fácil, ya que el sitio web presentaba un certificado. Así fue como me di cuenta de que, efectivamente, me encontraba en el lugar adecuado. El problema reside en que la mayoría de las personas están acostumbradas a ver dos cuadros de texto, el del nombre de usuario y el de la contraseña, que se presentan juntos cuando se inicia la sesión en un sitio. Llevamos años y años encontrándonos con el mismo flujo de trabajo. Por eso, si de repente uno se encuentra con un sitio que sólo pide el nombre de usuario, parece que todo se detiene. Resulta que, en este caso, y como intento de evitar los ataques de phising, el proveedor había implementado una tecnología basada en imágenes para que los usuarios identificaran el sitio. De este modo, cuando se rellena el cuadro de nombre de usuario, aparece una ventana emergente con una imagen identificable, tal y como se muestra en la Figura 4.
Figura 4 Algunos sitios usan ahora imágenes para autenticar el sitio a un usuario (haga clic en la imagen para ampliarla)
En teoría, el usuario sabe qué imagen se relaciona con un sitio determinado. Si no se muestra la imagen correcta, se identifica el sitio como falso. Este concepto, de por sí, es bastante sólido. Suponiendo que el usuario sabe qué imagen se relaciona con un sitio determinado, esta estrategia tiene bastante sentido.
Evidentemente, el lector astuto se habrá percatado de la barra de direcciones verde de la Figura 4. Esto quiere decir que el sitio usa certificados SSL y de validación extendida, que es la razón por la que la barra de direcciones es de color verde. También implica que la premisa de usar una imagen para identificar el sitio no ofrece ningún valor adicional. Por el contrario, la imagen no hace sino causar confusión, como mínimo, para algunos usuarios finales. Ya se ha identificado el sitio al usuario: ha proporcionado un certificado que contiene el nombre de la compañía, la dirección del sitio web y el nombre del emisor de confianza. Además, el hecho de que la barra de direcciones sea de color verde me dice que la compañía ha dado un paso adicional y ha pagado tres veces más por un certificado de validación extendida.
Claro que también es posible que las imágenes sean falsas. Si el usuario puede enviar su propia imagen, un atacante dispone de medios para averiguar la imagen que se está usando. También hay una alta probabilidad de que el usuario use la misma imagen para todos los sitios, por lo que lo único que deberá hacer el atacante es crear un sitio con contenido que pueda valorar el usuario (dejaré que se le ocurran sus propios ejemplos) y pedirle una imagen para verificar el sitio. Si el usuario usa la misma imagen para todos los sitios, el nuevo sitio obtendrá acceso a la imagen del usuario, para, por ejemplo, obtener acceso al sitio web de su banco.
Aunque algunos sitios permiten que el usuario escoja su propia imagen, hay otros que tienen su propia biblioteca de imágenes. Por ejemplo, en el sitio de la Figura 4, se puede elegir entre 318 imágenes de archivo. El truco anterior no funciona en los sitios que no permiten al usuario enviar su propia imagen. Sin embargo, las probabilidades de que el usuario recuerde las fotografías que se relacionan con cada sitio serán bastante bajas para los sitios que no se visiten frecuentemente. No tengo ni la menor idea de la imagen que uso para el sitio de la Figura 4, aunque puedo asegurarle que no es la que aparece en la captura de pantalla.
El problema del enfoque basado en imágenes es que un atacante puede mostrarle cualquiera de las 318 imágenes o elegir una fotografía cualquiera de Flickr, y muchos usuarios darán por hecho que la imagen es la correcta. Si la mayoría de las personas recordaran cosas como qué fotografía se relaciona con un sitio determinado, no tendríamos los problemas actuales de phising ni los relacionados con la seguridad.
Así que, ¿qué sentido tiene usar una imagen para autenticar un sitio al usuario cuando el sitio ya se ha autenticado mediante un certificado? ¿Por qué no usamos simplemente este certificado y ayudamos a los usuarios a aprender a validarlo? Los certificados ya demuestran la identidad del sitio al usuario.
El proceso de obtención de un certificado es mucho más seguro que el de obtener una imagen de autenticación de un sitio. Si el certificado es de validación extendida y el usuario utiliza Internet Explorer® 7 o Firefox 3, el explorador incluso resaltará la información relevante del certificado en la barra de direcciones. Desgraciadamente, la función de resaltado sólo se aplica a los caros certificados de validación extendida.
Trampas de la autenticación de sitios basada en imágenes
La tecnología de autenticación por imágenes tiene una serie de problemas. En primer lugar, la tarea de recopilar los nombres de usuario de un sitio se convierte en algo bastante fácil. De hecho, el sitio de la Figura 4 presentará el cuadro de diálogo de la Figura 5 si escribe un nombre de usuario incorrecto. Una vez que haya escrito el nombre de usuario correcto para un usuario que haya seleccionado una imagen secreta, podrá ver la imagen secreta de esta persona. Evidentemente, un atacante que esté intentando recopilar información acerca de un usuario encontrará esto bastante valioso.
Figura 5 Los sitios autenticados por imágenes permiten recopilar fácilmente los nombres de usuario
El tipo de implementación que se muestra aquí no tiene valor alguno en términos de seguridad. El atacante sólo tendría que duplicar el flujo de trabajo del inicio de sesión en un sitio falso. El sitio falso solicita el nombre de usuario y lo transmite al sitio real. Para que su apariencia sea más impecable aún, puede usar un AJAX en el cliente para actualizar el formulario en tiempo real. Además, si el sitio legítimo no ha mitigado los ataques de falsificación de solicitudes entre distintos sitios en el formulario de inicio de sesión, el código de AJAX puede enviar una solicitud directamente al sitio real, a no ser que el explorador mitigue las solicitudes de XML-HTTP entre sitios.
Ahora, una vez que se haya devuelto el resultado, el atacante puede analizar los datos, extraer la imagen y mostrársela al usuario final. En otras palabras, un atacante capaz de presentar un sitio de inicio de sesión falso al usuario podrá también mostrar la imagen secreta del usuario. El resultado final es que no existe ningún valor añadido asociado al uso de la autenticación basada en imágenes. La imagen se muestra antes de que el usuario autentique el sitio y, por lo tanto, el atacante que tiene (o podría tener) el nombre de usuario de esta persona podrá obtener acceso a la imagen.
Si damos por hecho que nadie ha enseñado al usuario a buscar un certificado antes de enviar formularios (esta suposición es segura, ya que la autenticación basada en imágenes se basa, a su vez, en esa misma suposición), obtener un nombre de usuario es una tarea bastante trivial. Además, dado que muchos esquemas de autenticación de sitios basada en imágenes responden de modo diferente a un nombre de usuario válido que a uno no válido, la recopilación de nombres de usuario es igualmente trivial. El atacante puede hacerlo incluso fuera de banda, antes de que comience el propio ataque.
Al final, tenemos usuarios que creen que su seguridad es mayor de lo que realmente es o que están mucho más confundidos. Hemos dedicado gran cantidad de capital social a implementar la autenticación de sitios basada en imágenes, pero no les hemos puesto las cosas difíciles a los usuarios malintencionados que convencen a los usuarios finales para que envíen sus credenciales a sitios web falsos.
No hay espacio para más en este número de Vigilancia de seguridad. Vuelva el mes próximo para la segunda parte de esta serie, donde trataré más ejemplos de prácticas de seguridad torpes e implementaciones de autenticación incorrectas.
Jesper M. Johansson es arquitecto de software dedicado al campo del software de seguridad. Es editor colaborador de TechNet Magazine. Posee un doctorado en sistemas de información de administración, más de 20 años de experiencia en el ámbito de la seguridad y es MVP de Microsoft en seguridad empresarial. Su último libro es Windows Server 2008 Security Resource Kit.
© 2008 Microsoft Corporation y CMP Media, LLC. Reservados todos los derechos. Queda prohibida la reproducción parcial o total sin previa autorización.