¿Cuáles son las deficiencias del siguiente esquema de autenticación de transacciones bancarias?

6

Aquí en Alemania, la autenticación de transacciones en banca en línea (más allá de la contraseña de inicio de sesión básica que también es y siempre ha sido necesaria) ha evolucionado a partir de una lista de contraseñas de un solo uso que se distribuyen por adelantado en papel (por lo que (llamados códigos "TAN" o números de autenticación de transacciones) para el uso de contraseñas de un solo uso enviadas a pedido a un teléfono móvil o dispositivo similar, en un mensaje que también contiene detalles de la transferencia para autenticar el mensaje. Me he estado preguntando si es posible alcanzar un nivel de seguridad similar mientras se usa el método anterior de distribución de una lista en papel por adelantado, y de hecho se me ocurrió un esquema que me parece factible. Como soy consciente de la calidad general de los esquemas de seguridad diseñados por aficionados (y soy aficionado), me interesaría escuchar comentarios sobre las deficiencias de mi esquema por parte de los lectores de este sitio.

La idea básica del esquema es que el banco distribuirá de antemano al cliente una lista en papel de las entradas numeradas. Sin embargo, en lugar de contener contraseñas simples, la lista contendría tareas numéricas simples, tales como:

  1. Ingrese la suma de la figura uno y la figura cuatro del número de cuenta, seguido del número ocho, seguido de la cifra tres menos sesenta del código de clasificación del banco.

  2. Ingrese la figura tres del número de cuenta, seguida de la figura dos y la figura siete del código de clasificación del banco, seguida de la figura dos y la figura uno del monto a transferir (ignorando los centavos).

  3. ...

Cuando el cliente tiene que autenticar una transacción, se le dará el número de una de las tareas y se le pedirá que ingrese la solución, usando los detalles de la transacción. Me parece que este esquema cumple con los requisitos de que la generación de contraseña única debe ser iniciada por el banco en el momento de la transacción, que está vinculada a la transacción, que no es trivial volver a trabajar desde la contraseña al método utilizado para generar y que implica un segundo canal de comunicación separado. Además, espero que sea manejable para los clientes (¡excepto que podría necesitar una gran cantidad de papel para llevar a cabo las tareas!), Y en realidad los alentaría a verificar los detalles de la transacción.

Me doy cuenta de que debería haber requisitos en las tareas para mantenerlos usables pero a la vez seguros, y que tendrían que ser expresables y parametrizables de manera que las computadoras del banco puedan lidiar (aunque se podrían introducir nuevos tipos en cualquier momento). Más allá de eso, me interesaría saber qué agujeros principales hay en este esquema que me he perdido.

    
pregunta michaeljt 21.03.2012 - 11:02
fuente

2 respuestas

6

Algunos pensamientos en ningún orden en particular.

  1. Requiere buenas habilidades de matemáticas, lectura y razonamiento; a pesar de esto Sería genial si todos pudieran realizar estas tareas que no podemos (ni debemos) esperar que todos los que tengan una cuenta bancaria podrán hacer esto. Esto resultará en inicios de sesión erróneos fallidos, uso reducido y aumento de llamadas de soporte.
  2. Requiere estandarización sobre cómo escribir las preguntas. Idealmente estas preguntas deberían poder ser algorítmicamente generado, no escrito por un humano, y verificadamente correcto y libre de ambigüedad.
  3. El esquema requiere la capacidad de leer el idioma en el que están escritas las preguntas. Un esquema que solo tenga una tarjeta de token o una lista de códigos de acceso no tiene esta limitación. Las cuentas bancarias son principalmente números que son interlingüísticos.

  4. Dada la estandarización requerida anteriormente, ahora debemos poder verificar que de hecho, no es trivial trabajar hacia atrás desde la contraseña a la algoritmo de generación. No está claro de su descripción que esto es demostrablemente cierto.

  5. El número resultante debe ser lo suficientemente largo como para proporcionar Entropía suficiente y lo suficientemente corta para hacer el paso de cálculo. factible. P.ej. un número de 10 dígitos podría tener suficiente entropía Dependiendo del esquema de cálculo y del resto de la seguridad; pero 10 dígitos pueden ser demasiado largos para esperar que alguien siga todos tus pasos.

  6. ¿Qué problema está tratando de resolver y cree que los esquemas actuales se quedan cortos?
respondido por el Mark Beadles 21.03.2012 - 15:20
fuente
1

Esto tiene dos deficiencias, una de las cuales es probablemente devastadora (en mi opinión).

  1. La usabilidad apesta. Una fracción significativa de los clientes va a tener dificultades para usar esto. La tasa de error va a subir mucho. Algunos clientes simplemente no estarán contentos con el banco, y eso no es bueno para los negocios. Otros van a llamar a la línea de asistencia telefónica para pedir ayuda, y eso es terrible para los negocios: he escuchado estimaciones que sugieren que cuesta $ 20-40 por llamada a la mesa de ayuda. Por lo tanto, si la introducción de su propuesta aumenta las llamadas a la mesa de ayuda en un 10%, ese es un costo enorme para su plan, que la hace morir en el agua. Creo que esto es un showstopper.

  2. No tiene ningún beneficio claro de seguridad sobre esquemas alternativos, como enviar detalles de la transacción y un código de confirmación al teléfono celular del cliente.

respondido por el D.W. 23.03.2012 - 10:05
fuente

Lea otras preguntas en las etiquetas