3.2.3. Contraseña de seguridad EjemploPara considerar un ejemplo del mundo de la seguridad de la contraseña, los administradores del sistema pueden intentar prevenir ataques de adivinar la contraseña contra su sitio web por los usuarios tengan que elegir contraseñas seguras (ver sección 9.6). Para ayudar a detectar ataques de adivinar la contraseña, los registros del servidor web pueden ser controlados por un gran número de inicios de sesión erróneos procedentes de una o más direcciones IP, y marcan las direcciones IP como sospechoso. Sin embargo, hacer eso no es suficiente. Todavía es probable que el atacante puede tropezar con un importante número de combinaciones de nombre de usuario y contraseña válidos, y es importante para reducir el número de cuentas que quedan comprometidas durante un ataque. Una opción podría ser la de negar todas las conexiones de las direcciones IP sospechosas de contener el ataque, o exigir una comprobación adicional para ver si el cliente presenta el servidor web con una cookie que se proporcionó al último inicio de sesión correcto. (Cubrimos las cookies en la sección 7.3.)Sin embargo, el atacante puede obtener algunos nombres de usuario y contraseñas válidas, sobre todo si elatacante tiene acceso a muchas direcciones IP, pero el objetivo de la contención es reducir el impacto del ataque, no impide por completo. Por último, para recuperarse del ataque, se podía controlar la actividad de la cuenta de los nombres de usuario para el que no estaban los inicios de sesión de éxito de las direcciones IP sospechosas, y negar cualquier transacción que parecen sospechosas, tales como las transferencias monetarias a las direcciones fuera del país. El sitio web también puede tener que presentar una reclamación de seguro para recuperarse económicamente de cualquier fraude exitoso que el atacante fue capaz de llevar a cabo, y la compra de los servicios de monitoreo de crédito para los clientes cuyas cuentas se han comprometido.

3.3. DIVERSIDAD-IN-DEFENSAUna idea relacionada con la defensa en profundidad se llama diversidad-en-defensa. Diversidad en la defensa propia essobre el uso de múltiples sistemas heterogéneos que hacen lo mismo.Un ejemplo del uso de la diversidad en la defensa personal es el uso de múltiples sistemas operativos dentro de una corporación para mitigar el impacto de los virus. Por ejemplo, se podría realizar una copia de seguridad de datos (por ejemplo, correo electrónico) en las máquinas que utilizan diferentes sistemas operativos.Si un virus ataca a Microsoft Outlook, que sólo funciona en plataformas Windows, será capaz de corromper todos los ordenadores de una empresa que ejecutan Microsoft Windows. Sin embargo, es poco probable que el mismo virus será capaz de atacar copias redundantes de la información almacenada en máquinas que ejecutan un sistema operativo diferente, como Linux. Usando una variedad de sistemas operativos protege toda la corporación contra los ataques a un sistema operativo en particular.Diversidad -en defensa viene a un costo, sin embargo. B y el uso de más de un sistema operativo,

el personal de TI puede venir bajo la carga de tener que ser expertos con más de una tecnología, y también tendrá que supervisar y aplicar parches de software para múltiples tecnologías. El mosto personal de TI

Capítulo 9

CONTRASEÑAS SEGURAS

Muchos sitios web, sistemas operativos, y otros tipos de software se han construido para usar contraseña palabras para autenticar a los usuarios. Aunque la comunidad de seguridad ha estado trabajando muchos años para avanzar hacia sistemas que utilizan mecanismos de autenticación más sofisticados, es probable que los sistemas de contraseñas estarán en uso por algún tiempo. Por lo tanto, es importante entender las fortalezas y debilidades de los sistemas de contraseñas y cómo hacerlos menos vulnerables a los ataques. En este capítulo, se expone cómo construir un gestor de mini-contraseña utilizando un ejemplo de código en Java. A continuación, incorporamos el gerente mini-contraseña en el servidor web simple presentado en el capítulo 2 para que pueda autenticar a los usuarios que quieran descargar documentos.

9.1 A Strawman proposal

