29 de octubre de 2010

Idea: Usar indicadores de la fuerza de la clave

Uno de los principales errores de un programador es dejar a criterio del usuario el formato o las condiciones mediante las cuales deben ser completados los diferentes campos de ingreso de datos en una aplicación. Llevado esto al campo de la seguridad, es importante entender que por mucho que le expliquemos a un usuario cómo crear una clave de acceso segura, estos no siempre están dispuestos a tomarse el tiempo de leer o escuchar nuestros consejos, aunque la falta de interés vaya en detrimento de su propia seguridad.

Es por eso que no podemos dejar bajo ningún concepto que las claves de acceso o de seguridad sean escogidas, sin la propia validación de las mismas para que cumplan con un formato relativamente seguro.

Sin embargo validar la seguridad de una clave o password no siempre es tarea fácil y la validación que pudiera ser aceptable o suficiente para otros casos no lo es tanto. Es por esto, que una modalidad muy aceptada actualmente es el uso de componentes en javascript llamados indicadores de fuerza de la clave o "password strength indicators" con los cuales los programadores podrán desarrollar mejores y mas ricas interfaces a la vez que mejorar drásticamente la fuerza de las claves de sus usuarios.


A continuación presento un listado de interesantes sitios en los que podrás conseguir componentes de este tipo de fácil adaptación a tus aplicaciones:
  1. jQuery Password Strength Meter
    http://mypocket-technologies.com/jquery/password_strength/
  2. jQuery Password Strength Meter Plugin
    http://phiras.wordpress.com/2007/04/08/password-strength-meter-a-jquery-plugin/
  3. Enzoic Password Meter
    https://www.enzoic.com/free-password-strength-meter/
Para los programadores que usan ASP.NET Microsoft provee incluido en el Ajax Control Toolkit un componente muy útil denominado PasswordStregth que encapsula varios tipos de comportamiento personalizables.

Todos estos componentes son utilidades client-side (del lado del navegador). Recuerden además utilizar del lado del servidor un hash suficientemente fuerte (SHA256, Whirpool) y preferiblemente usar técnicas de "salt key" para prevenir el uso de Ataques por Diccionario y Rainbow Tables.

Hasta la próxima.

26 de octubre de 2010

Phishing: El parásito que evoluciona permanentemente.

El Phishing ya se ha convertido en un parásito dañino de nuestras aplicaciones y sistemas en Internet. Uno de los ejemplos más claros y mas actuales se refiere a que ahora ataca a cualquier sistema en el que pudiéramos colocar nuestros datos personales y no solamente a las redes sociales sino hasta a los sistemas más pequeños como por ejemplo sistemas de clasificados en línea y otros que parecieran estar exentos de este tipo de amenaza, nada más lejos de la realidad.

Según el Grupo de Delitos Telemáticos de la Guardia Civil española, los casos de suplantación de identidad han llegado a atacar directamente a sistemas de clasificados y venta en línea, en los cuales el usuario coloca una oferta, como por ejemplo la venta de una casa. Una vez colocada la oferta el usuario recibe dias después un enlace por e-mail que le advierte que hay un posible cliente interesado o que alguien ha solicitado información sobre el producto anunciado, por lo que no duda ni un instante en hacer clic sobre el enlace que lo lleva a una página falsa copiada del sistema de ventas o clasificados en línea en la que se le solicitan los datos nuevamente.

¡El resto es historia vieja!

Como podrán apreciar, la seguridad web no es un tema específico dedicado a bancos y aplicaciones transaccionales. Hoy en día cialquier sitio puede ser víctima de un ataque o bien para obtener los datos del usuario como en el ejemplo anterior, o bien para servir de plataforma de lanzamiento de la amenaza, porque pueden ustedes suponer con mucho acierto que los atacantes no colocan este tipo de sitios falsos en servidores propios registrados a su nombre.

El enlace a la página del Grupo de Delitos Telemáticos de La Guardia Civil Española en el que se trata el tipo de estafa es el siguiente: https://www.gdt.guardiacivil.es/webgdt/alertas_gdt.php?id=106


Seguimos en contacto...

