Vigilancia de seguridadContraseñas y tarjetas de crédito, 2ª parte
Jesper M. Johansson
Contenido
Proceso de inicio de sesión pseudomultifactor
El problema de los complementos del explorador
El autenticador no debe cambiar nunca
Uso de una versión anterior menos segura de las contraseñas
Cómo omitir el inicio de sesión pseudomultifactor
Problemas con contraseñas comprometidas
Algunas ventajas
Engañar a los usuarios con una imagen atractiva
Abrir o no abrir
Ofrecer una comunicación segura
La privacidad está en juego
Bienvenido a la segunda entrega de esta serie de tres partes sobre cómo el sector de TI confunde a los consumidores en lugar de ayudarles con los problemas de seguridad. En el número de julio de 2008 de TechNet Magazine hablaba de consejos improcedentes e incorrectos sobre seguridad, así como de flujos de trabajo confusos de inicio de sesión. Si no ha leído aún la primera parte, la encontrará
en technet.microsoft.com/magazine/cc626076. Expuse la idea de lo común que sigue siendo aún el confundir a los consumidores con consejos de seguridad insuficientes y flujos de trabajo incorrectos de inicio de sesión y el socavar los esfuerzos de los mismos a la hora de proteger su información personal.
En esta entrega seguiré tratando este tema, aportando ejemplos más reales tomados del mundo de la seguridad del consumidor. La última entrega de esta serie, que incluirá una "llamada a las armas" para los profesionales de la seguridad de todo el mundo, se publicará en el próximo número de TechNet Magazine.
Proceso de inicio de sesión pseudomultifactor
En octubre de 2005, el Federal Financial Institutions Examination Council (FFIEC) publicó sus directrices con el título "Authentication in an Internet Banking Environment" (consulte www.ffiec.gov/press/pr101205.htm). El calendario para su implementación era de tan sólo 14 meses, por lo que las instituciones financieras de EE. UU. pronto se encontraron con numerosas dificultades para encontrar la manera de cumplir con las nuevas directrices.
La mayoría de las instituciones no consiguieron realizarlo en el plazo previsto. Muchas de las instituciones que al final cumplieron con las directrices, lo hicieron con medidas destinadas exclusivamente a satisfacer dichas directrices. En otras palabras, las instituciones tomaron medidas que no aumentaban en absoluto la seguridad de los clientes, ya que se trata en realidad de meros ensayos dentro del "escenario de la seguridad". Algunos de los ejemplos más interesantes de soluciones poco útiles son aquellas soluciones que intentan crear la autenticación multifactor sin ser en realidad multifactor.
Tomemos, por ejemplo, la tecnología que mide la cadencia de escritura cuando un usuario escribe la contraseña. Esta solución empleada en un sitio web presenta un cuadro de diálogo de inicio de sesión con exactamente el mismo aspecto que el anterior cuadro de diálogo del mismo tipo. Este cuadro de diálogo, sin embargo, es ahora un objeto de Adobe Flash.
El objeto de Flash registra la cadencia de escritura del usuario que incluye, entre otras, características como el tiempo que dura la presión de las teclas y el intervalo de tiempo que transcurre entre cada presión de teclas. Estos datos y la contraseña se envían al sitio web, donde se comparan con los valores almacenados. El inicio de sesión se acepta cuando los datos de la cadencia de escritura se sitúan dentro de determinadas variaciones de los datos almacenados y la contraseña coincide. La idea general es que esto permita al sitio usar un método pseudobiométrico de autenticación sin tener que instalar hardware de terceros en el cliente.
De ahora en adelante, denominaré a este proceso autenticación de pseudomultifactor. No se trata de una autenticación multifactor real. Esta mide dos o más de los siguientes factores canónicos:
- Algo que el usuario tiene (como una tarjeta inteligente)
- Algo que el usuario sabe (como una contraseña)
- Algo que el usuario es (como una huella dactilar)
En lugar de incluir varios factores en el proceso de autenticación, la autenticación pseudomultifactor lee varios parámetros a partir de un solo factor: la contraseña. A continuación, emplea estos parámetros adicionales para sacar las conclusiones pertinentes acerca de algo que el usuario es.
La tecnología usada para la autenticación pseudomultifactor presenta muchas imperfecciones que, en conjunto, convierten a esta tecnología en una herramienta realmente ineficaz a la hora de resolver los problemas de seguridad para los que está diseñada.
El problema de los complementos del explorador
Los sistemas de autenticación pseudomultifactor se basan en complementos del explorador para ofrecer el procesamiento sofisticado de cliente que necesitan. Está claro que todos los programas de software presentan errores y algunos de estos provocan vulnerabilidades. Estas vulnerabilidades se convierten en un verdadero problema cuando la actualización del software es un proceso complicado y el usuario no está seguro de haber instalado una actualización.
Los complementos del explorador son responsables de estos dos tipos de características: son difíciles de actualizar y no ofrecen al usuario información detallada sobre el grado de actualización de la versión instalada. Como resultado, el usuario tiene que exponer en Internet un componente de software que, de lo contrario, no hubiera sido necesario hacerlo.
En determinadas ocasiones mantener actualizados un complemento requiere visitas frecuentes el sitio web del complemento para descargar las actualizaciones necesarias. Sobre decir que este tipo de situación no se produce normalmente para la mayoría de los usuarios. Cualquier sistema que requiera que un usuario final exponga otro software no relacionado a Internet sólo para proporcionar funciones de seguridad debe ser tomado en gran consideración.
El autenticador no debe cambiar nunca
El factor "algo que forma parte de usted" tiene un rasgo, quizás incluso un defecto, que no afecta a los otros dos factores. Si bien es posible cambiar contraseñas (algo que sabe) y producir nuevos tokens de seguridad (algo que tiene), el número de autenticadores biométricos que puede usar es bastante limitado. Con las huellas dactilares, por ejemplo, se suele disponer de diez de por vida. Si perdiera uno de estos dígitos en un accidente, normalmente no podría reemplazarlo.
Vamos a ver ahora cómo se aplica esto al ejemplo de inicio de sesión pseudomultifactor. Las métricas reunidas como parte de otro factor no se pueden reemplazar ni modificar fácilmente. En efecto, cuando se cambia una contraseña, también lo hace la manera en que el usuario la escribe, pero no lo hará la forma en que normalmente presiona las teclas en el teclado. Esta técnica se basa precisamente en ese aspecto. Si estas métricas se ven comprometidas, podrían sintetizarse. Como mínimo, un atacante puede capturar estas métricas y reproducirlas.
Uso de una versión anterior menos segura de las contraseñas
Una buena idea consiste en usar contraseñas largas y cambiarlas a menudo. Además, como comenté en la primera parte de esta serie y a diferencia de determinadas opiniones, otra buena práctica consiste en registrar las contraseñas, por supuesto de un modo seguro. Sin embargo, estas prácticas no son propicias para escribir contraseñas de forma manual. Una contraseña larga es más difícil de escribir y una contraseña registrada resulta mucho más útil cuando se puede copiar y pegar. Una de las mejores maneras de realizar el seguimiento de cien o más contraseñas es emplear una utilidad de software como, por ejemplo, Password Safe (que encontrará en sourceforge.net/projects/passwordsafe). Este tipo de herramienta permite generar contraseñas completamente aleatorias, almacenarlas en un formulario cifrado y pegarlas directamente en los cuadros de diálogo de inicio de sesión. De hecho, con herramientas como éstas, no le hará falta conocer ni las contraseñas.
Pero ahí está el problema: no es posible medir la cadencia de escritura a menos que el usuario escriba la contraseña. Y si además tiene que escribir la contraseña en un objeto que mide la cadencia de escritura, ahí es donde empieza a fallar esta técnica de administración de contraseñas. Escribir correctamente una contraseña completamente aleatoria de 15 caracteres no es una tarea sencilla. Por lo tanto, los usuarios optarán generalmente por simplificar sus contraseñas cuando usen este tipo de sistema. Aun así, una contraseña completamente aleatoria de 15 caracteres es en sí mucho más segura que una contraseña más corta emparejada con un sistema de autenticación pseudomultifactor.
En efecto, la autenticación pseudomultifactor, implementada exclusivamente, obliga a los usuarios a usar contraseñas menos seguras. Desgraciadamente, como comprobará en breve, tener en cuenta a usuarios que emplean técnicas correctas de administración de contraseñas obvia prácticamente cualquier valor que ofrezcan los sistemas de autenticación pseudomultifactor.
Cómo omitir el inicio de sesión pseudomultifactor
Aunque un sitio ejecute la autenticación pseudomultifactor, debe admitir asimismo una forma de omitir dicho sistema. En primer lugar, pocos sitios pueden obligar a todos sus usuarios a que instalen una tecnología de "cuartos" para poder tener acceso al sitio. Parte de estos usuarios como, por ejemplo, algunos autores de TechNet Magazine, siempre se negarán a instalar este tipo de software.
En segundo lugar, la cadencia de escritura puede cambiar por muchos motivos que los sitios deberán contemplar. Por ejemplo, supongamos que un usuario se hace un esguince en la muñeca y que esto modifica temporalmente su cadencia de escritura. ¿Cómo podrá obtener acceso al sitio si éste analiza su cadencia y piensa que otra persona está intentando iniciar sesión con sus credenciales de usuario? Si la lesión fuera permanente, el usuario podría restablecer el valor de cadencia almacenado. Sin embargo, como se trata de una lesión temporal, el usuario probablemente no desea restablecer el valor almacenado, ya que asume que su cadencia de escritura pronto volverá más o menos a su estado original.
Por último, no todos los usuarios son capaces de usar sistemas de autenticación pseudomultifactor. Por ejemplo, una persona minusválida que interactúa con el equipo a través de una interfaz de reconocimiento de voz podría no ser capaz de rellenar el cuadro de diálogo, en función de si evita o no la entrada mediante programación. En ese caso, lo más probable es que la ley exija un sistema alternativo compatible con los usuarios minusválidos.
La forma más sencilla y directa de aceptar todas estas situaciones consiste en admitir también la autenticación estándar basada en contraseña.
Problemas con contraseñas comprometidas
Los sistemas de autenticación pseudomultifactor pretenden solucionar varios problemas asociados con la autenticación basada en contraseña. Sin embargo, estos sistemas no consiguen abordar cada una de las principales formas en que pueden comprometerse las contraseñas. Existen cinco maneras principales en las que los sistemas basados en autenticación por contraseña pueden verse comprometidos, entendiendo por "verse comprometidos" el hecho de que un atacante obtiene y usa la contraseña de otro usuario:
- Averiguación de contraseñas
- Capturadores de teclado
- Ataques de suplantación de identidad (phishing)
- Preguntar al usuario
- Irrumpir en cualquier sistema que almacena la contraseña o un hash de ésta
La averiguación de contraseñas ha dejado de ser un método de ataque común para los atacantes y se ha ido sustituyendo progresivamente por otros métodos como los capturadores de teclado o la suplantación de identidad. La averiguación de contraseñas, además, sólo queda mitigada en parte por la autenticación pseudomultifactor. Es poco probable que un método normal de averiguación de contraseñas funcione con un sistema de autenticación pseudomultifactor, ya que el atacante debe adivinar la contraseña y la cadencia de escritura. Aunque en teoría es posible sintetizar la métrica de escritura, rara vez es necesario hacerlo, ya que los verdaderos datos normalmente se pueden capturar mediante un ataque de suplantación de identidad o un capturador de teclado. Asimismo, si el sistema ofrece además una interfaz estándar de inicio de sesión sólo mediante contraseña, el atacante puede usar simplemente ese sistema para adivinar la contraseña.
La mejor manera de combatir los ataques de averiguación de contraseñas es usar contraseñas seguras. Si enseñáramos a los usuarios a emplear contraseñas más seguras, posiblemente con la ayuda de herramientas, la autenticación pseudomultifactor no sería necesaria. (En cambio, las contraseñas más sencillas que se emplean normalmente con los sistemas de autenticación pseudomultifactor hacen en realidad más viable el método de averiguación de contraseñas.) Por lo tanto, cualquier valor que pueda ofrecerse en este caso para mitigar la averiguación de contraseñas sólo agrega valor si la implementación no es compatible con el inicio de sesión de sólo contraseña. Y, como he comentado, esto es prácticamente imposible. Es decir, si los usuarios emplean contraseñas menos seguras en presencia de sistemas de autenticación pseudomultifactor, la averiguación de contraseñas puede convertirse de nuevo en un método de ataque viable, de forma que la autenticación pseudomultifactor reduciría la seguridad en lugar de aumentarla. Por lo tanto, es necesario investigar más sobre este tema.
La autenticación pseudomultifactor tampoco es efectiva para resolver los problemas derivados de ataques de capturadores de teclado. Aunque a día de hoy no tengo noticia de ningún capturador de teclado de uso habitual que capture la cadencia de escritura, no hay motivo alguno por el que no se pueda diseñar uno que lo haga. Un capturador de teclado es un hardware que se coloca entre el teclado y el equipo o un software que captura las pulsaciones de teclas. En cualquier caso, el capturador tiene acceso completo a todos los datos que usa la solución de autenticación pseudomultifactor.
De hecho, el capturador de teclado puede incluso tener acceso a más datos, ya que una solución de autenticación se ejecuta en modo de usuario, mientras que un capturador de teclado se sitúa muy por debajo de ese nivel. A menos que exista un canal de confianza entre el teclado y el objeto basado en Web empleado para capturar la contraseña, no es posible evitar este tipo de riesgo. Si las soluciones de autenticación pseudomultifactor acaban siendo lo suficientemente habituales, está claro que tarde o temprano alguien creará un capturador de teclado de este tipo.
Asimismo, los ataques de suplantación de identidad tampoco pueden combatirse mediante la autenticación pseudomultifactor. En lugar de usar simplemente una pantalla de inicio de sesión falsa, el atacante puede usar un objeto de Flash para capturar la contraseña y la cadencia de escritura.
También hay que admitir que la autenticación pseudomultifactor puede ayudar en determinadas situaciones en las que la técnica del atacante sólo proporcionará la contraseña del usuario. Por ejemplo, la manera más fácil de obtener una contraseña de un usuario es preguntarle al propio usuario. Lo sorprendente es que esta técnica ha resultado ser efectiva, ya sea preguntando a los usuarios en persona, por teléfono o a través de mensajes de suplantación de identidad.
Preguntarle a un usuario su cadencia de escritura resultará, por supuesto, mucho menos efectivo. Del mismo modo, si una base de datos corporativa de contraseñas se ve comprometida, lo más probable es que el atacante sólo obtenga acceso a las contraseñas. Pero aquí de nuevo los ataques sólo se mitigarán si el sistema no ofrece autenticación estándar basada sólo en contraseña.
Me gustaría destacar además que si la propia base de datos de contraseñas ya está en realidad comprometida, es probable que el atacante haya puesto en peligro el sistema de un modo mucho más profundo que el que sería posible con una sola contraseña de cuenta de usuario normal, o incluso con varias. De este modo, no sirve de mucho intentar mitigar lo que puede hacer un atacante en posesión de una base de datos de contraseñas.
Algunas ventajas
Para ser justos, la autenticación pseudomultifactor sí puede ayudar a solucionar algunos problemas, siempre que el sistema no ofrezca la opción estándar de inicio de sesión basado únicamente en contraseña. Por ejemplo, puede usarse para evitar las contraseñas compartidas. Sin embargo, esto puede ser un inconveniente para los sistemas en los que sea legítimo compartir cuentas entre varios usuarios, como puedan ser cuentas bancarias conjuntas.
Además, un cuadro de diálogo interactivo de inicio de sesión debidamente diseñado (no un inicio de sesión en un sitio web) podría forzar al usuario a pasar por otras fases de autenticación si su cadencia de escritura no coincide. Esto puede proporcionar seguridad adicional para una cuenta comprometida en un entorno muy confidencial.
Engañar a los usuarios con una imagen atractiva
Una de las mejores formas de engañar a los usuarios es proporcionarles indicaciones poco precisas de seguridad. El método más común es quizás la imagen del candado que se muestra en una página web, como la de la figura 1. Esta página va más allá e incluso muestra la palabra "Secure" (seguro) junto al candado.
Figura 1 Ejemplo de abuso del icono del candado, una tendencia preocupante (haga clic en la imagen para ampliarla)
Como sabrá, el mero hecho de colocar una imagen de candado y la palabra "Seguro" en una página no la hace segura. Sin embargo, lo inquietante de este tema es que es una práctica bastante habitual, incluso entre los sitios web más visitados y de mayor reputación. El resultado es que muchos usuarios se acostumbran a buscar estas indicaciones visuales de seguridad en el cuerpo de la página web en lugar de averiguar si estas indicaciones tienen algún significado en el lugar que realmente importa: la barra de direcciones. El wiki sobre el contexto de seguridad web W3C incluye una entrada sobre este problema; lo encontrará en w3.org/2006/WSC/wiki/PadlockIconMisuse.
Es lamentable que haya tantos ejemplos de este tipo de uso indebido. Diversos estudios han revelado que los usuarios no son capaces de identificar sitios web malintencionados, incluso cuando los certificados son muy obvios (consulte www.usablesecurity.org/papers/jackson.pdf). En el fondo se trata de la capacidad de distinguir fácilmente lo falso de lo verdadero, aunque no se disponga del verdadero para compararlo. Para ello hace falta tener habilidad; la información atractiva y engañosa de seguridad en páginas web dificulta el desarrollo de esta habilidad, ya que se atrae a los usuarios hacia la información incorrecta.
Una variante especialmente perturbadora de este problema es la que se muestra en la figura 2. En este caso, la página que muestra la información en realidad no es segura. Si miramos la barra de direcciones, veremos que el protocolo indicado es "http". Este sitio hace uso de una técnica muy común de optimización: en lugar de cifrar la página que contiene el formulario de inicio de sesión, sólo se cifra el envío del formulario. El inicio de sesión es seguro, tal como indica la página, siempre que asociemos "seguro" con "cifrado". Sin embargo, y esto es crucial, el usuario no puede comprobar dónde se envían las credenciales hasta que éstas se han enviado. El sitio no muestra un certificado que autentique el sitio al usuario hasta que se haya enviado el formulario. Es una cuestión de confianza, como caer hacia atrás esperando que la persona que se encuentra detrás de nosotros nos agarre. En el momento de enviar el formulario, puede que el daño ya esté hecho.
Figura 2 Imagen atractiva de seguridad en una página que no es segura (haga clic en la imagen para ampliarla)
La capa de sockets seguros (SSL), el protocolo que proporciona la seguridad en HTTPS, tiene dos finalidades importantes. En primer lugar, autentica el servidor para el usuario. En segundo lugar, ofrece un mecanismo sencillo para negociar una clave de cifrado de sesión que se puede usar entre cliente y servidor.
Si sólo se cifra el envío del formulario, ya no se logra el principal y primer objetivo. Los sitios que emplean esta optimización usan simplemente SSL como un método para negociar claves. Lo irónico es que esto lo podrían hacer simplemente empleando un protocolo de negociación de claves estándar, con lo que se evitarían el costo y la sobrecarga que supone el uso de SSL.
El sitio que se muestra en la figura 2 no es una rareza. Muchos sitios ofrecen protección SSL sólo para el envío de formularios, pero no para el propio formulario. Este sitio en concreto, sin embargo, presenta un rasgo aún más perturbador. Si escribimos https://www.<sitio>.com (observe el indicador https seguro) en la barra de direcciones del explorador, el sitio le redirigirá a la versión no SSL de éste. Aunque intente inspeccionar un certificado antes de enviar sus credenciales al sitio, éste último se negará a mostrarle el certificado.
No todos los sitios funcionan incorrectamente, pero muchos sí. Y dos de las más importantes entidades financieras de Estados Unidos emisoras de tarjetas de crédito se encuentran entre los infractores. De hecho, de las tres principales compañías de tarjetas de crédito que uso, sólo American Express proporciona un certificado en el formulario de inicio de sesión. American Express redirige incluso las solicitudes HTTP a HTTPS. Buen trabajo.
Un último apunte con respecto a las imágenes atractivas y sin sentido de seguridad y la ausencia de certificados en los formularios de inicio de sesión. Es posible que se pregunte por qué un sitio haría este tipo de cosas. El motivo es simplemente económico. Presentar certificados requiere cifrar la página, y cifrar la página implica realizar una inversión en el procesamiento. El gasto en el procesamiento significa que se requieren más equipos para cubrir una misma carga. Y más equipos cuestan más dinero. Lamentablemente, cuando se trata de elegir entre proteger la privacidad del cliente y aumentar los beneficios, muchas organizaciones optan por la segunda.
Abrir o no abrir
Hace poco recibí un mensaje de correo electrónico asombroso de la compañía de mi seguro médico. Cualquiera que haya usado un equipo informático en los últimos 10 años sabrá que nunca hay que abrir datos adjuntos de correo electrónico no solicitados. Así que imagínense mi sorpresa al recibir el mensaje que se muestra en la figura 3.
Figura 3 Mensaje de correo electrónico con "datos adjuntos seguros" (haga clic en la imagen para ampliarla)
Por lo que parece, formulé una pregunta en el sitio web de la compañía de seguro médico y ya ni me acordaba de ésta cuando llegó el mensaje sospechoso. Y así es cómo me respondió la compañía. Al principio pensé que se trataba de un esquema inteligente de suplantación de identidad. Cuando me di cuenta de que era un mensaje legítimo, se me pusieron los pelos de punta.
La primera instrucción es hacer doble clic en los datos adjuntos para iniciar el descifrado del mensaje. El conjunto de la comunidad de la seguridad y los administradores de TI se han pasado los últimos 10 años intentando enseñar a los usuarios a no hacer doble clic en datos adjuntos. Y luego viene una compañía (mi compañía de seguro médico, por cierto, no es la única organización que hace uso de este método) y me dice que debo hacer clic en los datos adjuntos para mi seguridad. ¿Cómo debe actuar el usuario en esta situación? ¿Qué conducta debe aprender u olvidar?
Seguidamente, usé la característica de vista previa en Microsoft® Office Outlook® 2007 para ver el archivo. Como se puede comprobar en la figura 4, Outlook pensó que este mensaje podría ser un ataque y me advirtió que no lo abriera.
Figura 4 Outlook 2007 considera que el documento seguro es hostil (haga clic en la imagen para ampliarla)
Resulta irónico, a la par que triste, que una compañía de asistencia sanitaria infrinja los controles de seguridad más básicos empleados en el cliente de correo electrónico más popular del mundo. Teniendo en cuenta que esta compañía ni se molestó en probar su nueva solución de seguridad con Outlook, me pregunto qué otras cosas hará para proteger mi información privada. O, dicho de manera más rotunda, ¿qué otras soluciones está implementando la compañía exclusivamente para evitar ser acusada de no proteger adecuadamente la privacidad de sus clientes? Esto es similar a la dramatización de seguridad que llevan a cabo las instituciones financieras. En mi opinión, en este caso el principal objetivo de la solución es evitar ser acusados, y no proteger realmente a los clientes.
Tenía ganas de saber en qué consistían en realidad los datos adjuntos. Resultó ser un objeto de control ActiveX®. Para ver los datos adjuntos, tuve que abrirlo en Internet Explorer® e instalar el objeto. Me apareció la pantalla de confirmación que se muestra en la figura 5. Como se puede comprobar, los diseñadores se esforzaron mucho en lograr que el mensaje se pareciera a un sobre de correos tradicional; incluso tiene un sello que afirma que el sobre es de confianza.
Figura 5 El documento "seguro" muestra un sobre con el sello "Trusted" (de confianza) (haga clic en la imagen para ampliarla)
Este tipo de tecnología es preocupante por muchos motivos. En primer lugar, promueve un comportamiento totalmente incorrecto por parte del usuario: abrir datos adjuntos no solicitados. En segundo, el mensaje real contiene instrucciones realmente inadecuadas sobre cómo configurar el sistema para que abra siempre datos adjuntos sin solicitar la confirmación del usuario. En tercero, los mensajes adquieren un carácter muy sospechoso cuando nos encontramos ante mensajes conflictivos del equipo para los que el correo electrónico dice que son de confianza y Outlook dice que no lo son. Por último, los datos adjuntos en cuestión contienen imágenes atractivas de seguridad sin sentido para convencer al usuario de que en realidad son de confianza. Si el usuario aprende a confiar en este tipo de mensajes, entonces la línea que separa este tipo de confianza con la de confiar en mensajes malintencionados de aspecto similar es mínima.
Ofrecer una comunicación segura
Admitámoslo: el problema que esta tecnología pretende solucionar es muy importante. Comunicar con los clientes con confianza es una tarea difícil. Sin embargo, esta solución en concreto está sobrediseñada. Lo más probable es que provoque confusión en los clientes y produzca un resultado final contrario al que pretendía: evitar comprometer el sistema del cliente.
Los sitios web mejor diseñados emplean ahora un "centro de mensajes". Con este tipo de diseño, cuando la compañía necesita comunicarse con el cliente, envía un mensaje de correo electrónico con un texto parecido al siguiente: "Tiene un mensaje en el centro de mensajes. Vaya a nuestro sitio web, inicie sesión y haga clic en el vínculo Centro de mensajes para ver el mensaje". Las compañías ganan más puntos cuando usan extensiones seguras multipropósito al correo de Internet (S/MIME) para firmar cualquier mensaje de correo electrónico dirigido a los clientes y permitir que el usuario autentique el origen. Si además el mensaje no incluye ninguna frase del tipo "haga clic en este vínculo", ganarán aún más puntos. El usuario debe escribir la dirección URL de la compañía de forma manual para asegurarse de que irá al sitio previsto.
Con un centro de mensajes y un mensaje firmado, las compañías pueden lograr un canal de confianza para comunicarse con el cliente. Todo lo que ve el cliente durante el flujo de trabajo de mensajes se autentica, con lo que la compañía se asegura de no promover prácticas de seguridad deficientes.
La privacidad está en juego
Hasta ahora, he dedicado las dos primeras entregas de esta serie a describir cómo los profesionales de la seguridad ofrecen realmente un mal servicio a los usuarios. Nuestro trabajo consiste en mantener la seguridad. Sin embargo, muchas de las decisiones que se toman y de las soluciones que se implementan confunden a los usuarios y les enseñan a tomar decisiones incorrectas, además de proporcionarles una sensación falsa de seguridad. No debemos abrumar a los usuarios con estas ideas opuestas.
Tal como comenté anteriormente, para los usuarios convencionales, la seguridad consiste simplemente en proteger las contraseñas y los números de tarjeta de crédito. Desean que la tecnología funcione y que sea de confianza. Lamentablemente, tienen que tomar decisiones y, por lo tanto, nuestro trabajo consiste en asegurarnos de que las decisiones que tomen estén bien fundamentadas.
En la última entrega de esta serie, hablaré de cómo algunas de las tecnologías más importantes disponibles para los consumidores no cumplen las expectativas depositadas en ellas. También presentaré mi "llamada a las armas". Así que ya saben: pueden consultar la columna sobre vigilancia de seguridad de septiembre de 2008.
Jesper M. Johansson es un arquitecto de software que trabaja en el campo del software de seguridad y colabora como editor en 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.