Seguridad versus Usabilidad: El caso del banco Santander

Información Importante Sobre el Contenido

Estas accediendo al contenido antiguo del blog. Este artículo "Seguridad versus Usabilidad: El caso del banco Santander" es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.

Con el fin de mejorar la interacción del usuario con algun sistema, los diseñadores y desarrolladores adoptan distintas técnicas de usabilidad para hacerle el trabajo más fácil al usuario, el problema es cuando se prioriza la usabilidad por sobre la seguridad. Para muchos podría parecer que la gente que desarrolla los sistemas piensan que los usuarios son unos tontos unos niños ingenuos, y que por no hacerlos pensar “donde hacer click” le dan todo en bandeja pasando por alto las normas de seguridad. Es por esto que escribiré sobre como la usabilidad pasa por encima de la seguridad.

Como ejemplo, tomaré el caso del Banco Santander y analizaré como una función para hacerle el trabajo más fácil al usuario puede atentar contra la seguridad del mismo usuario. Para muchos podría ser algo básico, pero si lo ven como si fueran un usuario “normal“, se darán cuenta que realmente es un riesgo y que al usuario le podría pasar perfectamente.

Esta es la pantalla de inicio de sesión que vemos al ingresar a www.santander.cl.

Lo normal sería que al ingresar al portal del banco, el usuario hiciera click en el campo “rut” para ingresar su número de identificación, luego ingresara el password y finalmente presione enviar. Pero, ¿cual es la mejora de usabilidad que implementó Santander?

Cuando ingresamos al sitio web, el usuario sin situarse sobre el formulario de inicio de sesión, el cursor ya está en el formulario, el usuario lo único que debe hacer es ingresar su rut.

El problema es que esa función donde se situa el cursor sobre el formulario se ejecuta al terminar de cargar el sitio, si el usuario ingresa su número de identidad y luego comienza a escribir el password, cuando el sitio termine de cargar el puntero será cambiado al campo “rut”, que no está protegido por “*” y queda registrado en el historial, cuando el usuario sin darse cuenta presione “Iniciar sesión”, el sistema le enviará un mensaje de que la password o usuario son incorrectos, lo único que hará el usuario es volver a introducir los valores e iniciar sesión sin problemas, sin darse cuenta que su password pudo haber sido almacenada en el historial.

Es un poco rebuscado el problema, pero existe. Me ha pasado que mi internet va lento o que el servidor del banco responde lentísimo, entonces ingreso al portal y hago todo muy rapido, ingreso mi RUT y cuando presiono enviar me doi cuenta que la password la escribí en el campo desprotegido “rut”.

¿Qué es mejor, que el usuario tenga que mover un poco el mouse y hacer un par de clicks más, o dejar abierta la remota posibilidad que su password quede almacenada en un historial sin percatarse?

Yo creo que 1 de cada 100 personas podría caer en este error, yo mismo he leído y escuchado a algunas personas quejarse por esto mismo, al menos se que no soy el único que lo piensa 🙂

Información Importante Sobre el Contenido

Estas accediendo al contenido antiguo del blog. Este artículo "Seguridad versus Usabilidad: El caso del banco Santander" es de dominio público y no será mantenido a futuro. Cualquier error o problema acerca del contenido por favor contactate conmigo desde la sección contacto.

15 comentarios

  1. Tienes toda la razon a mi ya me ha pasado, y no solo con ese, creo que en hotmail igual pasa lo mismo. saludos

  2. Ufff me ha pasado todas estas veces, pero ya tengo cuidado al ingresar…
    Desde que cambió la página hace unos 2 años ahora vale hongo.

  3. Exactamente, me ha pasado algunas veces… sin darme cuenta, no tabulo y mi clave queda al final del rut… por ultimo deberian validar el largo del rut y no dejar ingresar mas datos….. menos mal que me ha pasado en mi notebook personal.

  4. Varias veces se ofrecen estas “mejoras” de usabilidad sin pensar. No hace mucho en un lugar donde trabajé le ofrecieron a un cliente (una caja de comp) una mejora donde el usuario al escribir su rut se autocompletaban los demas campos. Aunque se usara captcha igual es lo mismo que publicar los datos privados de los clientes.

    Lo peor es que ni se arrugaron cuando se los indique (ni el vendedor que ofreció la “mejora” ni el cliente), por suerte al final no se hizo, y no porque fuera inseguro, sino por que al gerente no le gusto.. lol.

  5. Hola Zerial… como muchos yo creo q te conocieron por el reportaje de LUN, he decidido venir a leer tus analisis de seguridad.. q los encuento geniales, y como muchos aca te insto a q sigas por este camino del hacker buena onda informando a los usuarios y las instituciones… frente al caso del banco, a mi tambien me ha pasado millones de veces y lo mas fome q encuentro q aun usen password de tan corto caracteres q ademas ni se toman la molestia de q sean password alfanumericas. creo q tambien es un tema q los desarrolladores informaticos deberian mejorar y luego. GRACIAS ZERIAL!!!

  6. Tengo curiosidad ¿a qué artículo de LUN os referís?

  7. por lo que veo, al menos el campo “Rut” corresponde a uno elejido por el suario (supongo).
    Porque algunos bancos ponen como usuario el
    numero de documento del cliente, y al menos aquí (Arg) es muy fácil encontrarlo (http://evidenciasecurity.blogspot.com/2011/09/control-social-o-exposicion-de.html)
    por otro lado, esto facilita una “suerte de Denial of Service” ya que al probar mas de tres veces la clave del cliente “elegido”, este ya no podrá acceder a su homebanking.
    he aquí un ejemplo https://wsec01.bancogalicia.com.ar/scripts/homebanking/GalHBlogin.asp

  8. Por lo que veo estais invadidos por los bancos españoles en esas tierras… ¡huir de ellos! Fdo: un español

  9. Me ha pasado eso en gmail varias veces, pero me he dado cuenta y he cambiado la pass.

  10. Oye Zerial, tienes un error de ortografía en la última pregunta en bold: dice “habierta”

  11. Zerial

    octubre 24, 2011 a las 7:55 am

    Hola ozq! gracias, ya está corregido 🙂

  12. Creo que ahí depende mucho de la institución también y no es únicamente culpar a los desarrlladores.

    Recordemos que en el ambiente de la corbata, la cosa es de no acabar; y que para hacer un ridículo cambio hay que enviar un memo a no sé donde para que lo evalúen, de ahí lo verifican (si es que lo hacen) con el encargado del área, ven la factibilidad…En fin una de burocracia, para que al final recibas una respuesta que es muy probable que sea un NO.

    Otra es que la mayoría de los casos, los sitios y portales de bancos y otras instituciones son desarrollad@s por subcontratistas, que pagan muy poco a los desarrolladores y disenyadores; mismos que lo que quieren es sacar el proyecto YA porqué además de ese tienen 3 o 4 proyectos más.

    Y por último está lo que pasa en latinoamérica, que la gente por más que se queje no es escuchada; en este caso si alguien se quejase le dirían: “Si no le gusta, puede irse a otro banco”. Aquí en latinoamérica las empresas ponen condiciones a los consumidores.

Los comentarios están cerrados.