El enfoque más básico en la construcción de un sistema de contraseña podría ser utilizar un archivo que almacena nombres de usuario y contraseñas. Un (delimitado colon) archivo Tal podría ser el siguiente:

john:automobilemary:balloonjoe:wepntkas

Cuando un usuario intenta iniciar sesión, usted puede simplemente localizar el nombre de usuario correspondiente en el archivo, y hacer una comparación de cadenas para determinar si la contraseña que el usuario introduce coincide con el uno en el archivo de contraseñas. (Si el nombre de usuario no aparece en el archivo de contraseñas, el inicio de sesión, por supuesto, ser negado.) Código Java para se muestra este enfoque simple aquí. Este enfoque básico, obviamente, tiene muchas limitaciones, no intente utilizar este código en un sistema real!Presentamos este código aquí principalmente para introducir la estructura básica de la clase MiniPasswordManager y refinamos como el capítulo avanza. La clase MiniPasswordManager en el código siguiente se utiliza una clase auxiliar llamada MiniPasswordFile, que enumeramos en el Apéndice B de modo que podemos centrarnos en lo esencial de MiniPasswordManager.

AQUÍ EL CODIGO

Las dos operaciones principales previstas en la clase MiniPasswordManager son add ()y checkPassword (). Ambos métodos toman un nombre de usuario y contraseña como argumentos. El método add () simplemente añade una entrada a la tabla hash dUserMap, cuya forma impide por nombre de usuario y almacena la contraseña como el valor. El checkPassword ()método busca el nombre de usuario en la tabla hash dUserMap y compara la contraseña facilitada a la almacenada en la tabla hash. Si coinciden, checkPassword () devuelve true; de lo contrario checkPassword () devuelve false sencilla -bastante y directo. El init () y flush () métodos de lectura y escritura de la tabla hash dUserMap desde y hacia el disco, respectivamente, utilizando la clase MiniPasswordFile (enumerados en el Apéndice B, como se mencionó anteriormente). El método main () se puede utilizar para agregar entradas al archivo de contraseñas. 1 Otras muchachas que utilizan la clase MiniPasswordFile puede inicializar MiniPasswordManager porllamando a su método init () con un archivo de contraseñas, y luego puede llamar checkPassword () para autenticar a los usuarios. Una vez que completemos la construcción de un mundo más seguro Clase MiniPasswordManager, que se adaptará SimpleWebServer del Capítulo 2 al utilizar MiniPasswordManager para autenticar usuarios que intentan descargar documentos del servidor web. Como hemos mencionado, el enfoque básico ilustrado por el código anterior tiene muchas limitaciones de seguridad. Por ejemplo, si un adversario alguna vez se apoderó del archivo de contraseñas, todas las contraseñas de los usuarios correría peligro. Cuantas más personas que utilizan el sistema, más valioso se convierte en el archivo de contraseñas, y mayor será el incentivo para un atacante para tratar de apoderarse de él.

9.2 HASHING

En un intento de remediar la situación, usted podría decidir no guardar las contraseñas "en claro". En cambio, podría almacenar una versión encriptada de las contraseñas, y descifrar las contraseñas en el archivo cada vez que usted necesita para comprobar ellos. Para ello, puede utilizar un algoritmo de cifrado simétrico, como AES (Advanced Encryption Standard). (Discutiremos los algoritmos de cifrado simétrico en el capítulo 12.) Usted tendría que seguir la pista de una clave utilizada para cifrar las contraseñas, y entonces tendríamos que determinar dónde almacenar la clave. Almacenamiento de la llave en el archivo de contraseñas en sí sería una mala idea, ya entonces un atacante que se apodera del archivo de contraseñas también podría descifrar todas las contraseñas en el archivo. Si la clave se almacena en cualquier lugar en el mismo sistema que el archivo de contraseña, de hecho, que el sistema todavía se convierte en un objetivo de ataque extremadamente valioso.

