Seguridad en las aplicaciones Web, enfocada en los usuarios

La idea de este artículo no es, para nada, proveer formas de asegurar un sitio o aplicación web contra ataques de terceros, sino más bien de repasar consejos básicos sobre que (no) hacer, para mantener la confianza de nuestros usuarios.

Aquellos que no sean desarrolladores, podrán utilizar la información vertida en este artículo para evaluar cuanta seguridad les proveen los sitios vía web que utilizan a diario (desde redes sociales, webmail, y demás).

Paranoia
Para poder hablar de seguridad, muchas veces es necesario adoptar una mirada paranoica… es decir, desconfiar de todo. Ojo, esto no quiere decir que desconfíen de mí cuando doy estos consejos, pero tampoco les digo que apliquen plena confianza en lo que les recomiendo… sino más bien que lo tomen como un dato, para que luego ustedes amplíen la información, y puedan hacer comentarios acorde a lo aprendido.
Si pienso en lo que he vivido por Internet, desde el momento que empecé a navegar (en conexiones a pedales por dial-up), tengo que admitir que muchas prácticas que listaré en el artículo… no se daban al comienzo, pero que si fueron apareciendo con el pasar de los años.
Aún así, muchas aplicaciones que tienen registro de usuarios, todavía no toman las medidas necesarias para proteger a estos, y peor aún, a veces los mismos dueños de dichas aplicaciones suelen abusar de dicha escasez de seguridad.

Registro de usuarios
Normalmente, cuando nos damos de alta en un sitio web, solemos recibir un correo de confirmación en donde nos invitan, o bien a ingresar en un enlace… o en todo caso, a probar nuestro recién creado usuario.
En el caso de que recibamos una confirmación, estas suelen ser para validar nuestra aceptación de dicho registro, lo cual ya nos demuestra cierto compromiso por parte del sitio en cuanto a sus usuarios. Si bien puede parecer de poca importancia, esto nos demuestra -a grandes rasgos- que el sitio no aceptará a miembros que no confirmen una asociación correo=usuario.
En el caso de que no recibamos una confirmación, ya tenemos un problema, dado que cualquier persona que lo desee podría dar de alta un usuario en dicho sitio, sin que tenga consentimiento del dueño de la cuenta de correo (o sea, nosotros). La prueba de esto no está muy lejos de nosotros, simplemente encontrar un sitio que cumpla con esta condición, y luego tratar de suscribir algún conocido sin que este sepa.
Aún así, este aspecto a veces se pasa por alto (y se justifica), por el simple hecho de facilitar el registro de usuarios (algunos dicen que es para minimizar el problema del nuevo usuario, otros piensan que es para maximizar la base de usuarios…).
Otro aspecto a tener en cuenta (y el que llevó a la creación de este artículo), es el envío de usuario y clave a nuestro correo, ni bien nos registramos. Este aspecto lo podríamos discutir como ser de baja (in)seguridad, pero si pensamos en la posibilidad de que nuestra cuenta de correo es accedida desde una máquina pública, esto nos deja con la posibilidad de que alguien logre acceder al correo si nos olvidamos de borrarlo. Dicha clave, a su vez, podría haber sido usada en uno o más servicios distintos al problemático, lo que amplía la gravedad del asunto, dejando una de nuestras claves… a la deriva.
Reitero lo que dijo Pablo, “…por algo las claves no se muestran ni en los campos de formularios que llenamos…“, en relación a que si la clave es personal y secreta, entonces no debería ser revelada en ninguna instancia.

Consejo: El registro debería ser de forma rápida y fácil, con envío de confirmación para validar que dicho usuario tiene dicha cuenta de correo en su posesión, y en dicho correo se debe enviar solo información sobre el usuario (no la clave, ni siquiera características de esta [longitud, primera letra, etc], ya que cualquier dato hace más vulnerable a la misma).

Registro de usuario con seguridad ampliada
Si bien esta forma de protección no la he visto en muchos sitios, hay que resaltarla porque siempre será bienvenida en aplicaciones que manejan datos muy importantes (por ejemplo, sitios como PayPal).
La idea es bien básica, en el registro de usuario, se listan dos posibles casillas de correo:

• Casilla Principal: Esta casilla será utilizada para todas las operaciones de importancia, y será la necesaria para confirmar el registro del usuario, cambios en la cuenta, información sobre transacciones, etc.
• Casilla Secundaria: Esta casilla será utilizada para enviar información sobre novedades del sitio, o bien publicidades (si el usuario acepta recibirlas).

La casilla principal vendría a ser la casilla segura, y tendría como limitación, la imposibilidad de cambiarla mediante un trámite fácil. Es decir, solo se podrá cambiar la misma, mediante algún trámite que requiera contacto con la empresa (sea por teléfono, por Fax, de forma presencial), de modo que ellos puedan garantizar que nosotros somos -realmente- quienes solicitamos dicho cambio. Como verán, esto incrementa la seguridad para ambas partes, ya que será muy complicado que alguien altere dicha casilla si no es el usuario mismo, y la empresa garantiza que la información le llega a la persona indicada. Si el usuario presta su casilla de correo… eso ya es problema de él.

La casilla secundaria, en cambio, será la que se pueda cambiar fácil… y se debería dejar la posibilidad abierta que el usuario ponga la misma casilla que la principal (maximizando el factor aleatorio en caso de que alguien intente vulnerar a este).
Consejo: No cuesta nada agregar un campo al formulario, aunque si cuesta explicarle el porqué al usuario… pero, podrían necesitarlo para sitios en donde el usuario busque seguridad ante todo.

Recuperación de clave
Este es otro aspecto que tocó Pablo, y básicamente es el que nos da un dato muy claro sobre cuan segura está nuestra información dentro de la base de datos de dicho sitio, con una prueba bien simple… la recuperación de clave.
Un dato como la clave del usuario, no debería guardarse en texto plano (es decir, tal cual el usuario la ingresó), sino más bien el resultado que se produce luego de pasarlo por una función hash (como ser MD5 o SHA, por ejemplo). Esto nos dejará una salida que no se relaciona con la clave en sí, y será muy difícil deducir la misma en sentido contrario (descifrarla). Podríamos usar otro tipo de algoritmo que resida en una clave, pero estaríamos ante el mismo problema, ya que si nosotros disponemos de dicha clave (y si o si será así), entonces podemos reconstruir lo que el usuario guardó… (siendo este el principal problema).

Ahora bien, como usuarios, si al momento de pedir una clave, esta nos llega en texto plano… entonces necesariamente la misma fue guardada sin hashear, lo cual… es preocupante. Ojo, que no nos envíen la clave cuando llenamos el formulario para recuperarla, no es signo de que esta haya sido guardada de forma segura… pero al menos, seremos felices ignorantes.
Consejo: Quienes desarrollen aplicaciones web, verán dos beneficios con respecto a hashear las claves (si tienen buenas intenciones, claro), uno es la seguridad de los usuarios (incluso cuando alguien externo acceda a nuestra base de datos), y otro es la posibilidad de delimitar las claves a una longitud fija… lo que nos permitirá administrar mejor el espacio de los campos en la base de datos. Con esto, esta demás decir que la única forma de recuperar la clave, será enviando una nueva generada de forma aleatoria… e invitar al usuario a que la cambie ni bien ingresa nuevamente al sitio…

Consiguiendo usuarios válidos…Hace un tiempo, intentando entrar en un sitio que no uso muy a menudo, me di cuenta de que no tenía ni el usuario ni la clave. Que mejor momento para probar el formulario de ‘Olvidé mi usuario…’.
Ni bien entré, me puse a pensar con que cuenta de correo me podría haber dado de alta… pero dado que tengo tantas (una por cada sitio que poseo… si, un infierno de usuarios y claves), me puse a probar.
Vaya sorpresa me llevé cuando me empezaron a aparecer estos mensajes:

• Este correo no tiene cuenta asociada a ningún usuario de nuestra base de datos
• Se le ha enviado un correo a su casilla, con los datos de su usuario
• El segundo mensaje fue el definitivo para dejar de probar… pero el primero, me sonó un tanto preocupante.