25 de octubre de 2010

Be smarter than John - Se más listo que John!

Muy interesante esta campaña de F-secure en la que se muestra a un usuario, un tal John, entregando los datos de su Facebook, Twitter y tarjetas de crédito a todo el mundo con carteles en las estaciones del metro y plazas de importantes ciudades europeas.

Aunque es una forma exagerada y llamativa de hacerlo, John solo está haciendo lo que mucha gente hace al dejar sus claves de acceso y datos personales al alcance de todos...




Trata de ser más listo que John!

Hasta la próxima!

20 de octubre de 2010

Evercookie: ¿Una cookie virtualmente imborrable?

Un nuevo desarrollo pone los pelos de punta a los programadores web, ya que no es fácil entender las repercusiones que este puede tener en lo referente a la privacidad de los usuarios en línea y como todo descubrimiento importante, puede ser utilizado para bien o para mal...

Se trata de los denominados Evercookies, o cookies virtualmente imborrables.

Para refrescar la memoria de los lectores, una "cookie" no es más que un pequeño archivo de texto que un desarrollador puede introducir en nuestro equipo a través del navegador y controlado por este, para poder guardar detalles importantes de navegación que solo le interesen específicamente al sitio que los guarda, como por ejemplo datos acerca de los gustos del usuario o preferencias de este, para teóricamente agilizar la navegación y presentar interfaces más inteligentes que se adapten mejor a nuestros gustos y usos. Por ejemplo mediante un cookie el sitio puede saber si el usuario ya ha votado en una encuesta para no presentársela nuevamente, si pertenece a un tipo de usuarios y enviarlo directamente a su área de interés, y hasta para saber si ya ha visto una cantidad de veces una publicidad determinada. La vida en la web sin cookies sería muy aburrida.

Los cookies además tienen muchas otras utilidades no tan obvias, por ejemplo controlar el rastreo de sesión a lo largo de las diferentes páginas de una aplicación en línea, ayudarnos a guardar los artículos que vamos seleccionando en un carrito de compras y muchas más. Inclusive muchos programadores que dicen no usar cookies los usan sin saberlo cuando acceden a la variable de sesión de un usuario de un lenguaje de desarrollo web.

Volviendo al nuestro punto de interés, la ventaja a nivel de privacidad con respecto a las cookies, es que cuando  el usuario lo desee puede borrarlas y punto. De esta forma los sitios que las colocaron pierden el rastreo que pudieran hacer mediante estas y el usuario navega "anonimamente" o lo más parecido a ello que puede.

El problema es que los Evercookies, además de ser una cookie convencional, usan entre 8 y 12 tipos de repositorios adicionales en el navegador para colocar la información (dependiendo de la viabilidad en cada caso), y si borramos ocho de ellos con que solo quede uno activo los otros se vuelven a crear.

Para aquellos interesados en verificar a fondo los nueve repositorios son los siguientes:


  1. Estandard HTTP Cookies
  2. Local Shared Objects (Flash Cookies)
  3. Silverlight Isolated Storage 
  4. Guardar cookies en valores RGB  auto-generados, colocados en PNGs cacheados por el navegador usando el tag de HTML5 "Canvas" para leeer los pixels (cookies) de nuevo.
  5. Guardando cookies el el Historial de Navegación 
  6. Guardando cookies en  HTTP ETags 
  7. Guardando cookies en el Web cache 
  8. window.name caching
  9. Internet Explorer userData storage
  10. HTML5 Session Storage 
  11. HTML5 Local Storage 
  12. HTML5 Global Storage 
  13. HTML5 Database Storage mediante SQLite
¿Interesante?
Más de los Evercookies en otras entregas...

19 de octubre de 2010

Las Botnets y el Distributed Brute Force Attack