En lugar de dos vías, el cifrado simétrico, es mejor tener un mecanismo que permiteque le permite almacenar una versión "cifrado" de la contraseña en el archivo, y le permite verificar la contraseña que el usuario ingresa al iniciar la sesión. Usted realmente no necesita para descifrar la contraseña, siempre y cuando se puede verificar que el usuario escribió en el correcto. Cuando el usuario introduce una contraseña en un intento de iniciar sesión, puede cifrar la contraseña introducida por el usuario y compararlo con el que está en el archivo. Lo que hay es una especie de "cifrado de una vía", en la que sólo se puede cifrar la contraseña del usuario, pero

nunca es capaz de descifrar la versión de la contraseña almacenada en el archivo de contraseñas. Si almacena sólo unidireccionales contraseñas encriptadas en el archivo de contraseñas, incluso si un atacante hacerse con el archivo de contraseñas, que no sería capaz de descifrar cualquiera de las contraseñas de los usuarios.

Para ayudarle a implementar de forma segura un archivo de contraseñas, una más adecuada criptográfica primitivaque de dos vías, el cifrado simétrico es una función hash unidireccional. Una función de hash, h, p toma una cadena como entrada, y produce h (p). Debido a la naturaleza de cómo funciona una función hash, es computacionalmente imposible para determinar p de H (p). Algunas funciones hash utilizados son SHA-1 y MD5. Mientras SHA-1 y MD5 se usan comúnmente, se han producido ataques recientes contra ellos, y es recomendable utilizar funciones hash como SHA-256 y SHA-512 en su lugar. Se discuten las funciones de hash con mayor profundidad en la Sección 15.1. Un ejemplo de un archivo que almacena la contraseña de un solo sentido contraseñas hash es la siguiente:

john:9Mfsk4EQh+XD2lBcCAvputrIuVbWKqbxPgKla7u67oo=mary:AEd62KRDHUXW6tp+XazwhTLSUlADWXrinUPbxQEfnsI=joe:J3mhF7Mv4pnfjcnoHZ1ZrUELjSBJFOo1r6D6fx8tfwU=

Para cada usuario que figuran en el archivo de contraseñas anterior, un hash SHA-256 de la contraseña es almacenado. Por ejemplo, en lugar de almacenar directamente la contraseña de John, "automóvil" en el archivo de contraseñas, los almacenes de archivos 9Mfsk4EQ ... en lugar de ella. Cuando la contraseña de John necesita ser comprobada, el hash de la contraseña que ha entrado se calcula y se compara con el hash en el archivo de contraseñas, como se muestra en la Figura 9-1. La ventaja de almacenar contraseñas hash en el archivo de contraseñas es que incluso si un atacante para robar el archivo de contraseñas, ella no sería capaz de determinar que la contraseña de Juan es "automóvil” con sólo mirar el archivo.

El siguiente código muestra cómo implementar un gestor de mini-contraseña que hashes de contraseñas. Por razones de brevedad, sólo muestra los métodos que necesitan ser modificados.

Tenga en cuenta que en el código anterior, el método computeSHA () se llama con la contraseñacomo argumento tanto en el add () y checkPassword () métodos. El computeSHA ()método utiliza un objeto MessageDigest proporcionado como parte del paquete java.security. Una vez que se obtiene una instancia de un objeto MessageDigest que puede calcular hashes SHA-256, método de actualización del objeto MessageDigest () se llama con los bytes que componen la cadena de entrada (la contraseña). Entonces el hash se calcula mediante una llamada al método digest (). Los bytes hash son entonces base64 para sustituir caracteres no imprimibles para los imprimibles, y se devuelve el hash de la cadena de entrada.

9.3 ATAQUES DE DICCIONARIO “OFFLINE”

9.5 ATAQUES DICCIONARIOS “ONLINE”

En los ataques de diccionario en línea, el atacante intenta activamente usuario y contraseña combinaciones utilizando un sistema vivo, correr, en lugar de, por ejemplo, el cálculo de valores hash y comparándolos con los de algún archivo de contraseñas adquirida. Si un atacante no puede adquirir una copia del archivo de contraseñas, y se limita a la realización de dictionar líneaataques de y, que al menos le permite monitorear la contraseña del atacante adivinar. Como mencionamos en la Sección 3.2.3, si un gran número de logins fallidos están viniendo de una o más direcciones IP, puede marcar las direcciones IP como sospechoso. Intentos de conexión subsiguientes de IPs sospechosas se les puede negar, y medidas adicionales se pueden tomar para mitigar el ataque de diccionario en línea.

