OraTOtP ( Oracle Time-based One-time Password )

This post is also available in: English

OraTOtP

OraTOtP ( Oracle Time-based One-time Password ) é uma ferramenta gratuita que adiciona uma camada de segurança extra de Autenticação em 2 Etapas ao conceder as permissões a um usuário de executar qualquer instrução em sua Base de Dados Oracle.

Exemplos de uso do OraTOtP:

  • Adicionar uma camada extra de segurança aos usuário do BD, tornando as senhas por si só menos importantes.
  • Caso alguém descubra a senha se algum usuário da base, ele terá acesso limitado ou nenhum acesso aos objeto do BD.
  • Você precisa estar em compilance com alguma norma de segurança (ex: PCI DSS Requirement 8.3)

Testada em todas as versões de BD Oracle (SE e EE) de 10gR2 até a última 12c.

1. Como funciona

Depois que o usuário se conecta, as suas roles serão desativadas e a única maneira de habilitá-las é digitando o token correto de 6 dígitos que é gerado usando um aplicativo de celular. O DBA pode definir facilmente quais destas roles necessitam da Autenticação em 2 Etapas antes de serem ativadas por alguém.

A ferramenta OraTOtP é muito fácil de configurar e utilizar, não exigindo grandes habilidades para que qualquer um possa habilitá-lo.

Você não deve habilitar a Autenticação em 2 Etapas para roles usadas por usuários com acesso autônomo (programas, tarefas em lote, etc) a menos que haja alguma interface de aplicativo para digitar o token. Também não é recomendado habilitá-lo para roles default (DBA, RESOURCE, etc) pois pode impactar processos internos do próprio Oracle, o mais indicado é que se clone estas roles com outro nome para ativar a proteção.

2. Recursos

  • Se você sempre se conectar a partir da mesma aplicação e máquina, você pode solicitar a ferramenta que "confie" na sua origem por 7 dias. Desta forma, não será necessário digitar o token novamente caso se conecte no banco de dados a partir do mesmo local.
  • O usuário pode reconfigurar o 2-Factor se trocar de telefone ou aplicativo.
  • Proteção contra ataques de força bruta de tokens.
  • A chave geradora do token é armazenada criptografada dentro da base de dados. O usuário pode fornecer opcionalmente uma senha de criptografia para torná-la irreversível por qualquer pessoa (nem mesmo eu).

3. Instruções

1- Baixe um aplicativo de Authenticator para o seu celular. Eu recomendo o "Google Authenticator", por ser de graça, simples e estável:

  • Android: https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2
  • iOS: https://itunes.apple.com/br/app/google-authenticator/id388497605
  • Windows Phone: https://www.microsoft.com/en-us/store/p/authenticator/9wzdncrfj3rj

Existem dezenas de outros aplicativos baseados no algoritmo TOTP. Sinta-se à vontade para escolher o de sua preferência.

2- Instale a ferramenta OraTOtP em seu BD (verifique a seção "Instalação" para mais detalhes).

3- CRIE ou ALTERE qualquer ROLE para poder ser ativada apenas após a autenticação em 2 Etapas ter sido concluída (verifique a seção "Exemplos de Uso" para alguns casos).

OBS: Certifique-se que a hora do seu servidor está sincronizada com o UTC e na timezone correta.

4. Objetos Criados

O OraTOtP irá criar 1 novo schema (cujo nome é definido durante a instalação) para manter as packages e tabelas que possuirão as configurações do Time-based One-time Password. Esse usuário será lockado e com senha expirada e não é para ser utilizado por qualquer um.

A ferramenta consiste em:

  • 1 Novo Schema com:
    • 3 Packages e seus Bodys
    • 1 Procedure
    • 1 Trigger
    • 3 Tabelas e suas Constraints e Índices
  • 2 Sinônimos Públicos (para evitar a necessidade de digitar o nome do schema)
  • 1 Context (para controlar Autenticação em 2 Etapas)

Caso o seu Banco de Dados seja Enterprise Edition, o script também criará 1 função e 4 Policies de VPD para proteger as tabelas do schema.

Caso possua o Database Vault Option, o script também irá criar um realm para proteger todos os objetos do schema.