Para empezar definamos de manera breve qué es una Botnet: Según Wikipedia Botnet es un término que hace referencia a un conjunto de robots informáticos o bots, que se ejecutan de manera autónoma y automática. Normalmente este tipo de redes de bots son asociadas con prácticas fraudulentas y se forman infectando gran número de ordenadores mediante troyanos ubicados en software obtenido de forma ilegal y otros vectores de infección. Una vez creadas su "amo" o "botmaster" puede controlar los ordenadores infectados mediante instrucciones que envía a los mismos por diferentes medios como por ejemplo IRC. Estas redes de ordenadores "zombies", son utilizadas al unísono con fines poco éticos, los cuales hasta hace poco tiempo se limitaban al envío de SPAM y a la generación de DDoS (Distributed Denial of Service).


Los amos de las Botnets, las ofrecen al mejor postor, y de esta forma un tercero logra por ejemplo enviar gran cantidad de SPAM desde una lista enorme de equipos lo cual es muy difícil de bloquear, o tratar de "colgar" un servicio en un servidor determinado, haciendo una enorme cantidad de solicitudes al mismo de forma que este se vea imposibilitado de atender los requerimientos reales.


Sin embargo actualmente se han conseguido otros fines para las Botnets, y uno de los que más preocupa es el Distributed Brute Force Attack, o ataque por fuerza bruta distribuido para obtención de passwords de servidores, servicios e inclusive a web transaccionales.


Lo que en realidad hace muy difícil manejar esta técnica de intrusión, es el hecho de que las solicitudes provienen de diferentes equipos, por lo cual un bloqueo por número IP no sería muy efectivo. 


Esta técnica de Distributed Brute Force Attack (DBFA) ha resultado muy eficiente en los últimos meses y han sido muchos los sitios a los que se les han violado sus servicios FTP, con el fin de conseguir plataformas de lanzamiento para ubicar los sitios falsos para ataques de phishing o pharming (entre otros tipos de ataques).


Esto demuestra que ningún sitio o aplicación web está a salvo de ser atacada, ya que si el ataque no se efectua directamente a la aplicación, el sitio puede ser utilizado para ensamblar ataques mayores o más "rentables".


¿Cómo podemos evitar el Distributed Brute Force Attack?
  1. Para empezar nunca es malo tener una contraseña fuerte, sobretodo en estos casos y además de fuerte larga, es decir de al menos unos doce caracteres, con todas las características de una buena contraseña que todos ya sabemos (caracteres especiales, números, mayúsculas y minúsculas...) Si quiere verificar que tan segura es su contraseña puede utilizar el verificador de contraseñas de Microsoft 
  2. Desactivar los protocolos FTP y SSH si no se están usando. No es necesario tener un servidor a la escucha permanentemente, si tenemos la posibilidad de desactivarlo y activarlo nuevamente cuando lo necesitemos. En el caso de los servidores dedicados, simplemente hay que apagar y encender el servicio cuando lo necesitemos. Es absurdo tener el servicio activo si apenas lo usamos una vez cada dos o tres meses. En el caso del hospedaje compartido, siempre tenemos la opción de apagar y encender el servicio FTP desde el panel de control.
  3. Controlar crecimientos inapropiados en el archivo de logs del servicio FTP. Lógicamente esta opción no está a la mano para aquellas aplicaciones web en servicios de hospedaje compartido, ya que el archivo de logs FTP solo puede ser visto por el administrador del servidor.
  4. Limitar el número de conexiones concurrentes de FTP y SSH en el servidor, pero sobretodo eliminar la posibilidad de conexiones ilimitadas. La cantidad máxima de conexiones simultáneas deberá ser calculada en relación a las necesidades del servicio. A menor cantidad de conexiones simultaneas permitidas el tiempo para lograr descubrir el password de acceso será exponencialmente mayor.
  5. Ubicar el servicio FTP o SSH en un puerto no convencional (ejemplo 2121).
  6. Evitar el escaneo de puertos por medio de un firewall. Si no hay servicio FTP visible simplemente no hay victima.
  7. Si es posible, restringir la máscara de números IP con acceso al servicio FTP o al SSH.
  8. Y como siempre, cambiar la contraseña cada tanto. Cambiarla cada 3 a 4 meses es suficiente. Pero lo más importante, no usar la misma para todos los servicios FTP a los que tenemos acceso.
Como verás algunas de las anteriores soluciones anteriores no son aplicables en todos los casos, pero el uso de al menos tres de ellas será suficiente respaldo para la gran mayoría de los casos.