En los esquemas de seguridad de contraseñas que hemos considerado hasta ahora, si el usuario es el registrodesde un cliente, la contraseña del usuario se envía a través de la red al servidor. El servidor ve la contraseña en el claro. (Incluso si la contraseña se transmite a través de SSL y encriptada en tránsito hacia el servidor, la contraseña se descifra y puestos a disposición del servidor para su verificación.) Si el servidor se puede suplantar, como en un ataque de phishing (véase la Sección 2.1.3) , el imitador recibirá la contraseña del usuario. El imitador entonces puede iniciar sesión en el servidor real que afirma ser el usuario legítimo. Por lo tanto, puede valer la pena utilizar enfoques en los que el servidor puede verificar la posesión del cliente de la contraseña sin necesidad del cliente para transmitir de forma explícita la contraseña para el servidor. Pruebas con contraseña autenticado intercambio de claves (PAKE) y en conocimiento cero son ejemplos de protocolos criptográficos que pueden permitir a un cliente para probar su conocimientode una contraseña sin revelar la contraseña en sí (Jakobsson, Lipmaa y Mao 2007). Sin embargo, tales protocolos no han demostrado ser eficiente o comercialmente viable todavía, y están más allá del alcance de este capítulo.

9.6 TÉCNICAS ADICIONALES DE SEGURIDAD EN LA CONTRASEÑA.

Además del hash básica y salazón técnicas para la administración de contraseñas, también cubrimos una serie de otros enfoques que pueden ayudar a gestionar las contraseñas de forma más segura. No todos ellos pueden ser apropiadas para su aplicación, y es posible que desee probar el uso de los que tienen más sentido para ayudar a proteger su base de usuarios específico. Algunas de las mejoras que siguen pueden ser usados para aumentar la dificultad de construir un ataque

9.6.1Contraseñas fuertes

Es importante animar a los usuarios a elegir contraseñas seguras que no se pueden encontrar en un diccionario y que no son concatenaciones simples de palabras del diccionario. Exigir a los usuarios a elegir contraseñas seguras es una parte importante de frustrar los ataques de diccionario.Algunas sugerencias para crear contraseñas seguras incluyen la fabricación de ellos el mayor tiempo posible; incluyendo letras, números y caracteres especiales; y empleando contraseñas que son diferentes de los que ha utilizado en otros sistemas. También puede crear contraseñas seguras de frases largas. Por ejemplo, considera que la frase "no hay nada realmente funciona a menos que lo haríapreferiría estar haciendo otra cosa "(una cita de JM Barrie). Si es fácil de recordar talcita, puede transformarla en una contraseña comon! rWuUwrbds3. La primera letra de cada palabra de la frase ha sido utilizada, y algunos de los personajes se han transformado a los signos de puntuación, mayúsculas y fonéticamente similares y números.Sin embargo, ya que algunos usuarios no pueden elegir contraseñas seguras, es

importante para proteger el archivo de contraseñas de caer en manos del atacante, incluso si se utiliza el salado. En versiones anteriores de UNIX, el archivo de contraseña utilizada para ser legible por todos y almacenada en / etc / passwd. laarchivo / etc / passwd es todavía presente en las nuevas versiones de UNIX, pero no almacena los hashes de contraseñas o sales. En lugar de ello, los hashes de contraseñas y sales se almacenan en unaarchivo / etc / shadow que sólo es accesible para el administrador del sistema y otros usuarios con privilegios.

9.6.2 “Honeypot” Passwords