¿Qué pasa si agarro un listado de correos de personas conocidas y pongo a probar uno por uno, a ver quienes participan en este sitio?. Los resultados en este caso no fueron muy favorables (por lo visto somos pocos los que usamos tal servicio), pero imaginemos que conseguimos asociar un correo de una persona importante, con un servicio…
¿Qué tiene de malo? (y aquí es donde la paranoia toma el mando) Con este mero dato (correo > servicio web), alguien podría mandar tranquilamente correos -personalizados- de scam… los cuales son de mucho más valor que aquellos que se mandan de forma generalizada, sin un objetivo específico (a veces me llegan correos relacionados a MySpace, por ejemplo, en donde no tengo cuenta…).
La cantidad de sitios -afectados- por este tema, es notable… y se sorprenderán de encontrarse con sitios muy conocidos que cometen este pequeño, pero molesto error.
Este mismo error también se puede manifestar a la hora de ingresar el usuario y la contraseña, pero aquí ya entramos en la dificultad de no poder dar un registro con igual nombre de usuario a dos o más personas. Es decir, a la larga… si el que intenta hacer daño prueba registrarse con cierto nombre de usuario, se dará cuenta de que este existe o no. Una solución para esto, es que el usuario sea lo mismo que el correo (ver consejo a continuación).

Consejo: Un mensaje genérico para todos los tipos de errores (es decir, cuando el correo es válido o no), como “En breve le enviaremos un correo, si la casilla ingresada es válida”, limita todo tipo de intentos de uso fraudulentos, ya que si el correo llega a su casilla destino… entonces, el usuario tendrá sus datos (y nadie sabrá si usa o no dicho servicio); mientras que si el usuario en cuestión no existe, no se envía correo tal. De esta forma, la única situación que revelaría datos sobre un usuario que utiliza nuestro servicio, sería si la persona que intenta hacer daño tiene acceso a dicha casilla (y eso ya es problema del usuario, no de nosotros).

Política de seguridad
Otras formas de incrementar la seguridad de los usuarios, es mediante la publicación de una página dedicada a las políticas de seguridad de la aplicación/sitio web.
De este modo, el usuario tiene un lugar en donde fijarse que es lo que la empresa se compromete a hacer, que es lo que nunca hará (por ejemplo, pedir que se cambie la clave o que se cambien determinados datos de nuestro perfil), y también dar la posibilidad de que los usuarios puedan enviar reportes de sucesos extraordinarios (intentos de estafa).
Para complementar todo lo antes mencionado en este punto, una página en donde se informe sobre el estado de seguridad de la aplicación/servicio, será muy bien visto por todo aquel que sea paranoico (como yo), e incrementará la credibilidad de la empresa que esté detrás de dicho sistema.

Recomendar software seguro y actualizaciones
Si bien muchas veces criticamos los intentos de las empresas por imponer cierto software para hacer uso de determinada aplicación web, es importante recalcar que esto se hace con miras a incrementar la seguridad de sus usuarios.
Recomendar software que sabemos que es seguro (o menos inseguro, en todo caso), y promover que los usuarios estén al día con las actualizaciones de las aplicaciones que tienen instaladas (navegador, por ejemplo), será un factor que mejore la seguridad del entorno en general (tanto del usuario, como de la empresa).

Correo seguro y Blog institucional
Otros aspectos a tener en cuenta, es por un lado la posibilidad de que nuestros usuarios nos contacten por correo de forma segura (utilizando criptografía asimétrica), y por otro la posibilidad de que estos puedan recurrir a un blog institucional, en donde se vayan comentando novedades respecto a los servicios ofrecidos (actualizaciones, eventos de mantenimiento, brechas de seguridad, etc).

Conclusión
Tanto el usuario como el desarrollador, deberían velar por la seguridad de los datos que se publican por medio de Internet.El usuario, debería ser consciente de que cada entidad a la que le confía sus datos en la red, debería ser de mínima confianza al menos para él (sea por recomendación, valoración propia, experiencia, etc.).
Desde el otro lado, los que están detrás de los servicios y aplicaciones web, deberían tomarse en serio la seguridad de los datos de sus usuarios, ya que sus sistemas no serían nada sin ellos… y si en algún momento hay una brecha, el usuario será quien tenga el látigo en mano (y más, si es paranoico…).
Agradeceré todo tipo de comentarios en relación al artículo, tanto desde su experiencia con servicios que cuidan o no nuestros datos, al menos para tenerlos en cuenta a futuro.
Espero que los desarrolladores no se enojen por cargarles un peso extra… pero bueno, es algo que en algún momento iban a tener que hacer, a fin de cuentas.

Fuente:
Federico Almada (http://www.techtear.com/2008/05/26/seguridad-en-las-aplicaciones-web-enfocada-en-los-usuarios/)