PSD2: Autenticação forte do cliente na UE

Este é o segundo de uma série de três partes de posts detalhando PSD2: Autenticação forte do cliente na UE (SCA).

Na primeira parte desta série de três partes, apresentamos a diretiva da Autoridade Bancária Europeia (ou EBA) da União Europeia chamada PSD2 (abreviação de The Second Payment Services Directive) e descrevemos alguns dos princípios orientadores da autenticação forte do cliente (ou SCA) .

Referindo-se à SCA, a EBA observa: “Graças ao PSD2, os consumidores estarão mais protegidos quando fizerem pagamentos ou transações eletrônicas (como usar seu banco on-line ou comprar on-line). Conforme observado na Parte 1, o Regulatory Technical Standard (RTS) torna a autenticação forte do cliente (SCA) a base para acessar uma conta de pagamento, bem como para fazer pagamentos online.”

Neste post, exploraremos as limitações e os reguladores do SCA que os implementadores devem considerar. Primeiro, vamos ver os códigos de autenticação que são gerados. Lembre-se, isso é essencialmente autenticação de dois fatores ou 2FA.

O RTS descreve as seguintes condições para os códigos de autenticação:

• Nenhuma informação sobre o conhecimento, posse e herança pode ser derivada da divulgação do código de autenticação. Isso significa que, se você conhece o código de autenticação, não há como derivar nenhum outro item de conhecimento (por exemplo, um ID de usuário), o que o usuário possui em sua posse (digamos, um telefone celular - o que significa que você não pode derivar o número do telefone celular) ou herança – aspectos sobre os próprios usuários, como biometria.
• Não é possível gerar um novo código de autenticação com base no conhecimento de qualquer outro código de autenticação gerado anteriormente . Para esta condição, dado qualquer código de autenticação, não há como gerar um novo código de autenticação referenciando um ou vários códigos de autenticação anteriores.
• O código de autenticação não pode ser falsificado . O implementador deve criar códigos de autenticação para que códigos forjados ou falsos não possam ser validados com sucesso.
• Não devem ser feitas mais de 5 tentativas de autenticação com falha dentro do tempo de vida do código. Cada código gerado terá um tempo de expiração ou “tempo de vida”. Esse cronômetro inicia imediatamente após a geração do código e inclui o tempo de entrega. Uma boa regra geral é que o código deve expirar em 15 minutos ou menos. Algumas organizações levam isso para 30 minutos ou 1 hora, mas isso pode ser muito longo. Se o usuário tentar se autenticar com o código e falhar 5 vezes, um novo código deverá ser enviado. Isso evita qualquer tipo de tentativa de força bruta para descobrir o código.
• O tempo máximo sem actividade do ordenante ou utilizador após a autenticação para aceder à sua conta de pagamento online não deve exceder 5 minutos . Este é um temporizador de inatividade padrão e, embora separado do código de autenticação, é um temporizador que inicia quando o usuário é autenticado com êxito e não executa nenhuma atividade.

Todas essas são condições relativamente padrão para a geração/validação do código de autenticação usado em situações de 2FA.

Agora vamos dar uma olhada no requisito RTS chamado Dynamic Linking of the Transactions. As transações eletrônicas remotas (por exemplo, feitas pela Internet, independentemente de o dispositivo ser um desktop ou um dispositivo móvel) devem incluir elementos que “vinculem dinamicamente a transação ao valor específico (do pagamento) e ao beneficiário específico.

Este requisito SCA indica que o valor do pagamento da transação junto com quem o pagamento está sendo feito deve ser devolvido ao usuário no momento da transação 2FA.

Por exemplo, um SMS recebido pelo usuário verificaria o valor da compra e o comerciante, juntamente com o código de segurança (autenticação) e as informações de validade desse código. Uma coisa a notar é que o valor da compra e o comerciante não são criptografados.

Uma alternativa seria incluir um URL junto com o código de segurança na mensagem SMS. A URL deseja as informações de transação vinculadas e criptografadas - acessíveis através de algo que o usuário conhece, bem como o código de segurança (recebido em algo que o usuário possui).

Os códigos de autenticação gerados por aplicativos compatíveis com TOTP de terceiros, como o Google Authenticator e muitos outros, são completamente separados das informações de pagamento/comerciante. A capacidade de vincular dinamicamente esses códigos à transação é um pouco problemática.

Além disso, a maioria desses aplicativos gratuitos pode não conter as medidas apropriadas para oferecer suporte à vinculação dinâmica de dados de transações e para garantir que esses aplicativos contenham contramedidas para interromper a clonagem de aplicativos, bem como jailbreak e detecção de raiz. Dito isso, existem alguns SDKs e APIs especiais que podem fornecer essas contramedidas para aplicativos móveis compatíveis.

Isso significa que um código de autenticação gerado por um aplicativo compatível com TOTP de terceiros, como o Google Authenticator, é gerado separadamente das informações de pagamento/comerciante e, portanto, não pode ser vinculado dinamicamente.

O requisito de Independência de Canal estabelece que “os prestadores de serviços de pagamento devem adotar medidas de segurança, sempre que qualquer um dos elementos de autenticação forte do cliente ou o próprio código de autenticação seja utilizado através de um dispositivo multifuncional, para mitigar o risco que resultaria dessa multi- dispositivo de propósito sendo comprometido.”

O dispositivo multiuso pode ser um dispositivo móvel, tablet ou laptop. Na verdade, provavelmente haverá cenários em que o aplicativo bancário/de pagamento e o aplicativo de autenticação estão no mesmo dispositivo. Em alguns casos, eles podem fazer parte do mesmo aplicativo. Como alternativa, o aplicativo de pagamento pode contar com um canal de autenticação fora de banda (como SMS).

Os canais referem-se aos meios pelos quais interagir com o usuário. O canal de pagamento online do usuário (ou acesso à conta de pagamento) e o canal usado para autenticação não devem ser os mesmos. Em termos das combinações de dispositivos disponíveis no mercado hoje, a independência de canal traz vários problemas. A autenticação fora de banda via SMS é amplamente implantada, fácil de usar e bastante popular entre os consumidores; no entanto, ele tem alguns problemas de segurança percebidos.

Além de soluções fora de banda, como SMS, outra boa solução independente de canal e viável seria usar uma mensagem push por meio de uma solução de autenticação em nuvem separada para um aplicativo de autenticação móvel ou até mesmo o aplicativo bancário/pagamento/comerciante com as informações de pagamento como bem como um código único.

Um aplicativo de autenticação separado que incorpora as contramedidas apropriadas, recebendo informações vinculadas dinamicamente por meio de um canal independente e criptografado, é outro método possível para atender a esses requisitos.

Na parte três desta série de três partes , descreveremos algumas opções de implementação de SCA que devem atender aos requisitos descritos no RTS, bem como alguns locais para encontrar mais informações.

Por favor, considere me seguir no Twitter: @wdudley2009

Saiba quais os efeitos que a atual crise de saúde pode ter na estratégia de negócios, na transformação digital e no futuro do comércio eletrônico AQUI.