Para ayudar a los atacantes de captura que intentan introducirse en un sistema de seguridad de la contraseña, puede utilizar contraseñas simples y nombres de usuario como "miel" para atraer a los atacantes. Por ejemplo, muchos sistemas pueden tener un nombre de usuario por defecto llamado "invitados" que tiene la contraseña "guest". Uno no espera que los usuarios normales que utilizan esta cuenta de invitado.Puede configurar el sistema de tal manera que si los rios atacante para iniciar sesión en el uso de una contraseña por defecto para el usuario invitado, puede establecer que como un disparador para que su personal de la administración del sistema puede ser notificado. Cuando alguien intenta ingresar a él, usted sabe que puede ser una indicación de que un atacante está tratando de entrar en su sistema.Una vez que el personal de la administración del sistema es notificado de que alguien podría estar tratando de romper en el sistema, puede adoptar medidas para identificar la dirección IP que el atacante está viniendo. También puede permitir al atacante continuar usando la cuenta de invitado para ayudarle a aprender más sobre lo que el atacante está tratando de alcanzar.

9.6.3 Fitrado de contraseñas.

Como la mayoría de los usuarios no les guste que han elegido contraseñas o incluso sugerido para ellos, se podía dejar que los usuarios eligen contraseñas por sí mismos.Sin embargo, si un usuario elige una contraseña que está en el diccionario o identificado por y nuestro sistema de seguridad de la contraseña tan fácil de adivinar, usted podría entonces filtrar esa contraseña y requieren que el usuario elija otro.

9.6.4. Contraseñas antiguasIncluso si el usuario elige una buena contraseña, puede que no desee que el usuario utilice la contraseña que durante todo el tiempo que van a utilizar el sistema. Cada vez que el usuario introduce la contraseña, hay una oportunidad potencial que un atacante puede estar mirando por encima del hombro del usuario. Por lo tanto, se podría animar a los usuarios a cambiar sus contraseñas en determinados intervalos de tiempo-cada mes, cada tres meses, o cada año, por ejemplo. Otra forma de contraseñas "edad" es sólo para permitir que cada contraseña que el usuario opta por trabajar un cierto número de veces.Tenga en cuenta que si usted requiere que los usuarios cambien sus contraseñas con demasiada

frecuencia, podrían comenzar por escritoing abajo o haciendo otras cosas potencialmente inseguros para tratar de recordar lo que sucontraseña actual. Al mismo tiempo, si no se requiere que cambien sus contraseñas con suficiente frecuencia, el atacante tiene más oportunidades dentro de un período de tiempo determinado para tratar de obtener sus contraseñas.

9.6.5 Las contraseñas pronunciablesContraseña diseñadores de sistemas de seguridad se dieron cuenta de que a veces los usuarios quieren elegir las palabras del diccionario, ya que son fáciles de recordar. Por lo tanto, decidieron crear contraseñas pronunciables que pueden ser fácil de recordar ya que los usuarios pueden sonar a cabo, pero no serían palabras en el diccionario. Contraseñas pronunciables se componen de sílabas y vocales conectados entre sí que están destinados a ser fácil de recordar.Algunos ejemplos de contraseñas pronunciables-generados por un paquete llamado Gpw (www.multicians.org/thvv/gpw.html) -son ahrosios, chireckl y harciefy.

9.6.6 LIMITADO INTENTOS DE CONEXIÓNUsted podría dar y nuestros usuarios un número limitado de intentos de conexión antes de deshabilitar o bloquear su cuenta. La ventaja de intentos de acceso limitado es que si un atacante está tratando de entrar en la cuenta de un usuario en particular, que sólo se da un número fijo de intentos (por ejemplo, tres o cuatro). El wnside do de utilizar este enfoque es que si un usuario legítimo pasa a introducir incorrectamente su contraseña a sólo un par de veces, y luego la cuenta será bloqueada. Un usuario legítimo podrá continuación, tendrá que llamar a un número de administrador del sistema o servicio al cliente para tenerla de restablecimiento de contraseña.Otra desventaja de la cuenta de bloqueo es que da un atacante la capacidad de lanzar unAtaque DoS contra una o más cuentas. Por ejemplo, si el atacante recibe una gran cantidad de nombres de usuario en el sistema y trata de un par de intentos aleatorios para la contraseña de cada usuario, el atacante puede llegar a bloquear una gran parte de las cuentas de usuario en un sistema.