Sin embargo, a medida que este tipo de ataques se hace más efectivo, el problema que se plantea es que pudiera ser utilizado también para transgredir aplicaciones web transaccionales o de banca en línea. Sin embargo un sistema de banca en línea que se respete, debe por lo menos bloquear los IPs de los sistemas que intenten acceder erróneamente más de un número determinado de veces. Sin embargo aunque parezca obvio, he podido comprobar que algunos de estos sistema si bien no son la mayoría, no tienen este tipo de control.

Hasta la próxima...

18 de octubre de 2010

Seguridad Web y Google: Gruyere

Es imposible pensar que Google podía faltar a la cita que tiene con todos los programadores a nivel mundial en lo referente a publicar algún tipo de documento para educar a los mismos en el proceso de generación de código seguro.

Pero Google no se conformó con hacer alguno que otro documento, sino creó toda una serie de cursos especializados en seguridad web en lo que se conoce como Google Code University , desarrollando toda una sección de cursos acerca de seguridad web a los que puedes acceder en http://code.google.com/edu/security/index.html

Una aplicación llena de agujeros
Entre estos cursos aparece una muy interesante aplicación llamada Gruyere hecha especialmente para que los programadores puedan aprender cómo son realizados los ataques  las aplicaciones y tomar las medidas pertinentes en su propio código.

Claro, ya se que algunos de ustedes dirán que han utilizado el  proyecto WebGoat de OWASP (Open Wen Application Security Proyect) a la que nos hemos referido en otros artículos pero este caso es algo diferente.
La diferencia primordial entre WebGoat y Gruyere, es que el segundo no necesita ser instalado en un equipo, ya que se puede ejecutar en línea sin necesidad de instalar la aplicación y ponerla en marcha, lo que es para muchos usuarios una ventaja, aunque para otros pudiera ser una limitación. 

La segunda diferencia es que WebGoat está desarrollada en JSP y Java bajo Tomcat, mientras Gruyere está hecha en Python. Esta puede ser una importante diferencia a la hora de tomar una decisión.

Sin embargo en ambos casos el lenguaje en que han sido desarrolladas no es lo importante a menos que quisiéramos ver el código de "como no debemos hacerlo", lo importante es su capacidad de explicarnos paso a paso como los errores o descuidos que comúnmente cometemos a la hora de programar pueden convertirse en nuestro peor enemigo.

Me gustó mucho la forma en que Gruyere explica el procedimiento del XSS en sus varias versiones aunque debo reconocer que WebGoat me pareció más completa y su interfaz es quizás más trabajada (posee incluso un instalador para Windows ). Sin embargo, la capacidad de que la aplicación pueda ser vulnerada directamente en línea le otorga a Gruyere un extra que no posee WebGoat. No se preocupen, la aplicación puede resetearse y además corre en un proceso de "sandbox" que no permite que puedan afectar a otros usuarios mientras ustedes cometen errores y dan sus primeros pasos, ya que cada usuario está ejecutando una copia personal.

Google al igual que OWASP no solo ha desarrollado esta aplicación sino muchas plantillas, presentaciones y otros tipos de material didáctico que valen la pena ser leidos, por lo que les recomiendo que visiten  http://code.google.com/edu/security/index.html y se pongan al tanto con lo que Google tiene que decirnos en cuanto a seguridad web, cuyo equipo seguramente algo de experiencia debe tener en el tema. ¿Cierto? ;)

Hasta la próxima!

17 de octubre de 2010

Guías de Desarrollo Seguro de OWASP

Las amenazas constantes a las aplicaciones web, el crecimiento de cada vez más veloz de las plataformas desarrolladas en línea y una creciente evolución de lo que se conoce como "Aplicaciones en la Nube" o "Cloud Computing" son razones de peso para pensar en orientar nuestros esfuerzos a ser programadores más "seguros".

