Google Authenticator, un código QR, muchos dispositivos (usuarios)

-1

Tengo un sitio web comercial donde la gente paga para usar los servicios. Los servicios que ofrezco son de naturaleza de juegos de palabras, por lo que realmente no necesita un cifrado de tipo bancario "Ford Knox" serio, por lo que es una seguridad de autenticación de usuario muy básica que necesito. Actualmente utiliza un nombre de usuario normal y la autenticación de contraseña. El problema con eso es que una persona puede suscribirse y dar su nombre de usuario y contraseña a todos los que desee y todos pueden obtener acceso gratuito. La dirección IP, el tipo de dispositivo, la ubicación, etc., no es una buena forma de autenticarlo, ya que quiero que pueda iniciar sesión en cualquier computadora o dispositivo móvil, siempre que esté presente allí mismo al hacerlo. Dado que el envío de smss (que debería ir a un solo dispositivo) se vuelve bastante costoso, esperaba que la aplicación Google Authenticator fuera una opción más barata ya que sucede en su dispositivo, para garantizar que sea la misma persona que ingresa al sitio web.

Mi problema viene con el código QR (o código que escribe) que se crea al vincular mi servicio a su aplicación Google Authenticator por primera vez. Por lo que he leído hasta ahora, parece que si copia ese código QR a todos sus amigos y familiares (captura de pantalla y lo envía o lo que sea) y también lo escanean en su aplicación Google Authenticator y luego tendrán el mismo acceso. como el hace ¿Tengo razón y, por lo tanto, sería una mala forma de abordar la piratería de software o la protección del contenido de un sitio web?

Gracias

    
pregunta JayCee 05.07.2016 - 03:24
fuente

2 respuestas

1

La autenticación multifactor no puede proteger las cuentas si el propio propietario de la cuenta quiere compartir una cuenta.

Cuando usa Google Authenticator (o cualquier otra aplicación similar), recibe una "semilla" que puede calcular el número de PIN actual de 2FA. Si alguien más tiene exactamente la misma semilla, también puede generarla.

Si tuviera que enviar un SMS sin tener en cuenta los gastos, puede tratarse de un problema de accesibilidad y parecería que también es codicioso.

Para una protección real, deberá verificar algo que sea:

  • El usuario no puede cambiarlo a un valor arbitrario.
  • Garantizado para estar disponible.

Apple tiene una pelusa en la cantidad de dispositivos que puede usar la cuenta de iTunes. Ellos tienen la identificación del hardware para determinar eso. Para una interfaz web, no hay mucho que puedas hacer.

Limita el número de sesiones que puede contener. Por ejemplo, mantén solo las 3 últimas sesiones. Esto hará que sea poco práctico compartir una cuenta de forma generalizada.

    
respondido por el Ayesh K 05.07.2016 - 06:02
fuente
1

Hay 4 opciones aquí:

O bien, puede usar Android Keystore System para generar una clave dentro de Secure Storage, como la La clave privada es muy difícil o imposible de extraer. (depende del modelo de teléfono, algunos modelos solo pueden tener un almacén de claves basado en software y eso no es tan seguro como un almacenamiento de claves basado en hardware)

Hay 2 opciones aquí cuando usas este método. Cualquiera de los dos, puede requerir que el booleano IsInsideSecureHardware () sea verdadero, pero eso limitaría su juego o aplicación a solo dispositivos que tengan un almacenamiento seguro.

O simplemente puede usar Keystore tal como está y ser compatible con todos los dispositivos Android 6.0 y posteriores.

La segunda opción, es aprovisionar un dispositivo físico OTP. Un dispositivo físico OTP no se puede copiar, y está diseñado para borrar cualquier secreto si se intenta abrirlo. También puede aprovisionar un dispositivo U2F, pero eso limitaría la compatibilidad con Chrome.

Una tercera opción es aprovisionar un Yubikey estándar. El código OTP de un yubikey se ingresa como un teclado, y la clave AES para crear la clave, se almacena en un almacenamiento seguro que hace que sea imposible extraerlo. Si opta por esta ruta, incluso puede programar cada Yubikey para que tenga la misma clave AES para todos los usuarios y luego almacenar el ID de usuario dentro de la "ID privada". Entonces, no es necesario que la identidad forme parte de la cadena pública de OTP, y el usuario no necesita ingresar ningún ID de usuario o similar, en lugar de eso, simplemente inserta el YubiKey en un puerto USB y toca el botón - voila se ha registrado.

Una cuarta opción que tiene es usar HOTP basado en eventos junto con Google Authenticator. Todavía pueden compartir la semilla, pero entonces tiene una trampa, por ejemplo, si se ingresa un código gastado, o si se ingresa cualquier código que no sea el código "actual" (por ejemplo, un código futuro), la cuenta está bloqueada y luego se requiere que ingresen 2 códigos desde el token de HOTP, luego aprovisionen una nueva semilla (nuevo código QR), y luego tiene una "tarifa de administración" que es como el 25% de la tarifa original.

Esto significa que si ocurre alguna acción, y no logran "sincronizar" sus tokens junto con cada miembro del "grupo de acciones", les costará el 25% de la tarifa de admisión. 25% (incluso podría ser 10%) no es demasiado si hace clic accidentalmente en el token sin usar el código o vuelve a ingresar accidentalmente un código gastado, pero es demasiado para bloquearlo una y otra vez si está compartiendo la cuenta .

    
respondido por el sebastian nielsen 05.07.2016 - 21:15
fuente

Lea otras preguntas en las etiquetas