Cómo crear un inicio de session sin contraseña para la aplicación mobile

Estoy interesado en crear algún tipo de inicio de session sin contraseña entre una aplicación mobile y una API (suponiendo que puedo controlar ambas). La motivación es que tener que iniciar session es muy molesto para los usuarios y tiene riesgos de security (por ejemplo, los usuarios reutilizarán las passwords existentes) y quiero que los usuarios puedan comenzar con la aplicación de inmediato.

Me pregunto si hay algunas técnicas que podrían funcionar. Por ejemplo:

  1. Genere y inicie session / contraseña aleatoria en el dispositivo mobile y guarde la contraseña en el llavero.
  2. Regístrese con la API usando esta combinación de inicio de session / contraseña. Esto devuelve un token.
  3. El token se usa en llamadas subsiguientes.

Los inconvenientes son:

  • El inicio de session / las passwords se pueden perder si el usuario elimina la aplicación (esto podría mitigarse mediante el uso de iCloud para almacenar el inicio de session, pero eso sería malo para la contraseña).
  • La contraseña se almacena en el dispositivo (sin embargo, está en el llavero)

Entonces, mis preguntas: ¿es algo así de factible y seguro? ¿Hay técnicas conocidas para hacer eso?

Esto es lo que hicimos:

Básicamente, la idea es bastante similar a la oferta de services de "contraseña olvidada":

  1. Pídale al usuario un correo electrónico
  2. Envíe un correo electrónico con un enlace de activación. El correo electrónico contiene un vínculo profundo con un token de una sola vez, algo así como myapp://login?token=.....
  3. El usuario abre el correo electrónico en el dispositivo donde está instalada la aplicación, esto es crucial para que funcione el enlace profundo, pero lo que sucede en el 99% de los casos de todos modos. El usuario hace clic en el button con el enlace profundo.
  4. El usuario es networkingirigido a la aplicación, extrae el token del enlace profundo en la aplicación y lo envía al server API para autenticarse. Una vez que se realiza la authentication, cree una session para el usuario, de modo que no tendrá que volver a autenticarse.

El bueno:

  1. Más seguro: los usuarios no tienen que pensar en nuevas passwords (que generalmente son demasiado simples ) y no hay riesgo de que los usuarios reutilicen las passwords. Para nosotros, como desarrolladores, ofrece una solución que tiene una única (y simple) ruta de authentication que es más fácil de comprender y, por lo tanto, de proteger. Además, no tenemos que tocar ninguna contraseña de usuario / contraseña con hash.
  2. Flujo de integración más suave al usuario: si ingresa previamente el correo electrónico en el campo de input, el flujo de inicio de session puede ser tan corto como 2 clics de button y están en. (A less que quiera tomar su nombre u otros detalles también, pero eso requiere campos adicionales de input en el inicio de session tradicional también)

Lo less bueno 🙂

  1. Es posible que los usuarios no estén muy acostumbrados a este flujo y podrían preguntarse por qué no necesitan una contraseña. Me gustaría agregar un pequeño enlace que explica "¿por qué no necesitamos passwords?"
  2. Si la aplicación se elimina o el usuario finaliza la session, deberán usar su correo electrónico para iniciar session nuevamente. Este es un problema menor para las aplicaciones mobilees donde los usuarios no se cierran la session ocasionalmente, etc.

Ya implementé este flujo en nuestra aplicación, puedes leer una explicación más detallada aquí: http://www.drzon.net/passwordless-login-in-mobile-apps/

Algunas consideraciones más:

  • Para hacerlo más seguro, haga que el token esté disponible para usar solo una vez y también espere (como una hora). También puede vincular el token con el dispositivo específico enviando al server una identificación de dispositivo única de algún tipo junto con la dirección de correo electrónico. De esta manera, el usuario no puede simplemente reenviar el correo electrónico a otra persona y él lo abrirá
  • Acerca del enlace profundo: descubrí que algunos proveedores de correo electrónico bloquean el uso de enlaces con esquemas de url personalizados como app:// . La forma de superar esto es haciendo que el enlace apunte a su server en su lugar y networkingireccione allí al enlace profundo https://myserver.com/login?token=... —> myapp://login?token=...

Mozilla escribió sobre esto también aquí

Esto es muy abierto, pero generalmente: no reinvente la rueda, use una solución estándar como OAuth y / o OpenID Connect (usa OAuth). Esto tiene la desventaja de que los usuarios pueden necesitar iniciar session a través de un WebView o similar para get un token, pero no tendrá que almacenar las passwords.

Cosas para considerar:

  • no puedes generar una contraseña aleatoria, ya que el server también debe saberlo
  • Android no tiene una API similar a una llavero pública, por lo que debes encargarte de asegurarte la contraseña tú mismo.

En cuanto a 'security suficiente', prácticamente todos usan OAuth hoy en día (Twitter, Facebook, etc.), por lo que al less está probado. La security real dependerá de su implementación particular.