2. Factor de doble autenticación
Es un mecanismo que permite el acceso a una aplicación o recurso siempre
que el usuario presente 2 o más factores que comprueben su identidad.
Los factores de autenticación de un esquema multifactor pueden incluir:
En nuestro caso utilizaremos la contraseña como algo que “el usuario sabe”,
y una aplicación de autenticación en el dispositivo móvil como algo que “el
usuario tiene”.
A) Algo que el usuario sabe. B) Algo que el usuario
tiene.
C) Algo que el usuario
es.
3. One time password
¿Por qué las TOTPS?
• Solo válidas para un solo inicio de sesión.
• Utilizan hash y el tiempo para derivar un valor sin embargo no son fáciles
de decodificar.
• No son sensibles a los ataques de repetición aun teniendo muestras de
ellas.
• Utilizan una aplicación o token físico sincronizado en el tiempo con el
servidor de autenticación.
En nuestro caso hablaremos del estándar de OTPs sincronizadas con el
tiempo (TOTP RFC 6238).
Un “One Time Password” es una contraseña válida solo para un inicio de
sesión ya sea en una aplicación, dispositivo digital o recurso físico.
Pueden ser basadas en el Tiempo (TOTP), o con base en un hash y en los
valores de OTPs anteriores (HOTP).
4. APEX y los esquemas de autenticación
En APEX utilizamos los esquemas de autenticación para establecer la identidad de
nuestros usuarios y controlar el acceso a las aplicaciones.
Los esquemas de autenticación preconstruidos en APEX son:
1. Oracle APEX Accounts.
2. Database Accounts.
3. HTTP Header Variable.
4. Open Door Credentials.
5. No Authentication (using DAD).
6. LDAP Directory.
7. Oracle Application Server Single Sign-On Server.
8. SAML Sign-In.
9. Social Sign-In.
Si bien es posible crear Custom Authentication Schemes; el resultado es un nuevo
componente que probar, mantener y asegurar, y debe incluye el registro de usuario, la
administración y la encriptación de la contraseña al menos.
5. Requerimientos para la generación
del OTP
APEX
+ Secret
+ Tiempo
Autenticador
+ Secret
+ Tiempo
Registro de primera vez:
otpauth://TYPE/LABEL?PARAME
TERS
Autenticación:
706210
En general para utilizar un cliente de autenticación OTP es necesario:
1. Generar y almacenar la clave secreta del
usuario.
2. Servidor y Cliente con hora sincronizada.
3. Generación de QR con Secret para registro
inicial.
4. Generación de OTP para cada inicio de
sesión.
Opcionalmente podemos utilizar mecanismos directos para enviar OTPs a dispositivos
del usuario como E-Mail, SMS, Telegram o WA con el objetivo de evitar el uso de
autenticadores.
6. Uso de las librerías
Generación de la clave secreta inicial aleatoria.
Generación del URI para registro en el autenticador.
:P2_OTP_URI := oos_util_totp.format_key_uri(
p_label_accountname => 'DFA' || ' - ‘ || lower( :P2_USER_NAME),
p_label_issuer => 'CELERIS',
p_secret => :P2_TFA_CODE
);
Un ejemplo de la cadena devuelta:
otpauth://totp/CELERIS:DFA-demo1?secret=GAZLXNBMOD5WFQYU&issuer=CELERIS
:P2_TFA_CODE := oos_util_totp.generate_secret;
Generación del OTP para verificación al inicio de la sesión:
:P9997_OTP := oos_util_totp.generate_otp(
p_secret => :P9997_TFA_CODE,
p_offset => 180
);
Offset es el tiempo de validez del OTP, en segundos.
PL/ SQL
Librería OOS_UTIL por OraOpenSource, específicamente el paquete
OOS_UTIL_TOTP.
8. JavaScript
Librería JS qrcode-generator por Kazuhiko Arase.
QR para versiones APEX antes de 23.2
Definición de un tag HTML DIV para mostrar el QR.
<div id="dfaQRcode"
style="text-align:center;
border: 1px dashed crimson">
</div>
Ejecución de código para generar la imagen del QR, Acción dinámica
OnLoad.
var qr = qrcode(0, 'M');
qr.addData($v('P2_OTP_URI'));
qr.make();
$('#dfaQRcode').html(qr.createImgTag(4, 16));
https://kazuhikoarase.github.io/qrcode-generator/js/demo/
Carga de qrcode.js en los archivos estáticos de APEX.
Application / Shared Components / Static Application Files
Incluir librería en la pagina donde se mostrará el QR.
#APP_FILES#qrcode.js
Page / JavaScript / File URLs
9. Implementación
Configuración del usuario Preferencia del usuario:
• No usa DFA.
• Recibirá el OTP por Correo.
• Utilizará una aplicación de
autenticación.
Bandera para indicar si el usuario
ya activó el DFA.
Clave secreta generada al
registrar el usuario.
QR Code generado codificando
el URI con la clave secreta, el
nombre del usuario y el “Issuer”.
Demo en APEX
10. Implementación
Modificación al proceso de Login
Inicialmente se obtiene la preferencia
del usuario sobre el uso del DFA.
Con base en ella se identifica si
podemos hacer el login de inmediato o
tendríamos que desviar el flujo al
diálogo de validación del OTP.
Si el usuario utiliza DFA, establecemos
las variables de configuración, el tipo, si
ya está activa o no y el secret que
utilizaremos en un paso posterior para
generar el OTP de verificación.
Finalmente se establece el URL al que
se navegará una vez concluido el
proceso de autenticación normal de
apex.
Usando el paquete APEX_CUSTOM
invocamos el proceso de LOGIN.
Demo en APEX
11. Implementación
Diálogo de activación y verificación del OTP.
En el primer inicio de sesión la aplicación determina que el usuario no ha registrado el QR en su
autenticador y por esta razón lo muestra.
También solicita un OTP inicial que el usuario tendrá disponible después de hacer el registro; al
realizar la verificación del OTP, la bandera de “QR Leido” es actualizada a ‘Si’ en la base de
datos.
12. Implementación
Diálogo de verificación del OTP.
En sesiones posteriores de un usuario
con autenticador configurado el QR ya no
es presentado.
Para el caso de los usuario con OTP por
correo electrónico, la aplicación genera un
OTP desde su primer ingreso y se envía
por medio del correo y se les notifica en
pantalla.
Para estos usuario el código QR nunca es
mostrado ya que no es necesario.
13. Estructura del diálogo.
Durante el proceso de page rendering (1) obtenemos el
email del usuario y generamos un valor para el URI de
registro, o el OTP que mandaremos por correo en caso
necesario.
Tambien existe un proceso condicionado que envia el correo
electrónico con el OTP si así lo indica la configuración.
El cuerpo del diálogo cuenta con varias regiones que están
condicionadas también de acuerdo a la configuración actual
del usuario: tipo de DFA, y esta activo o no, es decir, si el
código QR ya ha sido leído por primera vez o no.
También cuenta con varios ítems ocultos que guardan los
valores temporales de condicionamiento y calculo del URI y
del OTP para correo.
Estos valores se eliminaran posteriormente.
Por ultimo hay un botón que dispara el proceso de
verificación del OTP.
1
14. Estructura del diálogo.
En el page processing (2), verificamos que el OTP ingresado por el usuario corresponda con el
ingresado por el usuario, ya sea que hubiera sido calculado por el autenticador o enviado por email.
En caso necesario se actualiza la bandera de “QR leído”, establece la variable de doble factor a
verdadero y termina limpiando las variables de DFA de la sesión.
2
Demo en APEX
15. Implementación
Proceso de aplicación
Para evitar que un usuario mal
intencionado salte el proceso de
verificación del OTP manipulando de
alguna manera el URL directamente
en el browser, un proceso de
aplicación verificará antes del page
rendering de las paginas si la
validación se ha cumplido.
De otra forma realizara un redirect
inmediato a la pantalla de login.
Tampoco es posible alterar el valor de
la variable APP_TFA_AUTH ya que
esta no puede ser establecida desde
el browser.
Demo en APEX
16. Referencias
Generador de código QR (JavaScript).
https://github.com/kazuhikoarase/qrcode-generator
https://kazuhikoarase.github.io/qrcode-generator/js/demo
Generación de One Time Password (PL/SQL)
https://github.com/OraOpenSource/oos-utils
APIs de APEX (PL/SQL)
https://docs.oracle.com/en/database/oracle/apex/23.1/aeapi/APEX_UTIL.html#GUID-5ECE5C10-
1A88-4D37-8A7D-C51925ADB2B9
https://docs.oracle.com/en/database/oracle/apex/23.1/aeapi/APEX_CUSTOM_AUTH.html#GUID-
44772E73-B910-400C-869C-8CA23D3C88E0
https://docs.oracle.com/en/database/oracle/apex/23.2/htmdb/understanding-
authentication.html#GUID-144A774D-2B05-4BE5-9550-6951EE0B536B
Aplicaciones para autenticación
https://play.google.com/store/apps/details?id=oracle.idm.mobile.authenticator
https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2
https://apps.apple.com/us/app/oracle-mobile-authenticator/id835904829
https://freeotp.github.io/
Conceptos
https://en.wikipedia.org/wiki/Multi-factor_authentication
https://en.wikipedia.org/wiki/One-time_password
https://en.wikipedia.org/wiki/Time-based_one-time_password
Existe otra variante que se llama Hash Chains y cada OTP es creada utilizando la OTP anteriormente usada.
Custom Authentication: Creating a Custom Authentication scheme from scratch to have complete control over your authentication interface.
Oracle APEX Accounts: Oracle APEX Accounts are user accounts that are created within and managed in the APEX user repository. When you use this method, your application is authenticated against these accounts.
Database Accounts: Database Account Credentials authentication utilizes database schema accounts to authenticate users.
HTTP Header Variable: Authenticate users externally by storing the username in a HTTP Header variable set by the web server.
Open Door Credentials: Enable anyone to access your application using a built-in login page that captures a user name.
No Authentication (using DAD): Adopts the current database user. This approach can be used in combination with a mod_plsql Database Access Descriptor (DAD) configuration that uses basic authentication to set the database session user.
LDAP Directory: Authenticate a user and password with an authentication request to a LDAP server. Lightweight directory access protocol (LDAP) is a protocol that makes it possible for applications to query user information rapidly.
Oracle Application Server Single Sign-On Server: Delegates authentication to the Oracle AS Single Sign-On (SSO) Server. To use this authentication scheme, your site must have been registered as a partner application with the SSO server.
SAML Sign-In: Delegates authentication to the Security Assertion Markup Language (SAML) Sign In authentication scheme.
Social Sign-In: Social Sign-In supports authentication with Google, Facebook, and other social networks and enterprise identity providers that support OpenID Connect or OAuth2 standards.