ES2972816T3 - Autenticación de inicio de sesión y de transacciones segura y eficiente utilizando iPhones y otros dispositivos de comunicación móvil inteligentes - Google Patents

Autenticación de inicio de sesión y de transacciones segura y eficiente utilizando iPhones y otros dispositivos de comunicación móvil inteligentes Download PDF

Info

Publication number
ES2972816T3
ES2972816T3 ES21151197T ES21151197T ES2972816T3 ES 2972816 T3 ES2972816 T3 ES 2972816T3 ES 21151197 T ES21151197 T ES 21151197T ES 21151197 T ES21151197 T ES 21151197T ES 2972816 T3 ES2972816 T3 ES 2972816T3
Authority
ES
Spain
Prior art keywords
user
program
pin
application
security server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES21151197T
Other languages
English (en)
Inventor
Ravi Ganesan
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Prove Identity Inc
Original Assignee
Payfone Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Payfone Inc filed Critical Payfone Inc
Application granted granted Critical
Publication of ES2972816T3 publication Critical patent/ES2972816T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3215—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a plurality of channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/068—Authentication using credential vaults, e.g. password manager applications or one time password [OTP] applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Telephonic Communication Services (AREA)
  • Telephone Function (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • User Interface Of Digital Computer (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Para autenticar a un usuario de un dispositivo de comunicación móvil para iniciar sesión o autorizar transacciones, una primera aplicación en el dispositivo dirige la transmisión de una solicitud de autenticación del usuario a un servidor de seguridad. Una segunda aplicación en el dispositivo recibe la solicitud de autenticación del servidor de seguridad y dirige la presentación de la solicitud de autenticación recibida al usuario por parte del dispositivo. La segunda aplicación recibe una entrada del usuario al dispositivo que indica que debe continuar la autenticación solicitada y en respuesta dirige la transmisión de una indicación de que debe continuar la autorización solicitada al servidor de seguridad. En respuesta a esta última transmisión, la segunda aplicación recibe un PIN del servidor de autenticación. La primera aplicación dirige la transmisión del PIN recibido por la segunda aplicación al sitio de la red, que valida el PIN transmitido, para autenticar al usuario o la transacción en el sitio de la red. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN
Autenticación de inicio de sesión y de transacciones segura y eficiente utilizando iPhones y otros dispositivos de comunicación móvil inteligentes
SOLICITUDES RELACIONADAS
[0001] Esta solicitud reivindica prioridad basándose en la solicitud provisional de EE. UU. n.° de serie 61/327,723, presentada el 26 de abril de 2010. Esta solicitud está relacionada con la solicitud pendiente n.° de serie 12/938,161, presentada el 2 de noviembre de 2010 y titulada "A NEW METHOD FOR SECURE SITE AND USER AUTHENTICATION", que reivindica prioridad basándose en la solicitud provisional de EE. UU. n.° de serie 61/257,207, presentada el 2 de noviembre de 2009 y titulada "Project Seal". Esta solicitud también está relacionada con la solicitud pendiente n.° de serie 13/006,806, presentada el 14 de enero de 2011 y titulada "A NEW METHOD FOR SECURE USER AND SITE AUTHENTICATION", que es una continuación de la solicitud pendiente n.° de serie 12/938,161. Esta solicitud también está relacionada con la solicitud pendiente n.° de serie 13/011,587, presentada el 21 de enero de 2011 y titulada "A NEW METHOD FOR SECURE USER AND TRANSACTION AUTHENTICATION AND RISK MANAGEMENT", que reivindica prioridad basándose en la solicitud provisional de EE. UU. n.° de serie 61/298,551, presentada el 27 de enero de 2010 y titulada "Authentication-The Game Changer". Esta solicitud también está relacionada con la solicitud n.° de serie 13/011,739, presentada el 21 de enero de 2011 y "A NEW METHOD FOR SECURE USER AND TRANSACTION AUTHENTICATION AND RISK MANAGEMENT", que es una continuación en parte de la solicitud pendiente n.° de serie 13/011,587.
CAMPO TÉCNICO
[0002] Esta invención se refiere a la seguridad y la privacidad. Más particularmente, se refiere a la autenticación de transacciones basada en web utilizando dispositivos de comunicación móvil inteligentes, tales como Apple iPhones™.
ANTECEDENTES DE LA INVENCIÓN
[0003] La autenticación de usuario utilizando técnicas, como contraseñas, contraseñas de un solo uso (OTPs, por sus siglas en inglés), tarjetas inteligentes dehardwareosoftware,etc., ha demostrado ser demasiado débil y susceptible a los ataquesman in the middle(MITM) oman in the browser(MITB) o bien ha resultado ser demasiado engorrosa y costosa. El uso de técnicas de inicio de sesión único, como OpenlD, FaceBook Connect, etc., solo empeora el problema, ya que una vez que el atacante ha comprometido la cuenta maestra, ahora puede robar todas las demás cuentas que dependen de ese inicio de sesión inicial. Además, el enfoque de los atacantes ha pasado de intentar interrumpir el proceso de inicio de sesión a utilizar técnicas sofisticadas para entrar después del acto de inicio de sesión y atacar las transacciones que se realizan. Esto ha hecho que la autenticación de transacciones, el acto de confirmar si la transacción vista en el servidor web deback-endes idéntica a la prevista por el usuario, sea aún más importante.
[0004] La autenticación fuera de banda (OOBA, por sus siglas en inglés), una técnica mediante la cual se transmite una transacción al usuario y se obtiene la confirmación, utilizando una forma alternativa de comunicación, por ejemplo, realizando una llamada telefónica o un mensaje de texto, es una alternativa prometedora, pero también es demasiado inconveniente y difícil de usar con mucha frecuencia. Puede ser útil para las transacciones de mayor valor o eventos raros, como el restablecimiento de contraseñas, pero usarlo para una gran cantidad de transacciones es demasiado costoso y engorroso.
[0005] En el trabajo previo (consulte las solicitudes relacionadas identificadas anteriormente), describimos una innovación que aborda algunos de estos problemas. Específicamente, introdujimos la noción del establecimiento de un servidor de seguridad que se comunica con una ventana emergente independiente en el escritorio del usuario que se está utilizando para acceder al sitio web. Describimos cómo este servidor de seguridad puede alertar al usuario, a través de comunicaciones a la ventana emergente, sobre la legitimidad del sitio web por el que navega el usuario a través de su navegador. También describimos cómo esta ventana emergente puede proporcionar a un usuario una contraseña de un solo uso para permitir el inicio de sesión en el sitio web (es decir, la autenticación del usuario en el sitio web), basándose en un secreto compartido entre el sitio web y el servidor de seguridad. De particular utilidad en esta invención fue que proporcionó la seguridad de contraseñas de un solo uso, pero no requirió un secreto compartido por el usuario que todos los sistemas de contraseñas de un solo uso anteriores han requerido.
[0006] Es común que cuando los usuarios navegan por un sitio web del comercio electrónico vean botones de pago como los proporcionados por Paypal. Cuando el usuario hace clic en esa funcionalidad de pago, el usuario normalmente interactúa directamente con el proveedor de pagos. Esto significa que el usuario no revela sus credenciales para autenticarse con el proveedor de pagos en el sitio web del comercio electrónico. Esto es una característica importante que ya no está disponible cuando un usuario interactúa con el sitio web del comercio electrónico utilizando una aplicación para teléfonos inteligentes que el sitio web proporciona.
[0007] Las innovaciones descritas en este documento amplían aun más nuestro trabajo previo para proporcionar una autenticación de inicio de sesión y una autorización de transacciones eficientes y seguras utilizando dispositivos de comunicación móvil inteligentes. En este sentido, el documento US 2008/0052180 A1 da a conocer un sistema de transacciones con autenticación y almacenamiento de datos centralizados. Además, el documento US 2002/0004831 A1 describe un sistema y un método para utilizar la red telefónica pública conmutada para proporcionar autenticación o autorización para transacciones en línea.
OBJETIVOS DE LA INVENCIÓN
[0008] La presente invención está destinada a proporcionar un protocolo de autenticación de inicio de sesión y de transacciones mejorado y que se implemente fácilmente en dispositivos de comunicación móvil inteligentes, tales como iPhones y iPads.
[0009] Los objetos, las ventajas y características adicionales nuevas de la presente invención resultarán evidentes para los expertos en la técnica a partir de esta descripción, incluida la siguiente descripción detallada, así como mediante la práctica de la invención. Si bien la invención se describe a continuación con referencia a la(s) forma(s) de realización preferida(s), se debe entender que la invención no se limita a la(s) misma(s). Aquellos con experiencia ordinaria en la técnica que tengan acceso a la descripción del presente documento reconocerán implementaciones, modificaciones y formas de realización adicionales, así como otros campos de uso, que están dentro del alcance de la invención, tal y como se divulga y reivindica aquí y con respecto a los cuales la invención podría ser de utilidad significativa.
DIVULGACIÓN DEL RESUMEN DE LA INVENCIÓN
[0010] Según aspectos de la presente invención, se refiere a la autenticación de un usuario de un dispositivo de comunicación móvil, como un iPhone. Según la invención, se proporcionan un método, un artículo de producción, un dispositivo de comunicación móvil y un servidor de seguridad según las reivindicaciones independientes. Se pueden obtener formas de realización preferidas considerando las características de las reivindicaciones dependientes.
[0011] Para hacerlo, una primera aplicación que se ejecuta en el dispositivo de comunicación móvil, como una aplicación de comercio electrónico del comerciante o banco, dirige la transmisión, desde el dispositivo de comunicación móvil hasta un servidor de seguridad, de una solicitud de autenticación del usuario en relación con (i) el usuario que inicia sesión en un sitio de red, como el comerciante o el sitio de internet del banco, o (ii) el usuario que realiza una transacción con dicho sitio de red, como la compra de un producto del sitio de internet del comerciante o la transferencia de fondos desde el sitio de internet del banco. Una segunda aplicación que se ejecuta en el dispositivo de comunicación móvil, a la que comúnmente se le denomina la aplicación Hawk and Seal, pero que también se denomina a menudo en el presente documento la aplicación Authentify ("Authentify Application") (AA), recibe la solicitud de autenticación del servidor de seguridad. La segunda aplicación dirige la presentación mediante el dispositivo de comunicación móvil, por ejemplo, en la pantalla táctil del iPhone, de la solicitud de autenticación recibida al usuario. La segunda aplicación recibe entonces una entrada de usuario en el dispositivo de comunicación móvil, por ejemplo, a través de la pantalla táctil del iPhone, que indica que se debería continuar con la autenticación solicitada. La segunda aplicación, en respuesta a la entrada de usuario recibida, dirige la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad, de una indicación de que se debería continuar con la autorización solicitada. En respuesta, la segunda aplicación recibe, desde el servidor de autenticación, un número de identificación personal (PIN, por sus siglas en inglés). Este PIN podría caracterizarse como un PIN de inicio de sesión de sitio de red o un PIN de transacción, según corresponda. El PIN corresponde preferiblemente a un secreto compartido únicamente por el servidor de seguridad y el sitio de red, y no por el usuario. De la manera más preferible, el PIN también se obtiene de otros factores, incluidos los que son exclusivos de la aplicación EDA y, en el caso de la autorización de transacciones, de una transacción particular, etc. Independientemente de cómo se obtiene el PIN, la primera aplicación dirige la transmisión, desde el dispositivo de comunicaciones móviles hasta el sitio de red, del PIN recibido por la segunda aplicación, para autenticar al usuario o la transacción en el sitio de red.
[0012] Preferiblemente, la segunda aplicación almacena el PIN recibido en una memoria pública de datos, como un portapapeles(pasteboard)personalizado, dentro del dispositivo de comunicaciones móviles. En tal caso, la primera aplicación recupera el PIN almacenado de la memoria pública de datos y el PIN recuperado es el PIN cuya transmisión dirige la primera aplicación al sitio de red. Una ventaja única de esta invención es su capacidad de utilizar almacenamiento público compartido, como portapapeles públicos en el sistema operativo de iPhones. Sin embargo, de manera alternativa, la segunda aplicación podría simplemente transferir el PIN recibido directamente a la primera aplicación. En este caso, que puede ser ventajoso en ciertas implementaciones, la primera aplicación no tiene necesidad de recuperar el PIN y el PIN del que la primera aplicación dirige la transmisión al sitio de red es el PIN que fue transmitido directamente por la segunda aplicación. Otra alternativa más es que la segunda aplicación presente directamente al usuario el PIN en el dispositivo de teléfono móvil, por ejemplo, en la pantalla táctil del iPhone. En este último caso, el usuario introduce manualmente el PIN en la primera aplicación, por ejemplo, en la pantalla táctil del iPhone. Por lo tanto, en este último caso, la primera aplicación tampoco tiene necesidad de recuperar el PIN y el PIN del que la primera aplicación dirige la transmisión al sitio de red es el PIN que fue introducido por la segunda aplicación. Si bien este último caso podría ser potencialmente beneficioso en ciertas implementaciones, generalmente se prefiere que la transmisión del PIN al sitio de red por parte de la primera aplicación se dirija sin que el PIN se presente al usuario o sin que el usuario lo introduzca en la primera aplicación.
[0013] Según otros aspectos preferidos de la invención, la memoria pública de datos también se puede usar para otros fines. Por ejemplo, la segunda aplicación puede almacenar la información en la memoria pública de datos, lo que indica que existe o no existe una sesión activa entre la segunda aplicación y el servidor de seguridad. Si es así, después de que la primera aplicación reciba una solicitud del usuario para acceder al sitio de red o para realizar una transacción con el sitio de red, la primera aplicación puede determinar, basándose en la información de sesión activa almacenada, si existe o no una sesión activa. La primera aplicación solo dirigirá la transmisión de la solicitud de autenticación del usuario al servidor de seguridad solo si se determina que existe una sesión activa. De lo contrario, la primera aplicación solicitará que el usuario active una sesión con el servidor de seguridad antes de continuar con la autorización de la transacción.
[0014] De manera beneficiosa, la información almacenada que indica que existe o no una sesión activa incluye un número aleatorio y un tiempo de vida (TTL, por sus siglas en inglés). En tal caso, la segunda aplicación recibe un nuevo número aleatorio y un nuevo TTL del servidor de autenticación, con el PIN que recibe en respuesta a la transmisión de la indicación de que se debería continuar con la autorización solicitada. A continuación, la segunda aplicación almacena, en la memoria pública de datos, el nuevo número aleatorio y el nuevo TTL como información actual que indica que existe o no existe una sesión activa entre la segunda aplicación y el servidor de seguridad.
[0015] Según otros aspectos ventajosos de la invención, la segunda aplicación también ayuda preferiblemente al usuario a iniciar sesión en el servidor de seguridad. Para hacerlo, la segunda aplicación recibe una solicitud del usuario para iniciar sesión en el servidor de seguridad. Esta solicitud podría ser iniciada, por ejemplo, por el usuario al intentar acceder al sitio de red del servidor de seguridad, por ejemplo, el sitio web de Internet del servidor de seguridad. La segunda aplicación dirige la transmisión de la solicitud y un identificador de usuario, por ejemplo, el número de teléfono móvil del iPhone, desde el dispositivo de comunicación móvil hasta el servidor de seguridad. Una tercera aplicación que se ejecuta en el dispositivo de comunicación móvil, como una aplicación de mensajería de texto, recibe un mensaje, que incluye otro PIN, que podría caracterizarse como un PIN de inicio de sesión de seguridad, desde el servidor de autenticación en respuesta a la solicitud transmitida. La tercera aplicación dirige la visualización de este otro PIN mediante el dispositivo de comunicación móvil. La segunda aplicación recibe otra entrada de usuario, por ejemplo introducida en la pantalla táctil del iPhone, que incluye el otro PIN mostrado. La segunda aplicación dirige la transmisión del otro PIN recibido desde el dispositivo de comunicación móvil hasta el servidor de seguridad. En respuesta, la segunda aplicación recibe del servidor de autenticación unacookiede sesión e información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre la segunda aplicación y el servidor de seguridad permanecerá activa. La segunda aplicación almacena (i) lacookiede sesión en una memoria privada de datos a la que solo puede acceder la segunda aplicación y (ii) la información de la sesión activa en una memoria pública de datos, por ejemplo, el portapapeles del iPhone, al que puede acceder la segunda aplicación.
[0016] Según otras formas de realización de la presente invención, la funcionalidad anteriormente descrita se puede implementar en uno o más artículos de fabricación que incluyen un programa almacenado en algún tipo de medio de almacenamiento, de manera que el programa almacenado esté configurado para ser legible por un procesador y hacer que el procesador funcione como se describió sustancialmente con anterioridad.
[0017] Por ejemplo, la segunda aplicación podría ser una aplicación de iPhone almacenada en la memoria del iPhone que recibe, desde un servidor de seguridad, una solicitud de autenticación del usuario en relación con (i) el usuario que inicia sesión o (ii) el usuario que realiza una transacción con un sitio de red. Si es así, la aplicación dirige una visualización, mediante el dispositivo de comunicación móvil, de la solicitud de autenticación recibida. Si, en respuesta, la aplicación recibe una entrada de usuario al dispositivo de comunicación móvil que indica que se debería continuar con la autenticación solicitada, dirige la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad, de una indicación de que se debería continuar con la autorización solicitada. En respuesta a esta transmisión, la aplicación recibe un PIN del servidor de seguridad y pone el PIN recibido a disposición de otro programa ejecutable por el dispositivo de comunicaciones móviles, por ejemplo, almacenando el PIN recibido en una memoria pública de datos dentro del dispositivo de comunicación móvil para facilitar, de esta manera, la transmisión del PIN recibido desde el dispositivo de comunicación móvil hasta el sitio de red para autenticar al usuario o la transacción en el sitio de red. Como se ha indicado anteriormente, el PIN corresponderá preferiblemente a un secreto compartido únicamente por el servidor de seguridad y el sitio de red, y no por el usuario.
[0018] La aplicación preferiblemente también hace que el procesador almacene, en la memoria pública de datos, información que indica que existe o no existe una sesión activa entre la aplicación y el servidor de seguridad. En cuyo caso, la solicitud de autenticación solo se recibe desde el servidor de seguridad si la información almacenada indica que existe una sesión activa. Si la información de la sesión activa almacenada incluye un número aleatorio y un tiempo de vida (TTL), la aplicación también hace que el procesador funcione para recibir, desde el servidor de autenticación, un nuevo número aleatorio y un nuevo TTL con el PIN, y almacene, en la memoria pública de datos, esta nueva información como la información actual que indica si existe o no una sesión activa entre la aplicación y el servidor de seguridad.
[0019] De manera beneficiosa, la aplicación también hará que el procesador funcione para recibir una solicitud del usuario para iniciar sesión en el servidor de seguridad y la transmisión directa de la solicitud y un identificador de usuario desde el dispositivo de comunicación móvil hasta el servidor de seguridad. La aplicación hace que el procesador funcione para recibir también otra entrada de usuario, incluido el PIN, y para dirigir la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad, del otro P<i>N recibido. A continuación, la aplicación hace que el procesador funcione, en respuesta a la transmisión del otro PIN recibido, para recibir unacookiede sesión e información de sesión activa del servidor de autenticación, lo que indica un periodo de tiempo durante el cual la sesión entre la aplicación y el servidor de seguridad permanecerá activa, y almacenar (i) lacookiede sesión en una memoria privada de datos a la que solo puede acceder la aplicación y (ii) la información de sesión activa en una memoria pública de datos a la que pueden acceder otros programas ejecutables por el iPhone.
[0020] De acuerdo con otra forma de realización de la invención, un servidor de seguridad funciona para autenticar a un usuario de un dispositivo de comunicación móvil al recibir, desde una primera aplicación que se ejecuta en el dispositivo de comunicación móvil que está en una sesión activa con un sitio de red, una solicitud de autenticación del usuario en relación con (i) el usuario que inicia sesión o (ii) el usuario que realiza una transacción con el sitio de red. El servidor de seguridad transmite a una segunda aplicación, que se ejecuta en el dispositivo de comunicación móvil, la solicitud de autenticación recibida y, en respuesta, recibe, desde la segunda aplicación, una indicación de que se debería continuar con la autorización solicitada. En respuesta, el servidor de seguridad transmite entonces, a la segunda aplicación, un PIN, que preferiblemente corresponde a un secreto compartido únicamente por el servidor de seguridad y el sitio de red, y no por el usuario, para autenticar al usuario en el sitio de red. Como se ha indicado anteriormente, este PIN podría caracterizarse como un PIN de inicio de sesión de sitio de red o un PIN de transacción, según corresponda. Además, el servidor de seguridad recibe preferiblemente la solicitud de autenticación del usuario desde la primera aplicación solo si existe una sesión activa entre la segunda aplicación y el servidor de seguridad.
[0021] Según otros aspectos preferidos de las operaciones del servidor de seguridad, el servidor de seguridad recibe, desde la segunda aplicación, una solicitud del usuario para iniciar sesión en el servidor de seguridad. En respuesta, el servidor de seguridad transmite, a una tercera aplicación que se ejecuta en el dispositivo de comunicación móvil, preferiblemente una aplicación de mensajería de texto, un mensaje que incluye otro PIN. Este PIN podría caracterizarse como un PIN de inicio de sesión de seguridad, como se indicó anteriormente.
[0022] Posteriormente, el servidor de seguridad recibe el otro PIN transmitido desde la segunda aplicación y autentica al usuario basándose en el otro PIN recibido. El servidor de seguridad también transmite, a la segunda aplicación, unacookiede sesión e información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre la segunda aplicación y el servidor de seguridad permanecerá activa, basándose en la autenticación del usuario.
[0023] Puede que valga la pena destacar que puede haber tres tipos de PINs. El primero es el PIN requerido para la activación inicial de la aplicación de seguridad que se ejecuta en el dispositivo de comunicación móvil, es decir, la aplicación que recibe los PINs del servidor de seguridad. En ocasiones, este PIN se ha caracterizado como el PIN de inicio de sesión de seguridad mencionado anteriormente. El segundo es un PIN de firma de transacción, que la aplicación del sitio de red que se ejecuta en el dispositivo de comunicaciones móviles obtiene de la aplicación de seguridad para autorizar una transacción. En ocasiones, este PIN se ha caracterizado como el PIN de transacción mencionado anteriormente. El tercero es un PIN que la aplicación del sitio de red obtiene del sistema de seguridad para iniciar sesión en el propio sitio de red. En ocasiones, este PIN se ha caracterizado como el PIN de inicio de sesión del sitio de red mencionado anteriormente.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0024]
La figura 1 representa los componentes principales del sistema según nuestro trabajo previo inicial.
La figura 2 muestra el sistema ampliado con autenticación de usuario, en este caso logrado utilizando la autenticación fuera de banda, según nuestro trabajo previo inicial.
La figura 3 representa un registro de las actividades de la red que se pueden mantener y utilizar para un análisis de inteligencia de riesgos aumentado según ampliaciones anteriores de nuestro trabajo previo inicial. La figura 4 representa los componentes principales del sistema según ampliaciones anteriores de nuestro trabajo previo inicial.
La figura 5 muestra el sistema ampliado con autenticación de usuario, en este caso logrado utilizando la autenticación fuera de banda, según ampliaciones adicionales anteriores de nuestro trabajo previo inicial. La figura 6 representa un dispositivo de comunicación móvil inteligente según la presente invención.
La figura 7 representa una arquitectura de red simplificada según la presente invención.
La figura 8 representa una visualización asociada a un inicio de sesión inicial, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación de autenticación que se ejecuta en ese dispositivo según la presente invención.
La figura 9 representa una visualización asociada a otro inicio de sesión o una autorización de transacciones, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación de autenticación que se ejecuta en ese dispositivo según la presente invención.
La figura 10 representa otra visualización asociada al otro inicio de sesión o la autorización de transacciones, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación de autenticación que se ejecuta en ese dispositivo según la presente invención.
La figura 11 representa una visualización asociada a la autorización de transacciones, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación del comerciante que se ejecuta en ese dispositivo según la presente invención.
La figura 12 representa otra visualización asociada a la autorización de transacciones, que se presenta al usuario en un dispositivo de comunicación móvil inteligente mediante una aplicación del comerciante que se ejecuta en ese dispositivo según la presente invención.
FORMA(S) DE REALIZACIÓN PREFERIDA(S) DE LA INVENCIÓN
Descripción general
[0025] En trabajos anteriores hemos descrito cómo la introducción de un servidor de seguridad basado en red que tiene un canal independiente para una ventana emergente del usuario se puede usar junto con el navegador de un usuario y el sitio web que está visitando para proporcionar autenticación tanto del sitio web como del usuario a través de un único dispositivo de red de usuario.
[0026] A continuación mostramos cómo extender este concepto a la autenticación de transacciones. Específicamente, cuando un sitio web recibe una transacción desde el navegador de un usuario, que desea confirmar, envía la información de la transacción al servidor de seguridad, que reenvía la información de la transacción a la ventana emergente del usuario junto con una firma de transacción única que se calcula en función de un secreto compartido entre el servidor de seguridad y el servidor web y en la información de la transacción. El usuario transfiere esta firma de transacción única al servidor web a través del navegador, y el servidor web puede recalcular la firma de transacción única y, si hay una coincidencia, puede estar seguro de que el usuario ha confirmado la transacción.
[0027] También mostramos cómo extender el concepto de ventana emergente basada en navegador a diferentes factores de forma. Por ejemplo, la ventana emergente se puede implementar como una aplicación de teléfono inteligente, como una parte dedicada de una pantalla de un teléfono inteligente que se utiliza únicamente para este propósito, o podría implementarse como una tarjeta inteligente.
[0028] Además, mostramos cómo aprovechar el hecho de que la ventana emergente (o su sustituto) tiene un registro de cada inicio de sesión y transacción del usuario. Actualmente, los motores de riesgo observan la actividad de los usuarios en un sitio web determinado para determinar comportamientos sospechosos. O, en algunos casos, las redes de sitios web comparten dicha información. En otras palabras, se analizan datos de los sistemas deback-end.En nuestro sistema, el registro emergente del inicio de sesión y del historial de transacciones de un usuario proporciona una forma defront endcentrada en el usuario para capturar esta información y aumentar las capacidades de los motores de riesgo.
Nuestro trabajo previo inicial
[0029] Previamente describimos una forma de realización preferida para la autenticación de transacciones con referencia a las figuras 1 y 2, que muestran un sistema que consta de los siguientes componentes:
• Un servidor de seguridad.
• Una ventana emergente en el escritorio del usuario.
• Un navegador en el escritorio del usuario.
• El sitio web en el que el usuario realiza la transacción.
[0030] Tal y como se describió anteriormente, el usuario primero pasará por una fase de configuración y personalización, que es un proceso único, y luego iniciará o activará la ventana emergente utilizando una técnica como la autenticación fuera de banda. En este punto, el servidor de seguridad tendrá un canal de comunicación activo abierto para el usuario al que identifica mediante algún identificador de usuario, por ejemplo el número de teléfono utilizado para la autenticación fuera de banda. Además, el sitio web en el que el usuario realiza la transacción y el servidor de seguridad habrían acordado previamente un secreto compartido.
[0031] El usuario que utiliza el navegador selecciona una transacción, por ejemplo, "Pagar a Alicia 100 $", que el navegador transmite al servidor web. El servidor web transmite esta transacción al servidor de seguridad a través del navegador del usuario. El servidor de seguridad calcula una firma de transacción única en función de (i) los detalles de la transacción y (ii) el secreto que comparte con ese sitio web particular. A continuación, el servidor de seguridad transmite esta firma de transacción única a la ventana emergente del usuario. El usuario corta y pega o, de otro modo, copia esta firma de transacción única en el navegador web y la firma se trasmite de regreso al sitio web. El sitio web calcula de forma independiente la firma de transacción usando (i) los detalles de la transacción y (ii) el secreto que comparte con el servidor de seguridad, y la compara con la recibida del usuario. Si las dos firmas coinciden, entonces el servidor web puede estar seguro de que el servidor de seguridad vio la misma transacción que envió (es decir, no una transacción manipulada en ruta al servidor de seguridad) y, dado que el servidor de seguridad le muestra al usuario la transacción en un canal independiente, se obtiene la confirmación del usuario de la transacción.
Ampliaciones anteriores de nuestro trabajo previo inicial
[0032] En otra forma de realización preferida descrita anteriormente, mostramos cómo nuestro trabajo anterior con respecto a la autenticación, como el descrito inmediatamente con anterioridad, se puede extender al caso en el que la ventana emergente se implementa en uno de una variedad de diferentes factores de forma. Una variedad contempla que la ventana emergente esté en una aplicación en un dispositivo móvil, otra contempla que la ventana utilice una parte dedicada del área de visualización de un dispositivo de red móvil personal, como un teléfono inteligente, y la última contempla que la ventana emergente esté incorporada en unhardwarededicado similar al de una tarjeta inteligente, que tiene capacidades de comunicación. En todos los casos, todas las funciones funcionarán exactamente de la misma manera, excepto que el usuario ya no puede cortar y pegar las contraseñas de un solo uso utilizadas para la autenticación y, en su lugar, tendrá que escribirlas en el navegador web que funciona en un dispositivo de red diferente. Estos factores de forma proporcionan capas adicionales de seguridad simplemente por ser independientes del escritorio del ordenador del usuario que ejecuta el navegador.
[0033] En cualquiera de las formas de realización preferidas mencionadas anteriormente, cuando un usuario realiza múltiples inicios de sesión y transacciones, la ventana emergente o su sustituto tiene la capacidad de almacenar un historial o un registro de estos eventos. A continuación, dichos datos se pueden enviar a los motores de gestión de riesgos, que hoy en día solo tienen acceso a los patrones de actividad de los usuarios que observan desde uno o más sitios web.
[0034] En resumen, en ampliaciones de nuestro trabajo anterior, mostramos cómo fortalecer significativamente el vínculo entre el usuario, el servidor de seguridad que actúa como proveedor de identidad y el sitio web que es la parte de confianza en el caso de transacciones realizadas a través de una red, como la compra de un producto por parte de un usuario en el sitio web. Aquí, como en nuestro trabajo anterior, asumimos que el servidor de seguridad y el sitio web han acordadoa prioriun secreto compartido (el sistema se amplía fácilmente para utilizar criptografía de clave pública). Adicionalmente, como se muestra en la figura 2, también asumimos que el usuario ha utilizado algún método, por ejemplo, autenticación fuera de banda, para autenticarse en el servidor de seguridad. Cuando el usuario desea realizar una transacción en un sitio web, como la compra de un producto ofrecido en el sitio web o la transferencia de fondos desde una cuenta bancaria, el sitio web comunica los detalles de la transacción (como el tipo y la cantidad de la transacción), que se presentaron tanto en una página web mostrada al usuario a través del navegador del usuario como en una ventana emergente. Antes de continuar con la transacción, el sitio web requería la autenticación y confirmación de la transacción, o lo que comúnmente se conoce firma del usuario en la transacción. Por lo tanto, la página web mostró, además, un espacio en blanco para introducir la firma del usuario. Además, el sitio web también comunicó al servidor de seguridad una solicitud de firma del usuario en la transacción identificada. El servidor de seguridad calculó una contraseña de un solo en función de (i) el secreto que comparte con el sitio web y (ii) los detalles de la transacción aplicables que se muestran en la ventana emergente, y mostró la contraseña de un solo uso al usuario en la ventana emergente. El usuario introdujo (quizás cortando y pegando) esta contraseña de un solo uso en la página web, que sirvió como firma del usuario en la transacción. A continuación se trasmitió la contraseña de un solo, es decir, la firma, al sitio web. El sitio web confirmó la autenticidad de la firma volviendo a calcular la contraseña de un solo uso del secreto que comparte con el servidor de seguridad y los detalles de la transacción. Una vez más, este sistema tiene todas las propiedades de seguridad de las contraseñas de un solo uso, pero aun tiene la tremenda ventaja de que no requiere un secreto compartido con cada usuario, y son solo el servidor de seguridad y los sitios web los que necesitan secretos compartidos con el fin de generar contraseñas de un solo uso utilizadas como firmas en las transacciones. Si se desea, la contraseña real de un solo uso también se puede construir basándose en una marca de tiempo o un algoritmo OTP basado en contadores (en la forma en que usamos estos algoritmos, el servidor de seguridad debe comunicar el tiempo o el valor del contador al sitio web; o potencialmente calculado de manera determinista utilizando alguna fórmula acordada).
Ampliaciones adicionales anteriores de nuestro trabajo previo
[0035] También describimos previamente una ampliación adicional que proporciona una aplicación que permite que la propia ventana emergente resida en el teléfono inteligente, la tarjeta inteligente u otro pequeño dispositivo de red móvil inteligente personal del usuario, en vez de en el dispositivo de red, por ejemplo, un escritorio de ordenador, que se utiliza para acceder al sitio web correspondiente a través de su navegador. Mostramos, por ejemplo, cómo esto se logra fácilmente en un teléfono inteligente porque el teléfono ya está personalizado y, de acuerdo con las técnicas descritas anteriormente, no necesita almacenar un secreto especial ni ejecutarsoftwarede contraseña de un solo. Más bien, solo el sitio web y el servidor de seguridad deben compartir el secreto necesario y solo el servidor de seguridad debe generar las contraseñas de un solo uso necesarias para la autenticación del usuario y la firma del usuario.
[0036] También describimos previamente una ampliación que nos permite proporcionar análisis de inteligencia de riesgos aumentado. En este sentido, el análisis de riesgos convencional se basa en datos de sitios web. Sin embargo, debido al flujo de información, mostramos cómo se puede mantener fácilmente un registro de datos, como uno del tipo mostrado en la figura 3, para capturar las actividades del usuario mientras la ventana emergente estaba activa. El registro podría, por ejemplo, ser mantenido por el sitio web del servidor de seguridad y el usuario puede acceder a este registro. Si lo desea, el usuario o el servidor de seguridad puede calcular el perfil de riesgos del usuario. Además o alternativamente, los datos registrados se pueden reenviar a un motor de riesgos de terceros, dónde se pueden combinar con los datos recibidos de los sitios web visitados por el usuario para que el motor de riesgos pueda proporcionar al usuario un análisis de inteligencia de riesgos aumentado.
[0037] En otra ampliación adicional, describimos una forma de realización preferida que permite comunicaciones directas de solicitudes de autenticación y de información de transacciones entre el sitio web y el servidor de seguridad. Más particularmente, como se describe con referencia a las figuras 4 y 5, el usuario primero pasó por una fase de configuración y personalización, que es un proceso único, y luego inició o activó la ventana emergente utilizando una técnica, como la autenticación fuera de banda. En este punto, el servidor de seguridad tenía un canal de comunicación activo o una sesión abierta para el usuario que identificó mediante algún identificador de usuario, por ejemplo, el número de teléfono usado para la autenticación fuera de banda. Además, el sitio web en el que el usuario realizaba transacciones y el servidor de seguridad tenían un secreto compartido previamente acordado.
[0038] El usuario utilizó el navegador para seleccionar una transacción, por ejemplo, "Pagar a Alicia 100 $", que fue transmitida por el navegador del usuario al servidor web. El servidor web transmitió esta transacción al servidor de seguridad a través de un enlace directo que se había establecido entre el sitio web y el servidor de seguridad (en vez de a través del navegador del usuario). El servidor de seguridad calculó una firma de transacción única en función de (i) los detalles de la transacción y (ii) el secreto que compartió con ese sitio web particular. A continuación, el servidor de seguridad transmitió esta firma de transacción única a la ventana emergente del usuario. El usuario cortó y pegó o, de otro modo, copió esta firma de transacción única en el navegador web y la firma se transmitió de regreso al sitio web. El sitio web calculó de forma independiente la firma de transacción utilizando (i) los detalles de la transacción y (ii) el secreto que compartió con el servidor de seguridad, y la comparó con la recibida del usuario. Si las dos firmas coinciden, entonces el servidor web tenía la seguridad de que el servidor de seguridad vio la misma transacción que envió (es decir, no una transacción manipulada en ruta al servidor de seguridad) y, dado que el servidor de seguridad mostró al usuario la transacción en un canal o una sesión independiente, se obtuvo la confirmación del usuario de la transacción.
[0039] También describimos previamente cómo se puede implementar la ventana emergente en uno de una variedad de diferentes factores de forma. Una variedad contempló que la ventana emergente estaba en una aplicación en un dispositivo móvil, otra contempló que la ventana utilizaba una parte dedicada del área de visualización de un dispositivo de red móvil personal, como un teléfono inteligente, y la última contempló que la ventana emergente estaba incorporada en elhardwarededicado similar al de una tarjeta inteligente, que tiene capacidades de comunicación. En todos los casos, todas las funcionalidades funcionarán exactamente de la misma forma, excepto que el usuario ya no puede cortar y pegar las contraseñas de un solo uso utilizadas para la autenticación y, en su lugar, tendrá que escribirlas en el navegador web que funciona en un dispositivo de red diferente. Estos factores de forma proporcionan capas adicionales de seguridad simplemente por ser independientes del escritorio del ordenador del usuario que ejecuta el navegador.
Las ampliaciones actuales de nuestro trabajo previo
[0040] Ahora ampliamos nuestro trabajo anterior a iPhones™ y otros dispositivos de comunicación móvil inteligentes más sofisticados (que se denominarán más adelante teléfonos inteligentes o SPs, por sus siglas en inglés). Más particularmente, describiremos un protocolo innovador que utiliza una autenticación cuasi fuera de banda modificada (MQOOBA, por sus siglas en inglés) en vez de la autenticación cuasi fuera de banda (QOOBA, por sus siglas en inglés) que hemos descrito previamente.
[0041] De acuerdo con el presente protocolo, una aplicación de SP de MQOOBA, por ejemplo, iPhone o iPad, (que comúnmente se conoce como la aplicación Hawk and Seal y a menudo se la denomina a continuación aplicación Authentify™ ("Authentify™ Application") o "AA" elimina la necesidad y, por lo tanto, reemplaza la ventana de QOOBA. La AA se puede usar:
1. Para interactuar con otras aplicaciones de teléfonos inteligentes (SPAs, por sus siglas en inglés), como aplicaciones de banca en línea;
2. Para proporcionar números de identificación personal (PINs) para la navegación web a través de un sistema de autenticación; y/o
3. Como base para los pagos por teléfono móvil a través de un sistema de pagos.
Descripción general
[0042] Ahora describiremos cómo se puede utilizar la AA para proporcionar un método de pago seguro junto con otras SPAs y sin que las otras SPAs conozcan las credenciales de usuario del sistema de pagos. También mostraremos cómo la AA se integra fácilmente en una aplicación de banca en línea.
[0043] En el siguiente ejemplo, el SP tiene la AA y una aplicación de muestra para la tienda eDuckies. En este ejemplo, se supone que la AA y la aplicación de eDuckies (EDA, por sus siglas en inglés) no realizan múltiples tareas. Cada una tiene almacenamiento privado que nadie más puede ver. La AA también cuenta con almacenamiento público que cualquier otra SPA puede ver.
[0044] El usuario abre la AA e inicia sesión, quizás una vez al día. Por ejemplo, el usuario puede introducir su número de teléfono, por ejemplo, el número de teléfono del SP o la AA pueden rellenar automáticamente esta información según las preferencias del usuario. Entre bastidores, la AA habla con el servidor de autenticación (a veces también denominado servidor de seguridad), que luego emite un PIN de inicio de sesión al usuario a través de un servicio de mensajes cortos (SMS, por sus siglas en inglés), que ahora se conoce comúnmente como servicio de mensajería de texto.
[0045] El usuario recibe el mensaje de texto con el PIN de inicio de sesión e introduce el PIN de inicio de sesión recibido en la AA. En algunas plataformas de SP, la AA se puede configurar, si así se desea, para recuperar el PIN del flujo de SMS entrante y rellenar automáticamente el PIN de inicio de sesión, lo que lo hace aun más fácil para los usuarios. La AA almacena un equivalente privado de unacookiede sesión, que la utilizará para autenticaciones posteriores en el servidor de autenticación para obtener los PINs de transacciones cuando estén disponibles. La A<a>también se comunica con las SPAs utilizando el método más apropiado. Una ventaja única de esta invención es la capacidad de utilizar almacenamiento público compartido, como portapapeles públicos en el sistema operativo de los iPhones.
[0046] El usuario ahora ha iniciado sesión y una sesión de MQOOBA está activa. El usuario ahora puede comenzar a utilizar otras SPAs y regresar a la AA cuando sea necesario.
[0047] En este ejemplo, el usuario ahora navega por la aplicación de eDuckies o EDA y finalmente desea realizar un pedido. A eDuckies le gustaría obtener la autorización de este pedido sin problemas. Sin embargo, sería inseguro permitir que el usuario proporcione credenciales de pago a la EDA.
[0048] En consecuencia, la EDA publica la transacción en el servidor de autenticación, que aquí sirve como sistema de pagos. La EDA también solicita al usuario que autorice la transacción en la AA. Esto es similar a cuando un usuario es redirigido a un sitio web de pagos, como PayPal™, para autorizar una transacción. El servidor de autenticación publicará la transacción en la AA para su presentación al usuario.
[0049] De vuelta a la AA, el usuario ve una transacción en espera, la obtiene y ve que parece legítima. En consecuencia, el usuario autoriza la transacción. Se debería entender que la MQOOBA hace que sea extremadamente difícil para un atacante, incluso uno que de alguna manera haya descargado una aplicación de eDuckies en el teléfono del usuario, poder falsificar esto. El PIN de MQOOBA se genera en función del secreto compartido entre el servidor de autenticación y la web del comerciante legítimo, como eDuckies, y la información de la transacción, etc., si corresponde.
[0050] Después de que el usuario autorice la transacción en la AA, al regresar a la EDA, el usuario ve el PIN rellenado automáticamente. Entre bastidores, el servidor de autenticación generó el PIN (utilizando la información de transacción proporcionada por la EDA y el secreto compartido por el servidor de autenticación y eDuckies) y lo transfirió desde el servidor de autenticación a la AA. A continuación, la AA transfirió el PIN a la EDA en el SP del usuario utilizando el almacenamiento compartido. También debería entenderse que, si se desea, se le podría solicitar al usuario que copie manualmente el PIN de la AA a la EDA en lugar de rellenar el PIN automáticamente. En cualquier caso, después de rellenar el PIN en la EDA, cuando el usuario hace clic en "completar autorización", la EDA envía el PIN al sitio web de eDuckies. El servicio web de eDuckies volverá a calcular el PIN e informará a la AA si era válido o no.
Descripción detallada
[0051] Como se analizó anteriormente, la AA proporciona al usuario PINs dinámicos de inicio de sesión y autorización de transacciones para sitios web de comerciantes particulares y para transacciones particulares. La AA puede obtener estos PINs del sitio web del servidor de autenticación, después de haber iniciado sesión dentro de la AA.
[0052] En resumen:
1. El usuario accede al sitio web del servidor de autenticación.
2. A partir de entonces, cuando el usuario se encuentra en el sitio web de un comerciante participante y necesita iniciar sesión o autorizar una transacción, se le solicita al usuario que proporcione un nuevo PIN. 3. A continuación, el usuario acude a la AA y esta le mostrará el nombre del comerciante y la transacción y le proporcionará el PIN que autoriza la transacción.
[0053] Con referencia ahora a la figura 6, se muestra un SP 600. El SP 600 incluye una CPU 605 y una pantalla de visualización 615. El SP 600 también tiene varias SPAs ejecutables por la CPU 605 cargadas en la misma, incluida la AA 610, la EDA 612 y una aplicación de SMS (SMSA) 614 para mensajería de texto. Como se muestra, la AA 610 utiliza tanto la memoria pública 610a como la memoria privada 610b y la EDA 612 utiliza la memoria pública 612a. Con referencia a la figura 7, la CPU 605 puede ejecutar la AA 610 para interactuar con el servidor de seguridad 625 y puede ejecutar la EDA 612 para interactuar con el sitio web de eDuckies 650 y el servidor de seguridad 625.
Inicio de sesión del servidor de autenticación inicial
[0054] Como se muestra en la figura 8, cuando se inicia la ejecución de la AA 610, esto provoca la visualización de un logotipo en el área A1 de la pantalla de visualización 615. La visualización en el área A1 solicita un identificador de usuario, como el número de teléfono, por ejemplo, un número de teléfono móvil, asociado a SP 600. Preferiblemente, al usuario se le ha permitido previamente seleccionar entre una opción manual, que si se selecciona requeriría que el usuario rellene automáticamente el identificador, y una opción automática, que si se selecciona serviría como directriz para la AA 610 para rellenar previamente el espacio proporcionado en la visualización del área A1 con el identificador de usuario aplicable, por ejemplo, el número de teléfono móvil del SP. (Véase, en el caso del iPhone, http://arstechnica.com/apple/news/2009/01/iphone-dev-user-phonenumbers.ars).
[0055] Cuando el usuario hace clic en la flecha en el área A1, la AA provoca una publicación en el servidor de autenticación 625. El servidor de autenticación 625 devuelve una indicación de reconocimiento a la AA 610 y, si el mensaje fue reconocido, la AA 610 también provoca la presentación de lo que se muestra en el área A2 de la pantalla de visualización 615 representada en la figura 7. Como se indica en el área A2, si tiene éxito el servidor de autenticación 625 SMS, es decir, texto, envía un PIN al usuario a la dirección de SMS del usuario. Al activar la ejecución de la SMSA 614 por parte de la CPU 605, el usuario puede acceder a su cuenta de SMS y recuperar el PIN del mensaje SMS enviado por el servidor de autenticación. A continuación, el usuario introduce el PIN en el espacio proporcionado en el área A2, por ejemplo, cortando y pegando el PIN del mensaje SMS. Después de introducir el PIN, el usuario hace clic en la flecha en el área A2 y la AA 610 envía un segundo mensaje de interfaz de programación de aplicaciones (API, por sus siglas en inglés) para publicar el PIN.
[0056] Como se muestra en la figura 8, el mensaje de retorno del servidor de seguridad 625, si tiene éxito, devuelve unacookiede sesión, un número aleatorio que llamamos "nonce-login" y un tiempo de vida (TTL), y la AA 610 provoca la visualización mostrada en el área A3 de la pantalla de visualización 615.
[0057] Cabe destacar que, en vez de elegir simplemente entre el relleno manual y automático, al usuario se le podría permitir, adicional o alternativamente, seleccionar o solicitar que introduzca un nombre de usuario en el área A1 y una contraseña en el área A2. Se debería entender que la elección entre manual y automático descrita anteriormente es solo una de las opciones descritas en el presente documento. Por lo tanto, a continuación, se describirá otra elección entre manual y automático en el contexto de la autorización de transacciones y, más particularmente, con respecto a si la AA transmite a la EDA un PIN diferente, que está asociado a una autorización de transacción, automáticamente o solo después una introducción manual por parte del usuario.
[0058] Haciendo referencia nuevamente a la figura 6, lacookiede sesión se almacena de forma privada en la memoria privada 610b. Elnonce-loginy el TTL se almacenan públicamente en un portapapeles personalizado, el portapapeles público de AA, que se crea dentro de la memoria pública 610a (véase, en el caso del iPhone, portapapeles personalizados Ref: http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPho neOSProgrammingGuide/EventHandling/EventHandling.html#//apple_ref/doc/uid /TP40007072-CH9-SW28). Cuando el usuario dirige su "enfoque" a la AA 610, la AA 610 siempre verifica elnoncey el TTL. Si el TTL ha expirado, la AA hace que la visualización de lo que se muestra en el área A1 de la pantalla de visualización 615 de la figura 8 comience nuevamente el inicio de sesión en el servidor de autenticación 625.
Inicio de sesión y/o autorización de transacciones en el sitio web
[0059] Volviendo nuevamente a la figura 9, cuando el usuario se encuentra en algún otro SPA, por ejemplo, la EDA o el sitio web y se le ha solicitado un PIN, ya sea para fines de inicio de sesión o de autorización de transacción, el usuario es redirigido a la AA, como se explicará más adelante con referencia a la figura 11. Para los fines de la siguiente descripción, asumiremos que el usuario se encuentra en la EDA. Junto con esta redirección, la EDA publica información en el servidor de seguridad 625. Esta información incluye si si se solicita el inicio de sesión o la autorización de transacción, el nombre del comerciante, por ejemplo, eDuckies, y, si se solicita la autorización de transacción, el texto de la transacción. Si el servidor de seguridad tiene la capacidad para enviar información a la AA, el servidor de seguridad 625 provoca una publicación de esta información en la AA. La AA 610 provoca la visualización de la información publicada por el servidor de seguridad 625 en el área A4 de la figura 10 o lo que se muestra en el área A1 de la figura 8 si se requiere volver a iniciar sesión en el servidor de autenticación 625. Para los fines de esta explicación, asumimos que se muestra el área A4.
[0060] Alternativamente, si la AA no tiene la capacidad de ENVIAR DE MANERA FORZADA, confiamos en que el usuario EXTRAIGA los datos. Este es el flujo que se muestra en las figuras. Cuando el usuario hace clic en la flecha en el área A3 de la figura 9, la AA provoca una publicación en el servidor de seguridad 625. La publicación incluye lacookiede sesión anteriormente descrita.
[0061] El servidor de seguridad 625 devuelve un mensaje de éxito o fallo. El mensaje de retorno siempre devuelve un indicador que indica el inicio de sesión o la autorización de la transacción, el nombre del comerciante, por ejemplo, eDuckies, un nuevo inicio de sesión sinnonce,un nuevo TTL y un PIN. Si se trata de una autorización de transacción, también devuelve el texto de la transacción. Si tiene éxito, la AA provoca la visualización mostrada en el área A4 de la pantalla de visualización A4 de la figura 10.
[0062] Si el usuario hace clic en la señal de detención(stop),se le dirige de regreso a la pantalla mostrada en la figura 9. Preferiblemente, se envía una alarma al servidor de seguridad 625, a la EDA 612 y desde allí al sitio web de comerciante 650, y/o a algún otro sitio web relacionado con la seguridad.
[0063] Por otro lado, si el usuario hace clic en la flecha mostrada en el área A4 de la pantalla de visualización 615, elnonce-loginy el TTL se escriben en el portapapeles público de la AA en el almacenamiento público 610a. El PIN de inicio de sesión o de transacción, según corresponda, también se escribe en el portapapeles utilizando el identificador del comerciante y la combinación de PIN. Elmerchantid.PINse escribe sobre cualquierMerchantid.PINanterior. Ahora, el usuario vuelve nuevamente a ver la visualización mostrada en la figura 9. Alternativamente, si la transferencia manual del PIN es la opción seleccionada, entonces al usuario se le mostrará el PIN dentro de la AA y el usuario tiene la responsabilidad de copiarlo de la AA a la EDA.
[0064] Quizás valga la pena enfatizar aquí que, de acuerdo con nuestro trabajo anterior descrito con mayor detalle anteriormente, el PIN de inicio de sesión o de transacción es generado por el servidor de seguridad 625 en base a un secreto compartido por el servidor de seguridad y el sitio web, y no compartido con o conocido por el usuario. Además, si se solicita la autorización de la transacción, el PIN de transacción es generado por el servidor de seguridad 625 usando también información de la transacción.
[0065] Cabe señalar que la EDA comprueba si hay un portapapeles público de la AA con unlogin-noncecon TTL válido para el usuario Si no es así, informa al usuario de que él/ella no parece haber iniciado sesión en la AA. Aquí hemos asumido que el usuario ha iniciado sesión y que la EDA ha determinado que el portapapeles público de la AA tiene unnonceválido.
[0066] Para los fines de esta descripción, asumiremos que la autorización de la transacción está involucrada. Volviendo ahora a la figura 11, el usuario está en la EDA y se le presenta la información de la transacción mostrada en el área M1 de la pantalla de visualización 615. Cuando el usuario hace clic en la flecha mostrada en el área M1, se le redirige a la AA y la AA publica la información relacionada con el comerciante y la transacción en el servidor de seguridad 625. La publicación incluye ellogin-nonce.El servidor de seguridad 625 devuelve un éxito o un error. Si tiene éxito, entonces la AA presenta al usuario la visualización mostrada en el área M2 de la pantalla de visualización 615 representada en la figura 12. Si el usuario hace clic en la flecha mostrada en el área M2, se realiza el proceso de autorización de la transacción anteriormente descrito y el mensaje de regreso incluye una cadena.
[0067] Cuando el foco vuelve a la EDA, la EDA sondea la AA para ver si hay un nuevomerchantid.PIN.Una vez que la EDA lo localiza, hace una publicación en el sitio web de eDuckies de la CADENA y el PIN de autorización de la transacción. El sitio web devolverá un mensaje de éxito o error después de que se realice su propia verificación del PIN. Cabe señalar que, si se elige la opción de transferencia de PIN manual, el usuario debe introducir el PIN de autorización de la transacción en la EDA.

Claims (15)

REIVINDICACIONES
1. Método de autenticación de un usuario de un dispositivo de comunicación móvil (600), que comprende: dirigir, mediante una primera aplicación o un primer programa (612) que se ejecuta en el dispositivo de comunicación móvil (600), la transmisión, desde el dispositivo de comunicación móvil (600) hasta un servidor de seguridad (625), de una solicitud de autenticación del usuario en relación con (i) el usuario que inicia sesión o (ii) el usuario que realiza una transacción con un sitio de red (650);
recibir, mediante una segunda aplicación o un segundo programa (610) que se ejecuta en el dispositivo de comunicación móvil (600), la solicitud de autenticación desde el servidor de seguridad (625);
dirigir, mediante la segunda aplicación o el segundo programa (610), la presentación por parte del dispositivo de comunicación móvil (600) de la solicitud de autenticación recibida al usuario;
recibir, mediante la segunda aplicación o el segundo programa (610), una entrada de usuario al dispositivo de comunicación móvil (600) que indica que se debería continuar con la autenticación solicitada;
dirigir, mediante la segunda aplicación o el segundo programa (610) en respuesta a la entrada de usuario recibida, la transmisión, desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625), de una indicación de que se debería continuar con la autorización solicitada;
recibir, mediante la segunda aplicación o el segundo programa (610) desde el servidor de seguridad (625), un número de identificación personal (PIN), en respuesta a la transmisión de la indicación de que se debería continuar con la autorización solicitada;
almacenar, mediante la segunda aplicación o el segundo programa (610), el PIN recibido en una memoria pública de datos en el dispositivo de comunicaciones móviles (600);
recuperar, mediante la primera aplicación o el primer programa (612), el PIN almacenado de la memoria pública de datos; y
dirigir, mediante la primera aplicación o el primer programa (612), la transmisión, desde el dispositivo de comunicaciones móviles (600) hasta el sitio de red, del PIN recuperado, para autenticar al usuario o la transacción en el sitio de red (650);
donde, preferiblemente, el dispositivo de comunicación móvil (600) es un teléfono inteligente.
2. Método según la reivindicación 1, que comprende, además:
almacenar, mediante la segunda aplicación o el segundo programa (610) en la memoria pública de datos, información que indica que existe o no existe una sesión activa entre la segunda aplicación o el segundo programa (610) y el servidor de seguridad (625);
recibir, mediante la primera aplicación o el primer programa (612), una solicitud del usuario para acceder al sitio de red (650) o para realizar una transacción con el sitio de red (650); y
determinar, mediante la primera aplicación o el primer programa (612) en base a la información almacenada de la sesión activa, si existe o no una sesión activa;
donde la primera aplicación o el primer programa (612) dirige la transmisión, desde el dispositivo de comunicaciones móviles (600) hasta un servidor de seguridad (625), de la solicitud de autenticación del usuario solo si se determina que existe una sesión activa.
3. Método según la reivindicación 2, donde la información almacenada que indica que existe o no existe una sesión incluye un número aleatorio y un tiempo de vida (TTL), y que comprende, además:
recibir, mediante la segunda aplicación o el segundo programa (610) desde el servidor de seguridad (625), un nuevo número aleatorio y un nuevo TTL con el PIN, en respuesta a la transmisión de la indicación de que se debería continuar con la autorización solicitada; y
almacenar, mediante la segunda aplicación o el segundo programa (610) en la memoria pública de datos, el nuevo número aleatorio y el nuevo TTL como información actual que indica que existe o no existe una sesión activa entre la segunda aplicación o el segundo programa (610) y el servidor de seguridad (625).
4. Método según la reivindicación 1, donde el PIN corresponde a un secreto compartido únicamente por el servidor de seguridad (625) y el sitio de red (650), y no por el usuario.
5. Método según la reivindicación 1, que comprende, además:
recibir, mediante la segunda aplicación o el segundo programa (610), una solicitud del usuario para iniciar sesión en el servidor de seguridad (625);
dirigir, mediante la segunda aplicación o el segundo programa (610), la transmisión de la solicitud y un identificador de usuario desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625);
recibir, mediante una tercera aplicación o un tercer programa que se ejecuta en el dispositivo de comunicación móvil (600) desde el servidor de seguridad (625), un mensaje que incluye un segundo PIN, en respuesta a la solicitud transmitida;
dirigir, mediante la tercera aplicación o el tercer programa, la visualización, por parte del dispositivo de comunicación móvil (600), del segundo PIN;
recibir, mediante la segunda aplicación o el segundo programa (610), una segunda entrada de usuario que incluye el segundo PIN mostrado;
dirigir, mediante la segunda aplicación o el segundo programa (610), la transmisión, desde el dispositivo de comunicación móvil hasta el servidor de seguridad (625), del segundo PIN introducido recibido;
recibir, mediante la segunda aplicación o el segundo programa (610) desde el servidor de seguridad (625), unacookiede sesión e información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre la segunda aplicación o el segundo programa (610) y el servidor de seguridad (625) permanecerá activa, en respuesta a la transmisión del segundo PIN; y
almacenar, mediante la segunda aplicación o el segundo programa (610), (i) lacookiede sesión en una memoria privada de datos a la que solo puede acceder la segunda aplicación o el segundo programa (610) y (ii) la información de sesión activa en la memoria pública de datos para que pueda acceder la segunda aplicación o el segundo programa (610).
6. Artículo de fabricación para autenticar a un usuario de un dispositivo de comunicación móvil (600),caracterizado por:
un medio de almacenamiento no transitorio legible por un procesador; y
un programa almacenado en el medio de almacenamiento, donde el programa almacenado está configurado para ser legible por un procesador y, por lo tanto, hace que el procesador haga funcionar una segunda aplicación (610) según el método de la reivindicación 1 para:
recibir, desde un servidor de seguridad (625), una solicitud de autenticación del usuario en relación con (i) el usuario que inicia sesión o (ii) el usuario que realiza una transacción con un sitio de red (650); dirigir una presentación, por parte del dispositivo de comunicación móvil (600), de la solicitud recibida de autenticación al usuario;
recibir una entrada de usuario al dispositivo de comunicación móvil (600) que indica que se debería continuar con la autenticación solicitada;
dirigir, en respuesta a la entrada de usuario recibida, la transmisión, desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625), de una indicación de que se debería continuar con la autorización solicitada;
recibir, desde el servidor de seguridad (625), un número de identificación personal (PIN), en respuesta a la transmisión de la indicación de que se debería continuar con la autorización solicitada; y almacenar el PIN recibido en una memoria pública de datos en el dispositivo de comunicaciones móviles (600) para que esté disponible para otro programa ejecutable por el dispositivo de comunicaciones móviles, donde dicho otro programa es una primera aplicación (612) según el método de la reivindicación 1, para facilitar, por tanto, la transmisión del PIN recibido desde el dispositivo de comunicación móvil (600) hasta el sitio de red (650) para autenticar, de este modo, al usuario o la transacción en el sitio de red (650);
donde, preferiblemente, el PIN corresponde a un secreto compartido únicamente por el servidor de seguridad (625) y el sitio de red (650), y no por el usuario.
7. Artículo de fabricación según la reivindicación 6, donde el programa almacenado está configurado, además, para hacer que el procesador funcione para:
almacenar, en la memoria pública de datos, información que indique que existe o no existe una sesión activa entre el programa almacenado y el servidor de seguridad (625);
donde la solicitud de autenticación solo se recibe desde el servidor de seguridad (625) si la información almacenada indica que existe una sesión activa.
8. Artículo de fabricación según la reivindicación 7, donde la información almacenada que indica que existe o no existe una sesión activa incluye un número aleatorio y un tiempo de vida (TTL), y el programa almacenado está configurado, además, para hacer que el procesador funcione para:
recibir, desde el servidor de seguridad (625), un nuevo número aleatorio y un nuevo TTL con el PIN; y almacenar, en la memoria pública de datos, el nuevo número aleatorio y el nuevo TTL como información actual que indica que existe o no existe una sesión activa entre el programa almacenado y el servidor de seguridad (625).
9. Artículo de fabricación según la reivindicación 6, donde el programa almacenado está configurado, además, para hacer que el procesador funcione para:
recibir una solicitud del usuario para iniciar sesión en el servidor de seguridad (625);
dirigir la transmisión de la solicitud y un identificador de usuario desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625);
recibir otra entrada de usuario que incluye un segundo PIN;
dirigir la transmisión, desde el dispositivo de comunicación móvil (600) hasta el servidor de seguridad (625), del segundo PIN recibido;
recibir, desde el servidor de seguridad (625), unacookiede sesión e información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre el programa y el servidor de seguridad (625) permanecerá activa, en respuesta a la transmisión del segundo PIN recibido; y
almacenar (i) lacookiede sesión recibida en una memoria privada de datos a la que solo puede acceder el programa y (ii) la información de sesión activa en la memoria pública de datos para que puedan acceder otros programas ejecutables por el dispositivo de comunicación móvil (600).
10. Dispositivo de comunicación móvil (600) para autenticar a un usuario, que comprende:
una pantalla de visualización; y
un dispositivo de entrada de usuario;
caracterizado por
un primer programa;
un segundo programa (610);
una memoria pública de datos;
un procesador configurado para
(1) ejecutar el primer programa para dirigir la transmisión, desde el dispositivo de comunicación móvil (600) hasta un servidor de seguridad (625), de una solicitud de autenticación del usuario en relación con (1) el usuario que inicia sesión o (ii) el usuario que realiza una transacción con un sitio de red (650), (2) ejecutar el segundo programa para (a) recibir la solicitud de autenticación desde el servidor de seguridad (625), (b) dirigir la presentación de la solicitud de autenticación recibida en la pantalla de visualización, (c) recibir una entrada de usuario del dispositivo de entrada de usuario que indica que se debería continuar con la autenticación solicitada, (d) dirigir, al servidor de seguridad (625), en respuesta a la entrada de usuario recibida, la transmisión de una indicación de que se debería continuar con la autorización solicitada, (e) recibir, desde el servidor de seguridad (625) en respuesta a la transmisión de la indicación de que se debería continuar con la autorización solicitada, un número de identificación personal (PIN), y (f) almacenar el PIN el recibido en la memoria pública de datos, y (3) ejecutar el primer programa para (a) recuperar el PIN almacenado de la memoria pública de datos y (b) dirigir la transmisión, al sitio de red (650), del PIN recuperado para autenticar al usuario o la transacción en el sitio de red (650).
11. Dispositivo de comunicaciones móviles según la reivindicación 10, donde:
el procesador está configurado, además, para (1) ejecutar el segundo programa para almacenar, en la memoria pública de datos, información que indica que existe o no existe una sesión activa entre el segundo programa y el servidor de seguridad (625), (2) ejecutar el primer programa para (a) dirigir la transmisión de una solicitud del usuario para acceder al sitio de red (650) o para realizar una transacción con el sitio de red (650) y (b) determinar, en base a la información de sesión activa almacenada, si existe o no una sesión activa;
el proceso ejecuta el primer programa para dirigir la transmisión, a un servidor de seguridad (625), de la solicitud de autenticación del usuario solo si se determina que existe una sesión activa,
donde, preferiblemente:
la información almacenada que indica que existe o no existe una sesión activa incluye un número aleatorio y un tiempo de vida (TTL);
el procesador está configurado, además, para ejecutar el segundo programa para (a) recibir, desde el servidor de seguridad (625) en respuesta a la transmisión de la indicación de que se debería continuar con la autorización solicitada, un nuevo número aleatorio y un nuevo TTL con el PIN y (b) almacenar, en la memoria pública de datos, el nuevo número aleatorio y el nuevo TTL como información actual que indica que existe o no existe una sesión activa entre el segundo programa y el servidor de seguridad (625).
12. Dispositivo de comunicaciones móviles según la reivindicación 10,
donde el PIN corresponde a un secreto compartido únicamente por el servidor de seguridad (625) y el sitio de red (650), y no por el usuario, y/o
donde el dispositivo de comunicaciones móviles (600) comprende, además:
un tercer programa; y
una memoria privada de datos;
donde el procesador está configurado, además, para ejecutar (1) el segundo programa para (a) recibir una entrada de usuario al dispositivo de entrada de usuario que representa una solicitud del usuario para iniciar sesión en el servidor de seguridad (625) y (b) dirigir la transmisión de la solicitud recibida y un identificador de usuario al servidor de seguridad (625), (2) ejecutar el tercer programa para (a) recibir, desde el servidor de seguridad (625), un mensaje que incluye un segundo PIN, en respuesta a la solicitud transmitida, y (b) dirigir la presentación al usuario en la pantalla de visualización, del segundo PIN, y (3) ejecutar el segundo programa para
(a) recibir una segunda entrada de usuario al dispositivo de entrada de usuario que representa el segundo PIN mostrado, (b) dirigir la transmisión, al servidor de seguridad (625), del segundo PIN representado en el la segunda entrada de usuario recibida, (c) recibir, desde el servidor de seguridad (625) en respuesta a la transmisión del segundo PIN, unacookiede sesión e información de sesión activa que indica un periodo de tiempo durante el cual la sesión entre el segundo programa y el servidor de seguridad (625) permanecerá activa y (d) almacenar (i) lacookiede sesión en la memoria privada de datos a la que solo puede acceder el segundo programa y (ii) la información de sesión activa en la memoria pública de datos para que pueda acceder el segundo programa.
13. Servidor de seguridad para autenticar a un usuario de un dispositivo de comunicaciones móviles, que comprende:
un puerto de comunicaciones;
caracterizado por
un procesador configurado para (1) recibir, desde un primer programa (612) que se ejecuta en el dispositivo de comunicación móvil (600) a través del puerto de comunicaciones, una solicitud de autenticación del usuario en relación con (i) el usuario que inicia sesión o (ii) el usuario que realiza una transacción con un sitio de red (650), (2) dirigir la transmisión, a un segundo programa (610) que se ejecuta en el dispositivo de comunicación móvil (600) a través del puerto de comunicaciones, de la solicitud recibida de autenticación, (3) recibir, desde el segundo programa (610) a través del puerto de comunicaciones, una indicación de que se debería continuar con la autorización solicitada y (4) dirigir la transmisión, al segundo programa (610) a través del puerto de comunicaciones, de un número de identificación personal (PIN) para autenticar al usuario o la transacción en el sitio de red, en respuesta a la indicación recibida de que se debería continuar con la autorización solicitada y para autenticar al usuario en el sitio de red (650).
14. Servidor de seguridad según la reivindicación 13,
donde el servidor de seguridad (625) está configurado, además, para recibir la solicitud de autenticación del usuario desde el primer programa (612) solo si existe una sesión activa entre el segundo programa (610) y el servidor de seguridad (625); y/o
donde el PIN corresponde a un secreto compartido únicamente por el servidor de seguridad (625) y el sitio de red (650), y no por el usuario.
15. Servidor de seguridad según la reivindicación 13, donde:
el procesador está configurado, además, para (1) recibir, desde el segundo programa (610) a través del puerto de comunicaciones, una solicitud del usuario para iniciar sesión en el servidor de seguridad, (2) dirigir la transmisión, a un tercer programa que se ejecuta en el dispositivo de comunicación móvil (600), de un mensaje que incluye un segundo PIN, en respuesta a la solicitud de inicio de sesión recibida, (3) recibir, por parte del segundo programa (610) a través del puerto de comunicaciones, el segundo PIN transmitido, (4) autenticar al usuario en base al segundo PIN recibido y dirigir la (5) transmisión, al segundo programa (610) a través del puerto de comunicaciones, de unacookiede sesión e información de sesión activa que indica un periodo de tiempo durante el cual la sesión permanecerá activa, en base a la autenticación del usuario.
ES21151197T 2010-04-26 2011-04-13 Autenticación de inicio de sesión y de transacciones segura y eficiente utilizando iPhones y otros dispositivos de comunicación móvil inteligentes Active ES2972816T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US32772310P 2010-04-26 2010-04-26
US13/081,067 US8719905B2 (en) 2010-04-26 2011-04-06 Secure and efficient login and transaction authentication using IPhones™ and other smart mobile communication devices