Programar de forma segura en la web, amerita una serie de conocimientos acerca de una gran cantidad de vulnerabilidades que pueden ser explotadas por los atacantes y cómo prevenirlas, por lo que si eres programador, diseñador web o estás de alguna manera involucrado con el desarrollo de aplicaciones web, es muy posible que ya hayas enfrentado algún problema de seguridad en alguna de las aplicaciones web que has desarrollado.

Por tanto, es necesario para evitar que nuestras aplicaciones sean fácilmente vulneradas y darle a nuestros clientes la seguridad que necesitan, replantear algunos aspectos acerca de la forma en que vamos a crear dichas aplicaciones de ahora en adelante.

Para mejorar la forma en qué desarrollamos nuestras aplicaciones desde el punto de vista de la seguridad, OWASP ha colocado en línea desde hace ya varios años una guía en varios idiomas destinada al aprendizaje de técnicas de seguridad. 

Ya está en línea la versión de esta guía del 2010 en la dirección: http://code.google.com/p/owasp-development-guide/wiki/Guide. Sin embargo esta versión aun no está disponible en castellano, aunque puedes bajar en formato pdf la versión anterior aquí: http://www.owasp.org/images/b/b2/OWASP_Development_Guide_2.0.1_Spanish.pdf

Como todo lo que desarrolla OWASP, estás guías son completamente gratis.

9 de octubre de 2010

Ataques por Diccionario (2): ¿Que son lo "Rainbow Tables" o Tablas de Arcoiris?

Debido al interés que ha creado el anterior artículo "Ataques por Diccionario (Dictionary Attack) ¿Como prevenirlos?" he llegado a la conclusión de que es necesario explicar un término que tienen mucho que ver con los tipos de ataques mencionados en el artículo: ¿Qué son los Rainbow Tables?

Algunos lectores me expresaron que los ataques por diccionario usualmente estaban limitados a una serie claves "débiles" que los usuarios no deberían usar. Eso es cierto solo en parte, ya que depende del tipo de diccionario que se use, y es precisamente aquí en donde entra la definición de los "Rainbow Tables".

Los "Rainbow Tables", son un conjunto de tablas de "hashing" muy extensas, en las que se utilizan todo tipo de combinaciones de caracteres especiales junto con una serie de claves de acceso comunes convirtiéndolas en no tan comunes. Imaginemos una de las claves mas inseguras que se puede utilizar como por ejemplo "administrator", y reemplacemos simplemente la vocal "a" por el símbolo "@". Obtendríamos como resultado "@dministr@tor" lo que ya empieza a ser una clave algo más compleja de adivinar. Así podemos seguir cambiando la "o" por un cero, la "i" por un uno o una L, etc...

Ya vamos entendiendo el porqué del uso de la palabra "rainbow" (en castellano arcoiris), debido a que la idea es producir una gran cantidad de combinaciones de "hashes" que utilicen inclusive caracteres especiales, así como se combinan los diferentes colores del arcoiris para producir cualquier color visible.

Los Rainbow Tables tienen un solo problema, puede llegar a tener tamaños superiores a los 2 GigaBytes, por lo que normalmente no se encuentran versiones de los mismos en Internet como en el caso de los diccionarios de "hashing" simples, por lo que son utilizados casi siempre en el equipo del atacante una vez que tiene los hash en su poder. Sin embargo, puedes bajar un generador de "Rainbows Tables" para comprobar la eficiencia de las claves y los métodos de defensa que utilizas aqui.

Cómo en el artículo anterior la mejor técnica de prevención consiste en el "Salting" o uso del "Salt Key" que como también mencionamos consiste en agregar a las claves antes de calcular los "hash" un prefijo o sufijo que deberá agregarse cada vez que se quiera verificar la autenticidad de la misma.

Hasta la siguiente...
\backslash


Ataques por Diccionario (Dictionary Attack) ¿Como prevenirlos?

Indudablemente los programadores conscientes de la importancia de proteger los datos del usuario evitan incorporar datos como claves de acceso e información personal delicada en formato de texto plano sobre un archivo o en una base de datos, ya que en caso de intrusión en el sistema dicha información podría caer en poder del atacante y poner en riesgo al usuario. Punto a parte, si usted aún guarda las claves de sus usuarios en texto plano en una base de datos o archivos de texto, debiera plantearse actualizar sus conocimientos a nivel de seguridad.


