Capítulo final: Autenticação forte do cliente (SCA) para PSD2
Publicados: 2018-09-05Este é o terceiro de uma série de três partes de posts que detalham o PSD2 Strong Customer Authentication (SCA) da UE
Chegamos ao terceiro e último capítulo desta série. Na primeira parte, introduzimos a diretiva da Autoridade Bancária Europeia (ou EBA) da União Européia chamada PSD2 (abreviação de A Segunda Diretiva de Serviços de Pagamento) e descrevemos alguns dos princípios orientadores da Autenticação Forte do Cliente (ou SCA). A segunda parte explorou as limitações e regulamentações do SCA que os implementadores devem considerar, incluindo os códigos de autenticação, vinculação dinâmica das transações e independência do canal.
Para este post, descreveremos as opções de implementação de SCA que devem atender aos requisitos descritos no PSD2 RTS (Regulatory Technical Standard), bem como alguns bons lugares para procurar mais informações.
Antes de examinarmos algumas opções de implementação para SCA, também devemos salientar que existem algumas exceções de autenticação forte e vinculação dinâmica .
No PSD2 Press Release FAQ, eles observam: “[as isenções são] para evitar perturbar as formas como os consumidores, comerciantes e provedores de serviços de pagamento operam hoje. É também porque pode haver mecanismos de autenticação alternativos que são igualmente seguros e protegidos. No entanto, “prestadores de serviços de pagamento que desejam ser isentos de SCA devem primeiro aplicar mecanismos de monitoramento de transações para avaliar se o risco de fraude é baixo”. As isenções específicas estão descritas no Capítulo III do PSD2 RTS.
Duas áreas onde a autenticação forte do cliente é exigida no PSD2
- Acesso à conta – é o acesso a contas de pagamento por meio de qualquer dispositivo: desktop, laptop, tablet ou celular.
- Pagamentos – esta é a autenticação real de um pagamento, incluindo a vinculação dinâmica das informações de pagamento com o método de autenticação.
No mundo multi-dispositivo e multicanal de hoje, há uma variedade de métodos de aplicativos bancários / de pagamento para realizar a autenticação, desde simples 2FA baseado em SMS até o mais sofisticado (e seguro) Universal 2 nd Factor (U2F) do Fido Aliança junto com tudo no meio.
Normalmente, temos quatro configurações principais hoje:
- Dois dispositivos – um executando o aplicativo bancário/comerciante; outro fornecendo a autenticação. Isso inclui tokens de hardware e dispositivos U2F como dispositivos de autenticação, mas também inclui um dispositivo móvel e um laptop com o laptop executando o aplicativo bancário/comerciante e o dispositivo móvel fornecendo autenticação (mesmo autenticação fora de banda)
- Dois aplicativos, um dispositivo – em um único dispositivo, normalmente um telefone celular, teríamos o aplicativo bancário/comerciante e um aplicativo de autenticação. O aplicativo de autenticação pode incluir uma solução de soft-token, como o Google Authenticator ou um aplicativo de autenticação desenvolvido especialmente para se integrar ao banco/comerciante para transferir, por exemplo, informações de compra vinculadas dinamicamente ao aplicativo autenticador.
- Um aplicativo, um dispositivo – um exemplo seria um aplicativo de banco móvel que também fornecesse o recurso de autenticação nesse aplicativo.
- Out-of-Band – ou Autenticação OOB – isso inclui SMS enviado para o número do celular, protegido por um cartão SIM. Neste caso, o dispositivo móvel, alcançado através de um canal fora de banda como SMS (ou mesmo RCS, quando suportado) será o 2º fator (posse).
Dadas todas essas opções, quais seriam as melhores opções e métodos para suportar PSD2 SCA e estar em conformidade?
A opção Out-of-Band (OOB) é o método mais fácil e conhecido pelos consumidores. É totalmente compatível com as regras de Acesso à Conta e deve ser uma opção para Pagamentos desde que as informações de pagamento estejam incluídas no SMS. Também atende ao requisito de independência de canal.
Claro, hoje em dia, existem alguns problemas de segurança com o SMS; no entanto, muitos deles são um pouco exagerados na imprensa (por exemplo, troca de SIM, interceptações de SMS). Dito isto, existem métodos melhores e mais seguros. Se estiver usando o SMS como um canal OOB para 2FA, considere adicionar um fator de conhecimento adicional para proteger ainda mais a conta ou o pagamento. Isso fornecerá segurança adicional contra determinados cenários de troca de SIM ou interceptação de SMS, caso ocorram.
Um dos problemas com a opção de autenticação de vários dispositivos (2 dispositivos) usando vários dispositivos de hardware para autenticação de pagamentos é que é difícil incorporar a vinculação dinâmica de informações de pagamento/comerciante a esse dispositivo de autenticação. Embora muitos deles sejam bastante seguros, como dispositivos U2F, é difícil incorporar a vinculação dinâmica das informações de compra/pagamento.
Um método que seria útil seria usar uma solução de autenticação que ainda cria um código PIN padronizado na nuvem, mas usa informações criptografadas enviadas para um aplicativo de autenticação especializado. O aplicativo bancário/comerciante também pode incluir as informações de pagamento junto com o código que seria enviado ao aplicativo de autenticação.
O aplicativo de autenticação apresentaria as informações ao usuário e, em seguida, responderia com um “Aceitar” ou “Negar”. O aplicativo de autenticação pode fazer parte de uma estratégia de dois dispositivos, bem como de uma estratégia de dois aplicativos (um dispositivo). O aplicativo não dependeria de números de telefone (por exemplo, OOB) e, portanto, seria resistente a troca de SIM ou seqüestro de dispositivo. Além disso, o dispositivo teria que estar em posse física do titular da conta, juntamente com informações baseadas em conhecimento do titular da conta.
Felizmente, existem muitas opções disponíveis para os provedores de pagamento da UE, que precisarão implementar o PSD2 SCA nos próximos meses. Cada um terá casos de uso específicos que devem ser examinados de perto para determinar se os recursos SCA devem ser aplicados. Aqui estão algumas dicas:
- Examine cada caso de uso
- Entenda se as isenções de SCA podem ser aplicadas
- Determinar é o caso de uso relacionado ao acesso à conta ou pagamentos
- Para pagamentos, determine como você apresentará as informações de pagamento e o comerciante ao usuário (vinculação dinâmica)
- Para acesso à conta, sugerimos sempre aplicar autenticação de dois fatores aos logins – é apenas mais seguro
Para a maioria dos mercados da UE, esperamos que o método mais comum para compras e pagamentos online seja por meio de um dispositivo móvel. Portanto, isso implica que o dispositivo será usado tanto como dispositivo principal para compras/pagamentos quanto para autenticação. Nem sempre espere que os usuários usem desktops ou laptops. O uso de dispositivos móveis (incluindo tablets) aumentará apenas como dispositivos principais.
O PSD2 SCA é um conjunto complexo de regulamentos, mas com algum bom senso e compreensão sobre os desafios e opções de autenticação atuais, ele pode ser implementado para atender a esses regulamentos e proteger todas as partes envolvidas. Nos últimos meses, surgiram algumas críticas a alguns dos requisitos do SCA e algumas das limitações que eles impõem. De fato, pode haver regulamentações de acompanhamento (PSD3?) nos próximos meses e anos.
Não tenha medo de implementar o SCA se estiver envolvido em pagamentos online. Não espere até o último minuto. Aproveite o tempo para ler os requisitos, estudá-los e depois tomar decisões. Existem muitas opções disponíveis e esperamos que esta série de 3 partes tenha sido útil para guiá-lo através das várias opções e elementos do PSD2 SCA.