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.

Entidades Financieras Latino Americanas tardan demasiado en implementar soluciones a los problemas de seguridad de la banca en línea.

No hay duda que la seguridad en Internet debería ser una de las mayores preocupaciones de las entidades bancarias y financieras de nuestra América Latina. Sin embargo la velocidad de reacción ante los diferentes métodos de usurpación de identidad, las amenazas de seguridad latentes y los crecientes tipos de fraude en línea por parte de dichas entidades es por decirlo de un modo muy amigable, "demasiado lenta".

Existen en las entidades financieras de América Latina ciertos factores que impiden que un sistema de banca en línea se actualice y mejore a la velocidad requerida, en algunos casos haciendo que la ausencia de dichas mejoras cuesten tanto a las entidades como sus usuarios sumas de dinero varias veces superiores a los costos de implementar las soluciones requeridas.

¿Cuáles son estos factores?

Resistencia al cambio:
Es indudable que este factor está presente siempre que se desee hacer un cambio de relativa envergadura en un sistema. Sucede que según las juntas directivas de las entidades, hasta que no se demuestre que el sistema tiene un error no es necesaria la corrección del mismo y mucho menos el cambio. Es decir, según aquellos que se dedican principalmente a hacer dinero con nuestro dinero, hay que esperar a que se genere la estafa o el problema para que se tomen las medidas necesarias. En asuntos de seguridad definitivamente no se puede ser reactivo, hay que ser pro-activo y prevenir.

Personal de sistemas no actualizado:
El personal de sistemas de las entidades financieras de nuestra región en su gran mayoría cumplen con los estándares de lo que los hackers denominan como "code grinders". Este término despectivo es aplicado por los hackers al personal de sistemas que trabaja de 9 am. a 5 pm. y viste con camisa de cuello y corbata, para primordialmente crear rutinas de pago de nómina en RPG en "pantalla verde" u otros "horrores similares". Definitivamente no se pueden combatir las amenazas existentes en la actualidad con las herramientas que se vienen usando en algunas entidades desde hace más de 15 años.

Velocidad de reacción lenta o nula:

¿Se ha preguntado cuanto tiempo tarda una entidad financiera en responder correctamente ante un ataque de phishing? La falta de procesos de respuesta, la lentitud de reacción, los horarios inflexibles y otros factores, hacen que la entidad normalmente empiece a responder ante un posible ataque con un retardo de hasta 72 horas o más en algunos casos. En esos casos el daño mayor ya ha sido causado y probablemente el capital se encuentre para entonces en alguno de los países del otro lado del globo. A esto hay que agregarle el tiempo necesario para colocar los ajustes necesarios en línea que deben pasar por protocolos de validación y puesta en marcha completamente ineficientes para estos casos de emergencias. Las estructuras actuales no se ajustan a la velocidad de respuesta ante un ataque.

Protocolos de control de versiones y puesta en marcha demasiado lentos:

Colocar ajustes en línea en la aplicación que usted normalmente usa es un proceso largo y tedioso. Lógicamente debe ser así para garantizar que la aplicación funcione correctamente. Para explicarlo en forma rápida, los cambios y ajustes normalmente pasan por las etapas de "desarrollo" y "control de calidad" antes de llegar al público o a lo que se conoce como "ambiente de producción" o ambiente definitivo. Cada proceso es controlado por personal diferente, y cada personal tiene su propio tiempo de reacción. No existen procedimientos de emergencia que permitan saltar los controles de código ante ataques como el phishing o el pharming, lo que hace que el tiempo de reacción ante el ataque convierta dicha reacción en inútil.

Bajo presupuesto para las aplicaciones y personal de Banca en línea:

En algunos casos en nuestros países no se ha entendido aún el proceso que está llevando a las entidades a la creación de las oficinas virtuales que hoy en día llamamos "Banca en línea". La gran mayoría de los bancos de Latino-américa, tienen más usuarios registrados en línea que en cualquiera de sus agencias principales, sin embargo la "oficina de servicios virtuales" o "unidad de banca electrónica" es sin temor a equivocarme la que menos personal tiene. Al parecer es el negocio del siglo manejar altos volúmenes de transacciones y dinero con la menor cantidad de gastos posible. Dichas unidades no generan siquiera el 10% de los costos operativos de una agencia promedio. Sin embargo pareciera que las entidades están cometiendo los mismos errores que llevaron a la explosión de la burbuja de la primera ola de Internet. Seguro esta vez no les estallará la burbuja en la cara, pero deberán pagar altas sumas para recuperarse de los golpes recibidos por las amenazas actuales. Vemos todos los días como algunos bancos gastan enormes sumas en publicidad para crear el hábito de cambiar nuestra clave, por no haber dedicado ni un céntimo en crear estructuras y sistemas más eficientes para protegerla.

La idea de que el usuario es responsable de sus actos en Internet:

Las entidades y bancos no están renunciando aún al concepto errado de que "lo que le suceda al usuario en su computador es problema exclusivamente de él". En una buena cantidad de países las cortes están fallando a favor de los usuarios que han sido víctimas de phishing y otro tipo de estafas, con argumentos que explican que las entidades tienen aplicaciones en línea fáciles de copiar tanto visual como operativamente y que estas no protegen al usuario al momento de realizar sus transacciones. Más de el 90% de las interfaces de acceso bancarias en línea no resisten un simple copiado por Internet Explorer, y esta es solo una de la gran cantidad de vulnerabilidades que no permiten al usuario distinguir entre un sitio original y uno fraudulento.

En fin para no alargar este documento, es necesario aclarar que las aplicaciones de banca en línea en nuestra región son manejadas aún como complementos del negocio bancario, y por ejemplo son llevadas como se podría manejar quizás las redes de cajeros o los centros de atención telefónica. No se ha percibido aún el hecho de que como en muchas otras industrias y servicios las aplicaciones en Internet han dejado de ser un medio para convertirse en la industria misma. Es necesaria una revisión a fondo de las políticas aplicadas a la banca en línea en nuestros países y con ella la creación de nuevo personal capacitado, no renuente al cambio, que pueda adaptarse a los nuevos procesos rápidamente y con ello a una nueva manera de hacer las cosas que empieza por cambiar el formato de los horarios de trabajo y se basa principalmente en el culto a una mentalidad creativa y abierta.

En el camino muchas entidades relativamente fuertes se están preocupando porque su gran masa de usuarios no tiene mayor monto de dinero en sus cuentas pero en cambio moviliza mucho. ¡Claro es fácil de explicar! Es preferible un banco pequeño pero con una interfaz en línea más segura para guardar nuestro dinero aunque no tenga la gran red de agencias o cajeros que necesitamos ya que siempre podremos hacer transferencias del dinero necesario a otra cuenta en otro banco cuando necesitemos dichos servicios. Gracias a Internet no necesitamos desplazarnos de una agencia a otra para hacerlo. Sin embargo aunque parezca simple aún no se han dado cuenta de esto.

Para terminar, no está de más recordarle a los empresarios de las entidades bancarias de nuestra zona, que en Internet en pez grande no siempre se come al pequeño, porque solo para empezar, en nuestro navegador web no se percibe el tamaño del pez.