9.6.7. LOS RETRASOS ARTIFICIALESUsted podría introducir creciente retrasos artificiales cuando los usuarios intentan iniciar sesión en un sistema a través de la red. La primera vez que un usuario intenta conectarse, se presenta al usuario con el nombre de usuario y contraseña pedirá inmediatamente. Si el usuario introduce una contraseña incorrecta, puede hacer que el sistema espere 2 segundos antes de permitir que el usuario vuelva a intentarlo. Si el usuario sigue recibiendo el nombre de usuario o contraseña incorrecta, se puede tener espere 4 segundos antes de permitir que el usuario para intentarlo de nuevo. Generalizando, se puede aumentar exponencialmente la cantidad de tiempo antes de permitir que un cliente en particular con un try determinada dirección IP para conectarse a su red. Para los usuarios regulares, esto podría introducir un inconveniente. Si un usuario normal pasa a obtener su contraseña incorrecta tres veces, él puede tener que esperar en el orden de 8 segundos antes de que se les permita volver a intentarlo.Un ataque de adivinar la contraseña en línea en contra de un sistema que introduce retrasos

artificiales pueden requerir muchas IPs de probar muchas combinaciones diferentes de la contraseña de un usuario antes de que el atacante obtiene un derecho. Al introducir retrasos artificiales en el sistema, se disminuye el número de diferentes conjeturas de que el atacante puede probar en una determinada unidad de tiempo

9.6.8. ÚLTIMO INGRESOOtra mejora que se puede emplear para aumentar la seguridad de su sistema de contraseñas es que cada vez que un usuario inicia sesión, puede mostrar la última fecha, la hora, y, potencialmente, incluso la ubicación desde la que el usuario ha iniciado sesión. Usted podría educar a los usuarios a prestar atención cuándo y dónde sus últimos intentos de conexión eran. Si un usuario nunca se da cuenta de una inconsistencia entre el momento y donde ella conectados últimamente y cuándo y dónde el sistema informó que la última vez conectado, puede notificar a la administr sistema personal ación o servicio al cliente.Por ejemplo, si un usuario inicia una sesión por lo general una vez al mes desde su casa en California, sino en inicio de sesión, el sistema le informa que la última vez que se conectó fue a las 3 de la mañana, hace dos semanas en Rusia, se dará cuenta de que algo anda mal. A continuación, puede notificar al personal apropiado, y el problema de seguridad puede ser tratado de manera reactiva. Si no existiera el último mecanismo de inicio de sesión, luego de la ocurrencia del ataque no se haya dado cuenta.

9.6.8. Último ingresoOtra mejora que se puede emplear para aumentar la seguridad de su sistema de contraseñas es que cada vez que un usuario inicia sesión, puede mostrar la última fecha, la hora, y, potencialmente, incluso la ubicación desde la que el usuario ha iniciado sesión. Usted podría educar a los usuarios a prestar atención cuándo y dónde sus últimos intentos de conexión eran. Si un usuario nunca se da cuenta de una inconsistencia entre el momento y donde ella conectados últimamente y cuándo y dónde el sistema informó que la última vez conectado, puede notificar a la administr sistema personal ación o servicio al cliente. Por ejemplo, si un usuario inicia una sesión por lo general una vez al mes desde su casa en California, sino en inicio de sesión, el sistema le informa que la última vez que se conectó fue a las 3 de la mañana, hace dos semanas en Rusia, se dará cuenta de que algo anda mal. A continuación, puede notificar al personal apropiado, y el problema de seguridad puede ser tratado de manera reactiva. Si no existiera el último mecanismo de inicio de sesión, luego de la ocurrencia del ataque no se haya dado cuenta.

9.6.10. CONTRASEÑAS DE ÚNICA VEZEl último tipo de sistema de contraseñas que nos gustaría tocar se llama sistema de contraseñas de una sola vez. En todos los enfoques que hemos hablado hasta ahora, una de las cosas que le da al atacante alguna ventaja es que cada usuario utiliza sus tiempos de contraseña múltiple para iniciar sesión en un sistema. Por lo tanto, cuando se crea una cuenta de un usuario y que el usuario elige una contraseña, se le permite al usuario utilizar la contraseña varias veces para iniciar la sesión. Sin embargo, cada vez que un usuario entra en un sistema, hay una oportunidad potencial para que contraseña para ser espiado o encontrado por un atacante. Esto es

