Etiqueta 'formulario'

2October

Contraseñas en formularios para móviles: ¿visibles o no?

Como usuario de Android he tenido que meter contraseñas en el móvil unas cuantas veces, y con el teclado virtual de vez en cuando te equivocas y toca escribirla de nuevo. Por eso creo que para mejorar la usabilidad de las versiones móviles debemos desterrar el ocultar contraseña. Esta idea no es nueva, la propuso Jakob Nielsen hace unos cuantos meses. Cuando ocultas una contraseña creas dos problemas:

  • Los usuarios cometen más errores porque no ven lo que escriben y por tanto se sienten menos confiados.
  • Cuando la gente comete errores suele escoger contraseñas fáciles de escribir o copia y pega de un archivo. Ambas opciones hacen que haya riesgos de seguridad importantes.

Asi que el propósito inicial de ocultar la contraseña a ojos ajenos provoca que escojamos contraseñas más fáciles de romper. En el ordenador puede ser más necesario ocultar la contraseña aunque Jakob propone tener un checkbox donde cambiar si la mostramos o la ocultamos (plugin de jquery).

Sin embargo en el móvil no lo veo necesario ya que es un aparato personal con una pantalla que ves tu solo, y por lo tanto no supone tanto riesgo de seguridad. La comodidad que le das al usuario de ver lo que está escribiendo supera con creces los posibles peligros de ojos ajenos. Esta es una opinión personal que intento compartir con nuestros clientes, pero supone un cambio en la mentalidad de seguridad.

Ahora bien, si entramos en el aspecto técnico y el campo de contraseña se convierte en un simple input los navegadores o el sistema operativo en el caso de los móviles puede guardar en caché la contraseña y mostrarla la próxima vez que teclees. Algo totalmente erróneo como bien apunta Mike Andrews. La mayoría de los usuarios que comentan en este artículo no creen que esto deba aplicarse a la Web. Incluso sería vulnerable a los virus que hacen capturas de pantalla de tu ordenador.

Aún así, no soy el primero que lo ve bien para los móviles (especialmente aplicaciones). En el GAP (una especie de guía de desarrollo para webs en versión móviles) tratan este mismo tema y recomiendan que se muestre el campo de contraseña.

Do not use password masks
Reading what is on the screen of a mobile device is often hard enough for the user of the device. Peeking over the shoulder of the user is less likely to disclose a password than observing the user’s keypress sequence.
For this reason, hiding user input to users themselves by replacing each character with a ‘*’ (star) symbol (or similar) will do very little to protect privacy, while making it generally harder to use the service. For this reason, users should be made enter passwords in clear text.
This practice does not detract from the aforementioned practice to avoid login and find alternative ways to identify users.
Caveat: In case of highly sensitive application (such as ‘Net Banking’), security requirements may force you to overlook this practice. For example, some users may perceive the lack of password obfuscation as a sign of slack security practices.

Y ya que hablamos de contraseñas varios consejos a la hora de diseñar vuestro servicio web:

  • Las preguntas de seguridad son un arma de doble filo, porque mucha gente escribe respuestas muy fáciles de adivinar; como se ha podido demostrar con Britney Spears, Sarah Palin, etc. Yo no las recomiendo e intento evitarlas.
  • No se debe enviar la contraseña al email cuando el usuario se registra. La razón es que si entran al email de ese usuario le pueden encontrar las contraseñas y producirse un robo en cadena. Las opciones son, o bien dejar al usuario que escoja su contraseña al registrarse (mi opción preferida) o mandarle una aleatoria al email pero obligarle a cambiarla nada más conectarse a la web (más trabajo para el usuario).
  • También nos podemos plantear la duda de si obligar al usuario a escribir dos veces su contraseña. Desde este artículo rechazan esta convención. Argumentan que porque un 1% de los usuarios se equivoque al escribir la contraseña no tenemos que perder tiempo el 99% restante. En ese punto yo prefiero mostrarlo dos veces y compararlo mediante javascript antes de que dé a enviar. Si no lo hacemos así, puede que perdamos a ese 1% que se encuentre desorientado porque no funciona la contraseña que acaba de poner.
  • Respecto a escribir dos veces el email, ahí si que no. El usuario puede ver lo que escribe, muy poca gente se debería equivocar.

Una situación curiosa se produjo en una web cuyo formulario de registro consistía en solo su email como nombre de usuario y la contraseña que querían poner. Notaron que mucha gente no se registraba y haciendo un test de usabilidad descubrieron que la gente creía que les estaban pidiendo la contraseña de su email. Por eso la gente no se fiaba y no se registraba. Algo parecido puede ocurrir ahora con las conexiones a Flickr, Google, Del.icio.us, etc. Si es posible no hay que pedir al usuario la contraseña de estos sitios, si no usar el protocolo OAuth para conseguir el permiso y dar mayor sensación de control a nuestros usuarios.

¿Qué opináis? ¿Cuáles son vuestras experiencias?