Existem apenas 3 objetos que precisam ser conhecidos:

 

  1. Package TWOFACTOR (utilizado para efetuar todas as tarefas relacionadas ao 2-Factor. Privilégios de execução concedidos ao PUBLIC).
  2. Package TWOFACTOR_ADMIN (utilizado para efetuar todas as tarefas de administração relacionadas ao 2-Factor. Privilégios de execução devem ser concedidos apenas aos DBAs).
  3. Procedure ENABLE_ROLE (utilizada para ativar qualquer role protegida pelo 2-Factor. Privilégios de execução concedidos ao PUBLIC).

Esses 3 objetos acima estão mais detalhados na seção "Documentação".

5. Instalação

Faça o download do arquivo ZIPADO (verifique a seção "Download" para maiores informações) e extraia todos os arquivos.

Abra SQL*Plus e execute o INSTALL.sql.

Exemplo 1:

  • Instalar para um BD local.
[oracle@mydbserver ~]$ sqlplus /nolog

SQL*Plus: Release 12.1.0.2.0 Production on Tue Oct 18 13:54:08 2016

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

SQL> @INSTALL
Schema Name for 2-Factor [TOTP]: TOTP
String to connect as SYS [/ as sysdba]: / as sysdba
Connected.
DB Vault Users script skipped - Database Vault not enabled.
Connected.
User created.
Connected.
User privs granted.
Connected.
Objects created.
Policies created.
Connected.
DB Vault Realms script skipped - Database Vault not enabled.
=> SCRIPT EXECUTED SUCCESSFULLY! <=

Exemplo 2:

  • Instalar para um BD remoto usando TNS Names.
  • Note que neste caso o DB Vault está ativo. Neste caso, o script solicita algumas informações extras.
[oracle@mydbserver ~]$ sqlplus /nolog

SQL*Plus: Release 12.1.0.2.0 Production on Tue Oct 18 11:20:13 2016

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

SQL> @INSTALL
Schema Name for 2-Factor [TOTP]:
String to connect as SYS [/ as sysdba]: sys/Oracle.123@orcl as sysdba
Connected.
Oracle Database Vault Detected.
String to connect as DV Acct Mgr [/ as sysdba]: dvacctmgr/Oracle.123@orcl
String to connect as DV Owner [/ as sysdba]: dvowner/Oracle.123@orcl
String to connect as DBA [/ as sysdba]: system/Oracle.123@orcl
Connected.
User created.
Connected.
User privs granted.
Connected.
Objects created.
Policies created.
Connected.
Realm created.
=> SCRIPT EXECUTED SUCCESSFULLY! <=

Exemplo 3:

  • Instalar para um BD remoto usando EZ Connect.
  • Note que aqui o nome do Schema é definido como GAUTH em vez de TOTP.
[oracle@mydbserver ~]$ sqlplus /nolog

SQL*Plus: Release 12.1.0.2.0 Production on Tue Oct 18 11:20:13 2016

Copyright (c) 1982, 2014, Oracle.  All rights reserved.

SQL> @INSTALL
Schema Name for 2-Factor [TOTP]: GAUTH
String to connect as SYS [/ as sysdba]: sys/Oracle.123@10.1.1.5/orcl as sysdba
Connected.
DB Vault Users script skipped - Database Vault not enabled.
Connected.
User created.
Connected.
User privs granted.
Connected.
Objects created.
Policies created.
Connected.
DB Vault Realms script skipped - Database Vault not enabled.
=> SCRIPT EXECUTED SUCCESSFULLY! <=

6.Documentação

TWOFACTOR:

Este pacote deve ser concedido a cada usuário do BD e é responsável por permitir ao usuário configurar e autenticar no 2-Fator. Só depois disso ele será capaz de HABILITAR qualquer role protegida com 2-Factor.

SETUP;
Configurará o usuário conectado e gerará uma URL com um QR Code. Este é o primeiro passo que deve ser feito por qualquer pessoa. Scaneie o código gerado com o seu aplicativo para celular. Antes de executar esta procedure, não se esqueça de ativar SERVEROUTPUT.