especialmente un problema si esa contraseña no ha cambiado durante un largo período de tiempo.En un sistema de contraseñas de una sola vez, cada vez que un usuario entra, se espera que el usuario inicie sesión con una contraseña diferente. El sistema de contraseña de un solo utilizado para implementar dando a los usuarios una lista de contraseñas. Estas listas fueron esencialmente pequeños libros llenos de contraseñas personalizadas para los usuarios cada vez que se inicie sesión. Por ejemplo, la primera vez que el usuario inicia la sesión, que usaría la primera contraseña en la lista. La próxima vez que inicie la sesión, ella recibiría instrucciones para usar la segunda contraseña en la lista. El sistema también podría elegir un número de contraseñas al azar y esperar que el usuario introduzca el número. Estas listas, sin embargo, se convirtió en incómodo para los usuarios. La mayoría de los sistemas de contraseñas de un solo uso hoy son aquellos en los que el usuario tiene algún dispositivo con una pequeña cantidad de potencia de cálculo que se utiliza para calcular las contraseñas. El dispositivo puede ser utilizado como una fuente de contraseñas. Los usuarios, al iniciar una sesión en un sistema, llevan a cabo la contraseña del dispositivo sola vez, leen la contraseña de ese dispositivo, y entran en el ordenador sistema. Todas las contraseñas que se generan por este dispositivo se basan fuera de algún algoritmo criptográfico. No es típicamente parte de la semilla (valor inicial) que se utiliza para generar toda una corriente de muchas contraseñas en el tiempo. Esa semilla es también conocido por el servidor. Por lo tanto, dada la hora actual y la semilla, el servidor puede comprobar que la contraseña que el usuario está introduciendo es correcta.

La funcionalidad proporcionada en estos dispositivos de contraseñas de un solo uso están ahora integrados en PDAs, teléfonos celulares y otros dispositivos móviles que los usuarios ya llevan. Contraseñas de un solo terminan siendo un muy buen sistema para garantizar la seguridad de contraseña. De hecho, algunos bancos han comenzado a dar los dispositivos de contraseña de una sola vez a algunos de sus usuarios con el fin de acceder a sus cuentas bancarias basadas en web. Con suerte, habrá más uso de contraseñas de un solo uso en el futuro.

10.2.1. CROSS-SITE REQUEST FORGERY (XSRF)

Recordemos que una página maliciosa puede causar el navegador de nuestro usuario para hacer una solicitud GET o HTTP POST para nuestra aplicación web, con parámetros de consulta o valores de campo de formulario elegidas por el autor de la página maliciosa, y que al mismo tiempo el navegador de nuestro usuario enviará a lo largo de las credenciales y / o las cookies de autenticación HTTP asociados con nuestro usuario.

Supongamos que nuestra aplicación web incluye una función que permite a nuestros usuarios cambiar su información de perfil, incluida la contraseña que utilizan para iniciar sesión en nuestra aplicación.

Esta característica se implementa como un formulario HTML como la siguiente (omitimos el formateo marcado relacionado en el ejemplo):

Cuando se presente esta forma, nuestra aplicación (en concreto, el código que maneja las solicitudes para la URL / update_profile) determina la identidad del usuario que ha iniciado sesión en la base de una cookie de sesión, y luego actualiza la contraseña almacenada para este usuario en nuestra base de datos. Ahora supongamos que hay una página en un sitio web malicioso que nuestro usuario es atraído en visión, digamos, http://www.hackerhome.org/getfreestuff.html. ¿Y si esta página contiene HTML como la siguiente?

Si Alice, nuestro usuario desprevenido, pasa a ser registrado en nuestra aplicación (es decir, su navegador tiene una cookie de autenticación de sesión válido para www.mywwwservice.com), y luego carga www.hackerhome.org/getfreestuff.html, la siguiente secuencia de eventos tienen lugar:

1. navegador carga de Alice y analiza la página de www.hackerhome.org. Tenga en cuenta que debido a la política del mismo origen, esta página no tiene acceso a la cookie