Publications (1)

Publication Number Publication Date
ES2972816T3 true ES2972816T3 (es) 2024-06-17

Family

ID=44816912

Family Applications (2)

Application Number Title Priority Date Filing Date
ES11775429T Active ES2856195T3 (es) 2010-04-26 2011-04-13 Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes
ES21151197T Active ES2972816T3 (es) 2010-04-26 2011-04-13 Autenticación de inicio de sesión y de transacciones segura y eficiente utilizando iPhones y otros dispositivos de comunicación móvil inteligentes

Family Applications Before (1)

Application Number Title Priority Date Filing Date
ES11775429T Active ES2856195T3 (es) 2010-04-26 2011-04-13 Autenticación de inicio de sesión y de transacción segura y eficiente usando iPhones y otros dispositivos de comunicación móvil inteligentes

Country Status (8)

Country Link
US (2) US8719905B2 (es)
EP (2) EP2564308B1 (es)
JP (2) JP5595586B2 (es)
AU (1) AU2011245653B2 (es)
CA (1) CA2794589C (es)
ES (2) ES2856195T3 (es)
SG (1) SG184785A1 (es)
WO (1) WO2011136928A1 (es)

Families Citing this family (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8806592B2 (en) 2011-01-21 2014-08-12 Authentify, Inc. Method for secure user and transaction authentication and risk management
US8789153B2 (en) * 2010-01-27 2014-07-22 Authentify, Inc. Method for secure user and transaction authentication and risk management
US10581834B2 (en) 2009-11-02 2020-03-03 Early Warning Services, Llc Enhancing transaction authentication with privacy and security enhanced internet geolocation and proximity
WO2012065128A1 (en) * 2010-11-11 2012-05-18 Ebay Inc. Quick payment using mobile device binding
FR2968795B1 (fr) * 2010-12-10 2013-01-18 Xiring Dispositif d'appairage dynamique
US8640213B2 (en) * 2011-02-07 2014-01-28 Symantec Corporation Method and system for automatic authentication
US8752208B2 (en) * 2011-05-13 2014-06-10 Imperva Inc. Detecting web browser based attacks using browser digest compute tests launched from a remote source
US8346672B1 (en) * 2012-04-10 2013-01-01 Accells Technologies (2009), Ltd. System and method for secure transaction process via mobile device
US9098678B2 (en) * 2011-09-15 2015-08-04 Verizon Patent And Licensing Inc. Streaming video authentication
US8862888B2 (en) * 2012-01-11 2014-10-14 King Saud University Systems and methods for three-factor authentication
US12363112B2 (en) * 2012-02-02 2025-07-15 Josiah Umezurike Real-time analysis plugin for cyber defense
US9237215B2 (en) * 2012-02-10 2016-01-12 Time Warner Cable Enterprises Llc Remote activation of mobile applications
US10395247B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc Systems and methods for facilitating a secure transaction at a non-financial institution system
US11593800B2 (en) 2012-03-07 2023-02-28 Early Warning Services, Llc System and method for transferring funds
US20130238488A1 (en) 2012-03-07 2013-09-12 Clearxchange, Llc System and method for transferring funds
US10395223B2 (en) 2012-03-07 2019-08-27 Early Warning Services, Llc System and method for transferring funds
US10970688B2 (en) 2012-03-07 2021-04-06 Early Warning Services, Llc System and method for transferring funds
US10318936B2 (en) 2012-03-07 2019-06-11 Early Warning Services, Llc System and method for transferring funds
SG11201405282RA (en) 2012-04-01 2014-09-26 Authentify Inc Secure authentication in a multi-party system
CN102710750B (zh) * 2012-05-10 2015-03-04 上海克而瑞信息技术有限公司 一种B/S系统与Ipad实现用户硬件绑定的方法与装置
US10025920B2 (en) * 2012-06-07 2018-07-17 Early Warning Services, Llc Enterprise triggered 2CHK association
FR2993382B1 (fr) * 2012-07-13 2015-07-03 Oberthur Technologies Entite electronique securisee pour l'autorisation d'une transaction
CN103685384A (zh) * 2012-09-12 2014-03-26 中兴通讯股份有限公司 防恶意骚扰的用户身份验证方法及装置
US20140081683A1 (en) * 2012-09-14 2014-03-20 Sap Ag Business process management for mobile portal clients
US9396320B2 (en) 2013-03-22 2016-07-19 Nok Nok Labs, Inc. System and method for non-intrusive, privacy-preserving authentication
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9887983B2 (en) 2013-10-29 2018-02-06 Nok Nok Labs, Inc. Apparatus and method for implementing composite authenticators
US9961077B2 (en) 2013-05-30 2018-05-01 Nok Nok Labs, Inc. System and method for biometric authentication with device attestation
GB2517732A (en) * 2013-08-29 2015-03-04 Sim & Pin Ltd System for accessing data from multiple devices
KR102091606B1 (ko) * 2013-10-30 2020-03-20 엘지전자 주식회사 단말기 및 그 제어 방법
JP6378870B2 (ja) * 2013-11-15 2018-08-22 株式会社野村総合研究所 認証システム、認証方法および認証プログラム
JP5543010B1 (ja) * 2013-12-20 2014-07-09 株式会社 ディー・エヌ・エー 所定のサーバに対してログインを要求するログイン要求装置及び方法、並びにこれらに用いられるプログラム
US9577999B1 (en) 2014-05-02 2017-02-21 Nok Nok Labs, Inc. Enhanced security for registration of authentication devices
US9654469B1 (en) 2014-05-02 2017-05-16 Nok Nok Labs, Inc. Web-based user authentication techniques and applications
US10148630B2 (en) 2014-07-31 2018-12-04 Nok Nok Labs, Inc. System and method for implementing a hosted authentication service
US9455979B2 (en) 2014-07-31 2016-09-27 Nok Nok Labs, Inc. System and method for establishing trust using secure transmission protocols
US9875347B2 (en) 2014-07-31 2018-01-23 Nok Nok Labs, Inc. System and method for performing authentication using data analytics
US9749131B2 (en) 2014-07-31 2017-08-29 Nok Nok Labs, Inc. System and method for implementing a one-time-password using asymmetric cryptography
KR102206533B1 (ko) * 2014-08-05 2021-01-22 삼성전자주식회사 모바일 장치, 모바일 장치의 화면 표시 방법, 웨어러블 장치, 웨어러블 장치의 구동 방법 및 컴퓨터 판독가능 기록매체
US9736154B2 (en) 2014-09-16 2017-08-15 Nok Nok Labs, Inc. System and method for integrating an authentication service within a network architecture
US9367845B2 (en) 2014-09-23 2016-06-14 Sony Corporation Messaging customer mobile device when electronic bank card used
US9558488B2 (en) 2014-09-23 2017-01-31 Sony Corporation Customer's CE device interrogating customer's e-card for transaction information
US10262316B2 (en) 2014-09-23 2019-04-16 Sony Corporation Automatic notification of transaction by bank card to customer device
US9953323B2 (en) 2014-09-23 2018-04-24 Sony Corporation Limiting e-card transactions based on lack of proximity to associated CE device
US9317847B2 (en) 2014-09-23 2016-04-19 Sony Corporation E-card transaction authorization based on geographic location
US9355424B2 (en) 2014-09-23 2016-05-31 Sony Corporation Analyzing hack attempts of E-cards
US9646307B2 (en) 2014-09-23 2017-05-09 Sony Corporation Receiving fingerprints through touch screen of CE device
US9202212B1 (en) 2014-09-23 2015-12-01 Sony Corporation Using mobile device to monitor for electronic bank card communication
US9378502B2 (en) 2014-09-23 2016-06-28 Sony Corporation Using biometrics to recover password in customer mobile device
US9292875B1 (en) 2014-09-23 2016-03-22 Sony Corporation Using CE device record of E-card transactions to reconcile bank record
WO2016051353A1 (en) * 2014-09-30 2016-04-07 Eko India Financial Services Pvt. Ltd. System and ergonomically advantageous method for performing online secure transactions on trusted personal device
EP3013014A1 (en) 2014-10-21 2016-04-27 Gemalto Sa Method for accessing a service, corresponding first device, second device and system
JP2016116088A (ja) * 2014-12-15 2016-06-23 株式会社リコー 情報処理装置、情報処理方法、及びプログラム
DE102015000220A1 (de) * 2015-01-08 2016-07-14 Giesecke & Devrient Gmbh Verfahren zum sicheren Betreiben einer Computereinheit, Softwareapplikation und Computereinheit
US10832246B2 (en) 2015-03-23 2020-11-10 Early Warning Services, Llc Payment real-time funds availability
US10878387B2 (en) 2015-03-23 2020-12-29 Early Warning Services, Llc Real-time determination of funds availability for checks and ACH items
US10839359B2 (en) 2015-03-23 2020-11-17 Early Warning Services, Llc Payment real-time funds availability
US10748127B2 (en) 2015-03-23 2020-08-18 Early Warning Services, Llc Payment real-time funds availability
US10769606B2 (en) 2015-03-23 2020-09-08 Early Warning Services, Llc Payment real-time funds availability
US9614845B2 (en) 2015-04-15 2017-04-04 Early Warning Services, Llc Anonymous authentication and remote wireless token access
US11037122B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10438175B2 (en) 2015-07-21 2019-10-08 Early Warning Services, Llc Secure real-time payment transactions
US11151522B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11386410B2 (en) 2015-07-21 2022-07-12 Early Warning Services, Llc Secure transactions with offline device
US10956888B2 (en) 2015-07-21 2021-03-23 Early Warning Services, Llc Secure real-time transactions
US11062290B2 (en) 2015-07-21 2021-07-13 Early Warning Services, Llc Secure real-time transactions
US11037121B2 (en) 2015-07-21 2021-06-15 Early Warning Services, Llc Secure real-time transactions
US10963856B2 (en) 2015-07-21 2021-03-30 Early Warning Services, Llc Secure real-time transactions
US10970695B2 (en) 2015-07-21 2021-04-06 Early Warning Services, Llc Secure real-time transactions
US11151523B2 (en) 2015-07-21 2021-10-19 Early Warning Services, Llc Secure transactions with offline device
US11157884B2 (en) 2015-07-21 2021-10-26 Early Warning Services, Llc Secure transactions with offline device
US10084782B2 (en) 2015-09-21 2018-09-25 Early Warning Services, Llc Authenticator centralization and protection
US10817593B1 (en) * 2015-12-29 2020-10-27 Wells Fargo Bank, N.A. User information gathering and distribution system
CN113852594B (zh) 2015-12-31 2022-07-29 华为技术有限公司 一种验证码获取方法和终端
WO2017139374A1 (en) * 2016-02-09 2017-08-17 Ergomotion, Inc. Ultra-compact profile actuation system for an adjustable bed
US10552823B1 (en) 2016-03-25 2020-02-04 Early Warning Services, Llc System and method for authentication of a mobile device
US10637853B2 (en) 2016-08-05 2020-04-28 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US10769635B2 (en) 2016-08-05 2020-09-08 Nok Nok Labs, Inc. Authentication techniques including speech and/or lip movement analysis
US11144928B2 (en) 2016-09-19 2021-10-12 Early Warning Services, Llc Authentication and fraud prevention in provisioning a mobile wallet
CN106453352B (zh) * 2016-10-25 2020-04-17 电子科技大学 一种单系统多平台身份验证方法
US10091195B2 (en) 2016-12-31 2018-10-02 Nok Nok Labs, Inc. System and method for bootstrapping a user binding
US10237070B2 (en) 2016-12-31 2019-03-19 Nok Nok Labs, Inc. System and method for sharing keys across authenticators
US10659446B2 (en) * 2017-06-13 2020-05-19 Salesforce.Com, Inc. Conversational authentication
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US10833859B2 (en) 2017-12-07 2020-11-10 International Business Machines Corporation Automating verification using secure encrypted phone verification
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
JP6973262B2 (ja) * 2018-04-18 2021-11-24 トヨタ自動車株式会社 車両向けサービス提供システム、車載装置およびコマンド送信方法
US10944745B2 (en) 2018-12-06 2021-03-09 Bank Of America Corporation System and method for device and transaction authentication
US10986079B2 (en) 2018-12-06 2021-04-20 Bank Of America Corporation System and method for hierarchical decisioning within a hybrid blockchain
US12041039B2 (en) 2019-02-28 2024-07-16 Nok Nok Labs, Inc. System and method for endorsing a new authenticator
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
US11432149B1 (en) 2019-10-10 2022-08-30 Wells Fargo Bank, N.A. Self-sovereign identification via digital credentials for selected identity attributes
US20210204116A1 (en) 2019-12-31 2021-07-01 Payfone, Inc. Identity verification platform
JP2021136459A (ja) * 2020-02-21 2021-09-13 沖電気工業株式会社 音声通信装置、通信端末および音声通信システム
US12058528B2 (en) 2020-12-31 2024-08-06 Prove Identity, Inc. Identity network representation of communications device subscriber in a digital domain
US12499427B2 (en) 2021-08-31 2025-12-16 Early Warning Services, Llc Direct electronic bill payment with real-time funds availability
US12126613B2 (en) 2021-09-17 2024-10-22 Nok Nok Labs, Inc. System and method for pre-registration of FIDO authenticators
WO2023048707A1 (en) 2021-09-22 2023-03-30 Hewlett-Packard Development Company, L.P. Encrypted storage
US12585742B1 (en) * 2022-01-10 2026-03-24 Citibank, N.A. Securing interactions using user interface windows

Family Cites Families (73)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08235114A (ja) 1995-02-28 1996-09-13 Hitachi Ltd サーバアクセス方法と課金情報管理方法
JPH11184818A (ja) * 1997-12-25 1999-07-09 Ntt Data Corp 認証システム及び方法、並びに同システムのためのクライアントマシン
JPH11338933A (ja) 1998-05-21 1999-12-10 Micro Cabin:Kk 通信取引における取引申込者の認証システム
IL128720A (en) 1999-02-25 2009-06-15 Cidway Technologies Ltd Method for confirming actions performed over the phone
US6934858B2 (en) * 1999-12-15 2005-08-23 Authentify, Inc. System and method of using the public switched telephone network in providing authentication or authorization for online transactions
BR0111119A (pt) 2000-05-25 2004-06-22 Echarge Corp Protocolo de transação segura
JP2002152195A (ja) 2000-11-10 2002-05-24 Ntt Docomo Inc 認証サーバ、認証方法及び記録媒体
US6983381B2 (en) 2001-01-17 2006-01-03 Arcot Systems, Inc. Methods for pre-authentication of users using one-time passwords
JP2002259344A (ja) 2001-02-28 2002-09-13 Mitsubishi Electric Corp ワンタイムパスワード認証システム及び携帯電話及びユーザ認証サーバ
JP2002297939A (ja) 2001-03-30 2002-10-11 Casio Electronics Co Ltd 取引認証方法、取引認証システム及び取引認証プログラム
US20030055738A1 (en) * 2001-04-04 2003-03-20 Microcell I5 Inc. Method and system for effecting an electronic transaction
WO2003014867A2 (en) 2001-08-03 2003-02-20 John Allen Ananian Personalized interactive digital catalog profiling
US20040030934A1 (en) 2001-10-19 2004-02-12 Fumio Mizoguchi User selectable authentication interface and universal password oracle
US20040093263A1 (en) * 2002-05-29 2004-05-13 Doraisamy Malchiel A. Automated Interview Method
US20040019564A1 (en) * 2002-07-26 2004-01-29 Scott Goldthwaite System and method for payment transaction authentication
US20040210536A1 (en) 2002-12-18 2004-10-21 Tino Gudelj Cross-domain transactions through simulated pop-ups
US8023958B2 (en) * 2003-03-05 2011-09-20 Qualcomm Incorporated User plane-based location services (LCS) system, method and apparatus
US7421732B2 (en) 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US8213438B2 (en) 2003-12-19 2012-07-03 Iwics Inc. Data transport protocol for a multi-station network
JP2005209083A (ja) 2004-01-26 2005-08-04 Japan Telecom Co Ltd サービスシステム、及びそれを用いた通信システム、通信方法
US20050172229A1 (en) 2004-01-29 2005-08-04 Arcot Systems, Inc. Browser user-interface security application
US20050254653A1 (en) 2004-05-14 2005-11-17 Proxim Corporation Pre-authentication of mobile clients by sharing a master key among secured authenticators
US20060002556A1 (en) 2004-06-30 2006-01-05 Microsoft Corporation Secure certificate enrollment of device over a cellular network
US8296562B2 (en) 2004-07-15 2012-10-23 Anakam, Inc. Out of band system and method for authentication
US20060168259A1 (en) 2005-01-27 2006-07-27 Iknowware, Lp System and method for accessing data via Internet, wireless PDA, smartphone, text to voice and voice to text
JP4667908B2 (ja) 2005-02-28 2011-04-13 三菱電機株式会社 クライアント端末及びシングルサインオンシステム
US20060235795A1 (en) 2005-04-19 2006-10-19 Microsoft Corporation Secure network commercial transactions
US7734912B2 (en) 2005-05-31 2010-06-08 Tricipher, Inc. Secure login using single factor split key asymmetric cryptography and an augmenting factor
GB0519842D0 (en) * 2005-09-29 2005-11-09 Hewlett Packard Development Co Methods and apparatus for managing and using one-time pads
US7743409B2 (en) * 2005-07-08 2010-06-22 Sandisk Corporation Methods used in a mass storage device with automated credentials loading
JP4861417B2 (ja) 2005-08-11 2012-01-25 サンディスク アイエル リミテッド 拡張ワンタイム・パスワード方法および装置
JP2007102778A (ja) 2005-10-04 2007-04-19 Forval Technology Inc ユーザ認証システムおよびその方法
US20070283273A1 (en) 2005-10-24 2007-12-06 Woods Michael E System, Method, and Computer Program Product for Internet Tool
CA2631753A1 (en) 2005-12-01 2007-04-28 Firestar Software, Inc. System and method for exchanging information among exchange applications
CN100545852C (zh) 2005-12-09 2009-09-30 日立软件工程株式会社 认证系统以及认证方法
US20070157304A1 (en) * 2006-01-05 2007-07-05 International Business Machines Corporation Method, apparatus and computer program product for automatic cookie synchronization between distinct web browsers
KR20070077569A (ko) 2006-01-24 2007-07-27 삼성전자주식회사 휴대폰을 이용한 일회용 패스워드 서비스 시스템 및 방법
BRPI0621299A2 (pt) * 2006-02-03 2012-10-09 Mideye Ab sistema e meios de autenticação para autenticação de um usuário final, e, método para autenticar um usuário final remoto de um arranjo de estação de usuário
US9137012B2 (en) 2006-02-03 2015-09-15 Emc Corporation Wireless authentication methods and apparatus
WO2007095265A2 (en) 2006-02-10 2007-08-23 Rsa Security Inc. Method and system for providing a one time password to work in conjunction with a browser
US8434137B2 (en) 2006-03-22 2013-04-30 Gemalto Sa Method of securely logging into remote servers
US7912762B2 (en) * 2006-03-31 2011-03-22 Amazon Technologies, Inc. Customizable sign-on service
US7552467B2 (en) 2006-04-24 2009-06-23 Jeffrey Dean Lindsay Security systems for protecting an asset
US7562813B2 (en) * 2006-05-10 2009-07-21 First Data Corporation System and method for activating telephone-based payment instrument
US20080034216A1 (en) 2006-08-03 2008-02-07 Eric Chun Wah Law Mutual authentication and secure channel establishment between two parties using consecutive one-time passwords
US7818216B2 (en) 2006-08-28 2010-10-19 Seraphim Lawhorn Transaction system with centralized data storage and authentication
KR100786551B1 (ko) 2006-09-15 2007-12-21 이니텍(주) 복수 개의 방식에 의한 일회용 비밀번호의 사용자 등록,인증 방법 및 그러한 방법을 수행하는 프로그램이 기록된컴퓨터 판독 가능 기록 매체
US7979054B2 (en) * 2006-10-19 2011-07-12 Qualcomm Incorporated System and method for authenticating remote server access
US8112817B2 (en) 2006-10-30 2012-02-07 Girish Chiruvolu User-centric authentication system and method
US8060916B2 (en) 2006-11-06 2011-11-15 Symantec Corporation System and method for website authentication using a shared secret
US20080120707A1 (en) 2006-11-22 2008-05-22 Alexander Ramia Systems and methods for authenticating a device by a centralized data server
US8468244B2 (en) 2007-01-05 2013-06-18 Digital Doors, Inc. Digital information infrastructure and method for security designated data and with granular data stores
US8332921B2 (en) 2007-01-12 2012-12-11 Wmware, Inc. Enhanced security for user instructions
IL190839A0 (en) 2007-04-15 2008-12-29 Ari Eliaz Method and system for monetary billing for the use of content services in internet sites, by sending sms messages from cellular phones
US20090031407A1 (en) * 2007-07-24 2009-01-29 Shaobo Kuang Method and system for security check or verification
US20090093300A1 (en) 2007-10-05 2009-04-09 Lutnick Howard W Game of chance processing apparatus
GB0718817D0 (en) 2007-09-26 2007-11-07 British Telecomm Password management
US8032939B2 (en) 2007-11-06 2011-10-04 Airtight Networks, Inc. Method and system for providing wireless vulnerability management for local area computer networks
US20090132813A1 (en) 2007-11-08 2009-05-21 Suridx, Inc. Apparatus and Methods for Providing Scalable, Dynamic, Individualized Credential Services Using Mobile Telephones
US8302167B2 (en) 2008-03-11 2012-10-30 Vasco Data Security, Inc. Strong authentication token generating one-time passwords and signatures upon server credential verification
US8024576B2 (en) 2008-03-31 2011-09-20 International Business Machines Corporation Method and system for authenticating users with a one time password using an image reader
CA2632793A1 (en) 2008-04-01 2009-10-01 Allone Health Group, Inc. Information server and mobile delivery system and method
US8136148B1 (en) 2008-04-09 2012-03-13 Bank Of America Corporation Reusable authentication experience tool
US8272038B2 (en) 2008-05-19 2012-09-18 International Business Machines Corporation Method and apparatus for secure authorization
WO2010011731A2 (en) 2008-07-22 2010-01-28 Next Access Technologies, Llc Methods and systems for secure key entry via communication networks
US20100041391A1 (en) 2008-08-12 2010-02-18 Anthony Wayne Spivey Embedded mobile analytics in a mobile device
US20120005483A1 (en) 2009-04-09 2012-01-05 Hydrabyte, Inc. Method for Image-Based Authentication
US8230231B2 (en) * 2009-04-14 2012-07-24 Microsoft Corporation One time password key ring for mobile computing device
US20100268831A1 (en) * 2009-04-16 2010-10-21 Microsoft Corporation Thin Client Session Management
US8769784B2 (en) 2009-11-02 2014-07-08 Authentify, Inc. Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones
US10049356B2 (en) * 2009-12-18 2018-08-14 First Data Corporation Authentication of card-not-present transactions
US9021507B2 (en) * 2009-12-29 2015-04-28 International Business Machines Corporation Dynamic use of data across multiple programs
US20110208801A1 (en) 2010-02-19 2011-08-25 Nokia Corporation Method and apparatus for suggesting alternate actions to access service content

Also Published As

Publication number Publication date
US20110265149A1 (en) 2011-10-27
JP5595586B2 (ja) 2014-09-24
EP2564308A4 (en) 2017-11-15
EP2564308B1 (en) 2021-01-13
US20140245401A1 (en) 2014-08-28
WO2011136928A1 (en) 2011-11-03
US8719905B2 (en) 2014-05-06
US8893237B2 (en) 2014-11-18
AU2011245653A1 (en) 2012-08-30
EP2564308A1 (en) 2013-03-06
JP2013530440A (ja) 2013-07-25
EP3840290B1 (en) 2023-12-06
CA2794589A1 (en) 2011-11-03
SG184785A1 (en) 2012-11-29
JP2014225880A (ja) 2014-12-04
ES2856195T3 (es) 2021-09-27
CA2794589C (en) 2016-01-26
AU2011245653B2 (en) 2014-04-17
EP3840290A1 (en) 2021-06-23

Similar Documents

Publication Publication Date Title
ES2972816T3 (es) Autenticación de inicio de sesión y de transacciones segura y eficiente utilizando iPhones y otros dispositivos de comunicación móvil inteligentes
ES2553222T3 (es) Seguridad de autentificación 2CHK mejorada con transacciones de consulta
US9832183B2 (en) Key management using quasi out of band authentication architecture
US9444809B2 (en) Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones™
US10897455B2 (en) System and method for identity authentication
US10057763B2 (en) Soft token system
CA2875503C (en) Enterprise triggered 2chk association activation
Van Damme et al. A PKI-based mobile banking demonstrator
Umar An Authentication of Significant security for accessing Password through Network System
HK1175866B (en) Secure and efficient login and transaction authentication using iphones and other smart mobile communication devices