VALIDATE (PCODE IN VARCHAR2);
Depois que o usuário estiver configurado, você deve validá-lo fornecendo um código que é gerado pelo seu aplicativo. A validação prova que você configurou o aplicativo para celular corretamente e o código que está sendo gerado é válido. Somente depois que o usuário é validado que ele será capaz de autenticar e habilitar roles que são protegidos pela Autenticação em 2 Etapas.

Parâmetro:

PCODE - Forneça o código gerado pelo aplicativo para celular.

AUTHENTICATE (PCODE IN VARCHAR2);
Agora que o usuário está configurado e o gerador de código validado, após cada novo login você precisará autenticá-lo para ser capaz de ativar as roles e seus privilégios.

Parâmetro:

PCODE - Forneça o código gerado pelo aplicativo para celular.

DECONFIG (PCODE IN VARCHAR2 DEFAULT NULL);
Desfaz e limpa qualquer configuração do usuário. Útil se você alterar de aplicativo ou de telefone ou quiser reconfigurar seu gerador de códigos. É necessário fornecer um código válido caso o usuário já tiver sido validado. Se você perdeu seu aplicativo de geração de código e não consegue executar a DECONFIG, solicite suporte ao administrador da ferramenta.

Parâmetro:

PCODE - Forneça o código gerado pelo aplicativo para celular caso o usuário já tenha sido validado.

REMEMBER (PCODE IN VARCHAR2);
Essa procedure lembrará as informações da máquina, aplicativo e usuários de origem da sua conexão por 7 dias. Desta forma, esse local será definido como "confiável". Durante esse período, quando você estabelecer uma nova conexão desta localidade você já será automaticamente autenticado. Precisará apenas ativar a role.

Parâmetro:

PCODE - Forneça o código gerado pelo aplicativo para celular.

FORGET;
Removerá todas as conexões de origem marcadas como confiáveis e associadas ao seu usuário.

SETSECRETPASS (PPASS IN VARCHAR2);
Opcionalmente, você pode adicionar uma senha para tornar a "shared secret" da geração de código irreversível por qualquer pessoa.

Parâmetro:

PPASS - Você pode definir qualquer senha com até 30 caracteres. Atenção, isso não tem nada a ver com a senha de sua conta de usuário, esta aqui é usada para proteger e criptografar sua geração de código. Caso definido antes do SETUP inicial, sera necessário executar esta procedure sempre antes de passar o PCODE como parâmetro de qualquer outra procedure.

TWOFACTOR_ADMIN:

Essa package é muito semelhante à TWOFACTOR, exceto que também é possível gerenciar outros usuários com esta. Desta forma, ela deve ser concedida apenas para administradores do 2-Factor (ou DBA's). Basicamente, todas as subprocedures são as mesmos adicionando os parâmetros "PUSER" e "PPASS".

SETUP (PUSER IN VARCHAR2, PPASS IN VARCHAR2 DEFAULT NULL, PGAP IN NUMBER DEFAULT NULL);
Semelhante à TWOFACTOR.SETUP, exceto que ele irá configurar o usuário especificado pelo parâmetro PUSER (não o usuário da sessão).

Parâmetro:

PUSER - Nome do usuário afetado pela procedure.

PPASS - Opcionalmente, você pode adicionar uma senha para tornar a geração de código irreversível por qualquer pessoa.

PGAP - Intervalo de tempo em segundos para também aceitar códigos com base em erros de relógio. Um novo código é gerado a cada 30 segundos, no entanto, para evitar problemas, por padrão (se a entrada for nula), adicionamos um intervalo de 480 segundos (8 minutos) = 4 minutos para cima e para baixo. Isso significa que se o relógio do seu aplicativo marcar 12h00 e o relógio do servidor for 12h04, o código gerado ainda estará válido. O limite aceito é de 1200 segundos (20 minutos) = 10 minutos para cima e para baixo.

VALIDATE (PUSER IN VARCHAR2, PCODE IN VARCHAR2, PPASS IN VARCHAR2 DEFAULT NULL);
Semelhante à TWOFACTOR.VALIDATE, exceto que ele irá validar o usuário especificado pelo parâmetro PUSER (não o usuário da sessão).

Parâmetro:

PUSER - Nome do usuário afetado pela procedure.

PCODE - Forneça o código gerado pelo aplicativo para celular.

PPASS - Se o usuário tiver feito a configuração inicial com uma senha, digite-a aqui para decodificar os códigos.

AUTHENTICATE (PCODE IN VARCHAR2, PPASS IN VARCHAR2 DEFAULT NULL);
Semelhante à TWOFACTOR.AUTHENTICATE. Não é possível autenticar para outro usuário.

Parâmetro:

PCODE - Forneça o código gerado pelo aplicativo para celular.

PPASS - Se você tiver feito a configuração inicial com uma senha, digite-a aqui para decodificar os códigos.

DECONFIG (PUSER IN VARCHAR2, PCODE IN VARCHAR2 DEFAULT NULL, PPASS IN VARCHAR2 DEFAULT NULL, PISADMIN IN BOOLEAN DEFAULT TRUE);
Semelhante à TWOFACTOR.DECONFIG, exceto que ele irá desconfigurar o usuário especificado pelo parâmetro PUSER (não o usuário da sessão).

Parâmetro:

PUSER - Nome do usuário afetado pela procedure.

PCODE - Forneça o código gerado pelo aplicativo para celular. Ignorado caso o PISADMIN for true (comportamento padrão).

PPASS - Se o usuário tiver feito a configuração inicial com uma senha, digite-a aqui para decodificar os códigos.

PISADMIN - Quando este parâmetro é true (comportamento padrão), você não precisa fornecer um código para desconfigurar usuários já validados.

REMEMBER (PCODE IN VARCHAR2, PPASS IN VARCHAR2 DEFAULT NULL, PINT IN INTERVAL DAY TO SECOND DEFAULT NULL);
Semelhante à TWOFACTOR.REMEMBER. Não é possível lembrar as informaçoes de logins para outro usuário.

Parâmetro:

PCODE - Forneça o código gerado pelo aplicativo para celular.

PPASS - Se o usuário tiver feito a configuração inicial com uma senha, digite-a aqui para decodificar os códigos.

PINT - Intervalo de dias para lembrar as credenciais. Se não for especificado, o padrão é 7 dias.

FORGET (PUSER IN VARCHAR2);
Semelhante à TWOFACTOR.FORGET, exceto que ele irá remover as conexões confiáveis do usuário especificado pelo parâmetro PUSER (não do usuário da sessão).

Parâmetro:

PUSER - Nome do usuário afetado pela procedure.

ENABLE_ROLE:

Essa procedure é usada para ativar uma role protegida.

ENABLE_ROLE (ROLE_NAME IN VARCHAR2);
Adicionará a role protegida passada como parâmetro à sua lista de roles ativadas, executando "SET ROLE". Você deve estar autenticado no 2-Factor para poder executar esta procedure.

Parâmetro:

ROLE_NAME - Nome da role protegida que você deseja ativar em sua sessão.

TABELAS e COLUNAS:
Verifique os comentários nas próprias tabelas e colunas.

7. Exemplos de Uso

O primeiro passo é criar uma ROLE que você quer que seja protegida pela autenticação em 2 etapas:

SQL> CREATE ROLE APPOBJACCESS IDENTIFIED USING TOTP.ENABLE_ROLE;

Role created.

SQL>

OBS: Você pode opcionalmente alterar as roles existentes a serem habilitadas somente depois que o usuário estiver autenticado pelo 2-Factor.

Agora, vamos criar um novo usuário para demonstrar como o sistema funciona:

SQL> CREATE USER USER1 IDENTIFIED BY "User1";

User created.

SQL> GRANT CREATE SESSION TO USER1;

Grant succeeded.

SQL> GRANT APPOBJACCESS TO USER1;

Grant succeeded.

SQL>

A role foi criada e concedida ao USER1, vamos tentar conectar e ativar a função:

SQL> conn User1/User1
Connected.
SQL> select * from session_roles;

no rows selected

SQL> set role APPOBJACCESS;
set role APPOBJACCESS
*
ERROR at line 1:
ORA-01924: role 'APPOBJACCESS' not granted or does not exist

SQL> exec enable_role('APPOBJACCESS');
BEGIN enable_role('APPOBJACCESS'); END;
*
ERROR at line 1:
ORA-20000: User not authenticated in 2Factor.
ORA-06512: at "TOTP.ENABLE_ROLE", line 14
ORA-06512: at line 1

SQL>

Como você pode ver, a função não pode ser ativada através do comando set. O caminho certo é usar a procedure enable_role, no entanto, o usuário deve autenticar primeiro. Como este usuário ainda não está configurado, vamos configurá-lo:

SQL> set serveroutput on
SQL> set lines 1000
SQL> exec twofactor.setup;
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=%6F%74%70%61%75%74%68%3A%2F%2F%74%6F%74%70%2F%55%53%45%52%31%40%4F%52%43%4C%3F%73%65%63%72%65%74%3D%56%53%4D%34%50%52%35%41%4B%56%44%52%47%59%55%35%26%69%73%73%75%65%72%3D%44%42%20%53%65%72%76%65%72%20%2D%20%6F%72%63%6C%2E%75%73%2E%6F%72%61%63%6C%65%2E%63%6F%6D

PL/SQL procedure successfully completed.

SQL>

OBS: Se você esquecer de habilitar o serveroutput antes de executar o procedimento SETUP, basta executar o DECONFIG, habilitá-lo e, em seguida, executar a configuração novamente.

Abra o endereço do link retornado em um navegador e scaneie o QR Code usando o "Google Authenticator" (ou qualquer outro aplicativo do TOTP que você preferir):

Depois que seu aplicativo estiver configurado, ele começará a gerar os códigos conforme abaixo:

Agora é possível validar:

SQL> exec twofactor.validate(682286);

PL/SQL procedure successfully completed.

SQL>

Com o 2-Factor validado, de agora em diante tudo que é preciso após estabelecer novas conexões é autenticar e ativar a role:

SQL> select * from session_roles;

no rows selected

SQL> exec twofactor.authenticate(390564);

PL/SQL procedure successfully completed.

SQL> exec enable_role('APPOBJACCESS');

PL/SQL procedure successfully completed.

SQL> select * from session_roles;

ROLE
------------------------------
APPOBJACCESS

SQL>

Opcionalmente, você pode solicitar ao sistema de Autenticação em 2 Etapas para confiar na sua localidade pelos próximos 7 dias, desta forma não será necessário reautenticar após cada novo login vindo desta vindo da mesma máquina, terminal, IP, programa e usuário de SO:

SQL> conn User1/User1
Connected.
SQL> exec enable_role('APPOBJACCESS');
BEGIN enable_role('APPOBJACCESS'); END;
*
ERROR at line 1:
ORA-20000: User not authenticated in 2Factor.
ORA-06512: at "TOTP.ENABLE_ROLE", line 14
ORA-06512: at line 1

SQL> exec twofactor.authenticate(388648);

PL/SQL procedure successfully completed.

SQL> exec enable_role('APPOBJACCESS');

PL/SQL procedure successfully completed.

SQL> exec twofactor.remember(471508);

PL/SQL procedure successfully completed.

SQL> conn User1/User1
Connected.
SQL> exec enable_role('APPOBJACCESS');

PL/SQL procedure successfully completed.

SQL>

8. Download

https://github.com/dbarj/OraTOtP/archive/master.zip

---------------------------
Checksum information
---------------------------
Name: OraTOtP-1.00.zip
Size: 30248 bytes (0 MB)
CRC32: 9532060D
CRC64: F95F37109D5196B1
SHA256: 2339020753EE758969E2E500D5A4A29DD3D1FDFD9B14844EFD272567D4F54A4F
SHA1: C458801D32AC2B192ABD7AF2FC74099B08E5C269
BLAKE2sp: DF7E1399F2912244A02DEC6EFECEC617277321E0FD35AAB66AD7625F8DB3EA7F

Gostou? Não deixe de comentar ou deixar um 👍!

1 comentário

  1. Tudo bem? Primeiramente gostaria de parabenizar pelo post.

    Gostaria de saber se é possível utilizar o oratotp no APEX da Oracle. Digo pois o APEX é baseado em Banco e as aplicações desenvolvidas também.. Você acha que ele poderia ser utilizado? Obrigado

Deixe um comentário

Seu e-mail não será publicado.