www.mywwwservice.com, ni podría inspeccionar el contenido de cualquier página que pudiera actualmente cargada desde www.mywwwservice.com en otra ventana del navegador.

2. Una vez que se carga la página, el navegador ejecuta JavaScript especificado en la etiqueta <script>. El script a su vez hace que el navegador PUBLIQUE formulario denominado evilform definido dentro del mismo documento. Tenga en cuenta que la URL de acción de la forma como se especifica en la etiqueta <form> de hecho es el / URL update_profile de nuestra aplicación, pero los valores de los parámetros publicados-en particular, la contraseña parámetro son a elección del documento malicioso alojado en www.hackerhome.org. Cuando el navegador realiza la petición HTTP POST, envía a lo largo de todas las cookies que posee en la actualidad para el dominio de la URL de la solicitud (es decir, www.mywwwservice.com). El objetivo del puesto es el invisible <iframe> en la página del atacante (es decir, la solicitud POST no hará que el navegador para navegar fuera de la página actual y Alice no tendrá ninguna indicación visible de que su navegador está haciendo peticiones a www. mywwwservice.com).

3. Cuando nuestra aplicación recibe la solicitud, se determina que la cookie enviada junto con la solicitud es una cookie de sesión válidas, e identifica y autentica Alice. Ella a continuación, procesa la solicitud como si Alice misma había originado por rellenar y enviar el formulario web en nuestra aplicación, y actualiza la contraseña que tenemos en archivo para que Alice se evilhax0r! Ahora Alice no puede iniciar sesión en su cuenta más (a menos que de alguna manera se da cuenta de lo que pasó y mira a la fuente de la página maliciosa), y lo más importante, el dueño de hackerhome.org ahora sabe la contraseña de Alicia! (6) Cabe señalar que debido a la política del mismo origen, página maliciosa del atacante no puede leer los datos relacionados con la cuenta de Alice; más bien, es posible para él para causar ciegamente el navegador de Alice para hacer una solicitud de escritura a nuestra aplicación y provocar un cambio de estado del lado del servidor relacionados con la cuenta de Alice. (Por supuesto, en este caso, la solicitud pasó a ser uno que permitía al atacante a cambiar su credencial de inicio de sesión a un valor conocido, y por lo tanto en última instancia, le dio plena leer y escribir el acceso a su cuenta.) Ya que este patrón de ataque implica solicitudes a través de los límites de una aplicación web o sitio web con los parámetros que se han especificado o forjadas por el sitio malicioso, se refiere a menudo como cross-site solicitud falsificación (XSRF comúnmente abreviado o CSRF, y, a veces también se conoce como "falsificación de referencia entre sitios ") (Burns 2005). XSRF sea preocupante en cualquier aplicación web que mantiene el estado del lado del servidor o ejecuta las transacciones del lado del servidor, en nombre de sus usuarios. Ejemplos de este tipo de aplicaciones son las siguientes:

• Las aplicaciones con características que permiten a los usuarios mantener o actualizar la información del perfil, como usuario / login ID, nombre, correo electrónico de contacto, contraseña, lista de amigos en una aplicación de red social, etc.

• Las aplicaciones que permiten a los usuarios enviar mensajes o publicar mensajes en un tablero de mensajes (una página maliciosa podría enviar / publicar un mensaje vergonzoso en nombre de un usuario desprevenido)

• Las aplicaciones que realizan transacciones financieras o de comercio electrónico en nombre de su usuarios, como las transferencias de fondos, órdenes de compras en línea, etc.

• Aplicaciones que almacenan todo tipo de datos en nombre de un usuario que podría ser maliciosamente manipulado por un atacante (de calendario en línea, listas de tareas pendientes, información personal gerentes, etc.).

6) En la práctica, el ataque es un poco más difícil: el atacante también tendría que saber de Alice ID de acceso para nuestra aplicación, y que era, de hecho, Alice y no otro de nuestros usuarios que vieron su página. Dependiendo de la situación, que podría tener algunas pistas-tal vez de Alice ID de acceso es igual a su dirección de correo electrónico, y envió un enlace a su página maliciosa a esa dirección de correo electrónico.