El mejor método para evitar tener la responsabilidad de guardar claves de acceso es precisamente no guardarlas, por lo cual se hacen de gran utilidad para este tipo de casos los algoritmos de HASHing o hash, que mediante fórmulas matemáticas sofisticadas obtienen huellas únicas irrepetibles para cualquier tipo de cadena de texto. Quizás lo más importante que pueden ofrecer estos algoritmos es que no son reversibles, por lo que se les llama comúnmente algoritmos de cifrado de una sola vía. Esto significa que usted puede obtener una firma única como resultado de una cadena de texto sometida a este tipo de algoritmos, pero no puede obtener la cadena de texto a partir del resultado obtenido.


Hay muchos algoritmos de "hash" al alcance de los programadores y en algunos casos forman parte de las librerías de cifrado de los entornos de programación como Java y .NET por citar solo algunos. Ejemplo de los anteriores son MD5 (Message Digest Algorithm 5), SHA1 (Secure Hashing Algorithm 1), Whirlpool y otros.


Sin embargo no necesariamente el usuario está seguro si usted usa alguno de estos algoritmos, ya que también se producen lo que se denominan Ataques por Diccionario (Dictionary Attack). Este tipo de ataques consiste en utilizar bases de datos con los hash resultantes de cifrar los tipos de claves de acceso más comunes. 


Ejemplo práctico: Usted puede conseguir este tipo de bases de datos inclusive en línea. Si tiene dudas intente introducir el siguiente hash MD5(en negritas): ff9830c42660c1dd1942844f8069b74a en el diccionario en línea de este interesante enlace y verá como se obtiene del diccionario la clave "root123". Impresionante ¿no?


¿Cómo? ¿No era que los algoritmos hash son irreversibles?
Si lo son, pero los resultados de los mismos para cadenas de texto conocidas se pueden guardar en diccionarios. Simple y efectivo.



¿Cuál es entonces la solución para proteger las claves de los usuarios de este tipo de ataque?
Indudablemente si hablamos de claves en un diccionario estamos siempre hablando de claves deficientes o pobres. Una buena parte del problema se reduciría radicalmente si los usuarios escogieran claves más fuertes y menos evidentes (como para que no existan en un diccionario). Sin embargo todos los programadores sabemos que contar con el esfuerzo del usuario no siempre es la mejor opción por lo que la solución no puede depender de ellos. Por ejemplo estos diccionarios contienen las fechas de los últimos 40 años en formato hash. Es por eso que una simple fecha es una clave de acceso de las más ineficientes.


La mejor solución para evitar este tipo de ataque es utilizar lo que se conoce como "Salt Key" que para el caso que nos incumbe (la definición criptográfica puede ser más compleja) no es más que una cadena de texto que se agrega al texto original antes de ser cifrado. De esta forma el atacante no puede comparar los hash ya que necesitaría un diccionario completamente nuevo. Lo más importante es que aunque el atacante llegara a conocer el "Salt Key" no le serviría de absolutamente nada ya que los diccionarios existentes no tendrían las cadenas resultantes de utilizarlo. El programador solo tiene que tener en cuenta agregarlo de igual forma cada vez que compare el hash guardado con el producido por la clave recibida a la hora de validar la clave.


Recuerde que como el proceso de hash no es reversible, simplemente habría que crear un diccionario nuevo para cada "salt key" utilizado. Usted puede inclusive reforzar la técnica usando un "Salt Key" variable, pero dejaremos este truco avanzado para otra oportunidad. Espero que esta simple información le sea útil.

Hasta la próxima.
\backslash

1 de octubre de 2010

Entropía del password vs. cambio periódico del mismo.

Es un hecho que una clave de acceso es más segura a medida que su "entropía" es mayor. Al hablar de entropía hacemos mención a un término físico expresado en las leyes de la termodinámica que para efectos de este caso podemos entender como "desorden". Es cierto entonces que una clave de acceso mientras más "desordenada" es, también es más segura. Mientras menos podamos asociarla al concepto de "orden" como por ejemplo a una palabra, a una fecha, a una secuencia numérica o a cualquier otro tipo de cadena de caracteres "ordenada", más segura será. Pero es también un hecho que mientras más entrópica o desordenada sea la clave de acceso, más difícil será de recordar.

Para lograr una clave de acceso entropicamente adecuada, solicitamos a los usuarios claves "fuertes" que contengan al menos ocho caracteres, que dichos caracteres sean números y letras mezclados, que se utilicen mayúsculas y minúsculas combinadas y hasta que se agreguen algunos caracteres especiales o de puntuación en la combinación.

Sin embargo, los usuarios cometen un "error" muy grave: Una vez que descubren y memorizan una clave entrópicamente apropiada, la utilizan en diferentes sitios, por lo que aumentan radicalmente su exposición y por enden reducen sustancialmente su eficiencia. Si uno de los sitios es vulnerado, o el usuario entrega sin darse cuenta sus credenciales a un atacante, podría estar comprometiendo su información en otros sitios, por lo que el mayor nivel de entropía de dicha clave no le ayudaría en nada.

Basados en lo anterior, los desarrolladores y expertos en seguridad someten a los usuarios a cambios periódicos de clave de acceso, y la mezcla de este procedimiento junto con la solicitud de un nivel de entropía mayor lleva sin duda alguna a una gran cantidad de claves olvidadas y procesos de recuperación sin fin.

En algunos casos estos procesos de recuperación son simples, pero en otros como por ejemplo en la banca en línea pueden llegar a ser muy complejos, ya que el usuario debe demostrar de forma más que convincente que en realidad es quien dice ser. Estos procesos pueden significar costos ocultos para las empresas que regentan las aplicaciones en línea y también para sus usuarios.

Por tanto, resolver esta encrucijada es importante, pero no es asunto de una solución mágica. Debemos aplicar ciertos correctivos en nuestra aplicación como por ejemplo:

Proteger la visibilidad del password:
No estamos hablando de los conocidos asteriscos que son por defecto necesarios a la hora de escribir la clave, sino de no solicitarla sin antes validar algún otro factor además del identificador del usuario. Muy populares se están haciendo los sistemas de validación en dos capas, en los que solo si se ha cumplido con dos factores de autentificación (ejemplo: login, e-mail, otros...) se solicitará entonces la clave de acceso en una segunda fase, lo que reduce de forma radical la cantidad de veces que esta es expuesta. Este sistema presenta varias ventajas adicionales que no son parte de este artículo y que mencionaremos en otra oportunidad.

Solicitar renovación de la clave por cantidad de usos:
El tiempo de vida de una clave de acceso es un parámetro muy relativo para medir su fuerza. El usuario puede haberla usado una o dos veces en el lapso de varios meses y se le estaría obligando a cambiarla sin necesidad. Es él quien debe decidir cuantas veces quiere usarla o cuanto tiempo desea que sea válida antes de que se le solicite renovarla. Colocar una selección del tiempo de vida y la cantidad de veces de uso a la hora de renovar la clave, permite al usuario responsabilizarse por su seguridad, y no podrá culpar al aplicativo cuando este le solicite renovación.

Verificar la entropía de la clave en el momento de su creación:
Es necesario que el programador muestre al usuario que tan fuerte es la clave que ha escogido. Existen componentes que pueden mostrar barras con porcentaje y colores a medida que el usuario va insertando caracteres de la clave, lo que combinado con la selección de tiempo de vida y cantidad de usos permite que el usuario configure el proceso de creación y renovación a su medida. Programando un poco más podremos ofrecer un mayor rango de usos y más tiempo de vida para claves más fuertes y lo contrario para claves más débiles.

Estas no son soluciones definitivas, sin embargo han demostrado reducir el problema de la recuperación de las claves de acceso de forma considerable. Si a esto agregamos un manual acerca de como proteger las claves de acceso en el que se indique que hacer y qué no hacer con ellas, además de unas formas creativas de crear claves entrópicamente fuertes pero fáciles de recordar, de seguro tendremos el problema controlado por un largo tiempo.

Entradas populares