Autenticação forte de cliente e a PSD2: o bom, o ruim e o péssimo

Frederik Mennes, 12 de Setembro de 2019
Strong Customer Authentication under PSD2: the Good, the Bad and the Ugly

Em alguns dias, em 14 de setembro de 2019, os tão esperados requisitos de autenticação de cliente forte (SCA) no PSD2 finalmente entrarão em vigor. Publicado há cerca de 18 meses pela Comissão Europeia nas Normas Técnicas de Regulamentação (RTS) sobre Autenticação Forte do Cliente e Comunicação Comum e Segura, esses requisitos afetarão a maneira como os consumidores na Europa acessam seus aplicativos de Internet banking, pagam por compras de comércio eletrônico e use novos serviços financeiros fornecidos por provedores de terceiros (TPPs) por meio do sistema bancário aberto.

Neste artigo, analisamos o SCA no PSD2 e avaliamos o que correu bem e o que é necessário para uma implantação bem-sucedida do SCA na Europa.

1) O Bom

O PSD2 está aumentando o nível de segurança da autenticação de serviços financeiros em toda a Europa e harmonizando a força dos processos de autenticação de aplicativos financeiros. Por causa do PSD2, as instituições financeiras estão desativando métodos de autenticação fracos. Exemplos são soluções baseadas apenas em combinações de nome de usuário / senha e soluções baseadas em listas impressas de códigos de autenticação, como listas TAN e cartões matriciais. Conforme confirmado pelo parecer da Autoridade Bancária Europeia (EBA) de 21 de junho, essas soluções não atendem aos requisitos da SCA.

O PSD2 garante que conceitos avançados de autenticação, como vinculação dinâmica, ligação de dispositivos para aplicativos móveis, blindagem de aplicativos móveis e análise de risco de transação, se tornem ferramentas de segurança padrão em serviços financeiros. A este respeito, o PSD2 vai muito além do que o da EBA Diretrizes finais sobre a segurança dos pagamentos na Internet , que se tornou aplicável em 1 de agosto de 2015 e será substituído pelo PSD2 em 14 de setembro.

O PSD2 também está acelerando a adoção de métodos de autenticação adaptativos, que ajustam a maneira como o usuário é autenticado ao risco daquilo que ele deseja fazer. Como tal, o PSD2 permite encontrar um equilíbrio específico do usuário entre conveniência e segurança. Essa abordagem foi incluída no RTS graças à abertura da EBA e à estreita colaboração com os participantes do setor durante a elaboração do RTS.

2) O Mau

O PSD2 coloca a responsabilidade de proteger o acesso às contas bancárias com os bancos, também conhecidos como ASPSPs (Account Service Providers Payment Service Providers). Como os bancos possuem as contas bancárias, isso parece fazer sentido à primeira vista.

No entanto, ao examinar mais de perto, fica claro que essa abordagem cria complexidade significativa no contexto do Open Banking, como segue:

  • Primeiro, os usuários dos aplicativos TPP precisarão se autenticar duas vezes: uma vez para acessar o aplicativo TPP e uma segunda vez para usar uma determinada conta bancária por meio do aplicativo TPP.
  • Além disso, o método e o fluxo de autenticação para uma determinada conta bancária dependem do banco. Por exemplo, o banco A pode implementar autenticação usando um leitor de cartão e uma abordagem de "redirecionamento", enquanto o banco B pode usar um aplicativo móvel por meio da abordagem "dissociada". Portanto, a experiência do usuário no aplicativo TPP dependerá do banco. 

Como consequência, a experiência geral de autenticação para o usuário TPP médio promete ser complicada.

No entanto, o próprio PSD2 não é o culpado por isso. A questão é a conseqüência de um problema maior que transcende o PSD2, a saber, a ausência de um sistema de identidade digital pan-europeu construído sobre identidades verificadas e confiáveis. A inspiração para esses sistemas já pode ser encontrada em vários países, como Suécia (ID do banco) e Índia (Aadhaar). O desafio é construir esse sistema a nível europeu. Esse sistema é fundamental para o futuro do Open Banking.  Artigo recente do Citi fornece mais inspiração para isso.

3) O Feio

Os requisitos SCA do PSD2 devem ser à prova de futuro e independentes da tecnologia. Eles fornecem uma margem de manobra aos Provedores de Serviços de Pagamento (PSPs), o que significa que eles podem decidir como atender melhor a um determinado requisito. No entanto, isso pode deixar os PSPs, que precisam atender aos requisitos, no escuro. Alguns exemplos:

  • Uso de SMS para vinculação dinâmica . A EBA esclareceu no seu parecer de 21 de junho que o SMS pode ser considerado um elemento de posse válido. Mais especificamente, o cartão SIM no dispositivo móvel que recebe o SMS é um elemento de posse válido. Isso implica que senhas de uso único (OTPs) entregues via SMS podem ser usadas para construir um forte mecanismo de autenticação quando combinado com um segundo fator (por exemplo, uma senha ou PIN). No entanto, o parecer não esclarece se o SMS pode ser usado para vinculação dinâmica. De fato, o requisito de vinculação dinâmica no artigo 5 do RTS estipula que a confidencialidade e a integridade das informações de pagamento (por exemplo, número da conta bancária, quantia em dinheiro) precisam ser protegidas durante o processo de autenticação. Como o conteúdo de um SMS normalmente não é protegido, parece O SMS não atende aos requisitos de vinculação dinâmica .
  • Criando um ambiente de execução segura para aplicativos móveis . O RTS afirma que os PSPs devem usar ambientes de execução seguros para proteger aplicativos móveis. No entanto, o RTS final não define o que um ambiente de execução seguro é realmente, ou como poderia ser implementado. Dado o estado atual da segurança de aplicativos móveis, a melhor abordagem para atender a esse requisito provavelmente consiste no uso de tecnologia de blindagem de aplicativos , protegendo o aplicativo contra ameaças como sobreposições, injeção de código e registro de chaves.

Finalmente, o cronograma para a aplicação dos requisitos de SCA do PSD2 começou a mudar nos últimos meses. Originalmente, os requisitos de SCA para aplicativos de Internet banking e comércio eletrônico seriam aplicáveis em 14 de setembro de 2019. Na mesma data, o requisito de os bancos fornecerem uma interface de comunicação para o Open Banking entraria em vigor. No entanto, desde que a EBA publicou o seu parecer em 21 de junho, os prazos se tornaram mais fragmentados. No momento da redação, os prazos são os seguintes:

  • Prazo para os bancos implementarem o SCA para Internet banking: 14 de setembro de 2019, exceto no Reino Unido, onde o prazo é agora 14 de março de 2020
  • Prazo para implementar o SCA para pagamentos com cartão para comércio eletrônico: atrasos específicos de cada país são permitidos
  • Prazo para os bancos oferecerem interfaces Open Banking: 14 de setembro de 2019

Como conseqüência, PSPs diferentes podem ter cronogramas diferentes para atender aos requisitos de SCA, e isso pode afetar os pagamentos onde vários PSPs estão envolvidos. Por exemplo, se um pagamento com cartão for realizado entre um emissor do cartão que cumpre a partir de 14 de setembro de 2019 e um adquirente que recebeu uma extensão de, digamos, 6 meses, o adquirente poderá enviar uma solicitação de pagamento sem SCA ao emissor, mas o o emissor recusará o pagamento porque requer SCA. Como conseqüência, os pagamentos podem ser recusados, embora o emissor e o adquirente ajam corretamente. Isso claramente levanta a necessidade de autoridades competentes (CAs) concederem extensões de maneira coordenada. A EBA deve desempenhar o papel de coordenador entre as diferentes CAs aqui.

No épico filme de Sergio Leone de 1966, o Bom leva o ouro, o Bad morre e o Feio é salvo pela misericórdia do Good. Vamos torcer para que o script do filme se aplique também ao PSD2.

PSD2: quais soluções fortes de autenticação e transação cumprem?
WHITE PAPER

PSD2: quais soluções fortes de autenticação e transação cumprem?

Descubra os requisitos mais importantes do RTS final e quais soluções de autenticação têm mais probabilidade de atender aos requisitos.

Baixar Agora

Uma análise mais profunda do PSD2 e seus requisitos de autenticação forte do cliente é disponivel aqui .

Frederik lidera o Security Competence Center da OneSpan, onde é responsável pelos aspectos de segurança dos produtos e infraestrutura da OneSpan. Ele possui um conhecimento profundo de autenticação, gerenciamento de identidades, tecnologias regulatórias e de segurança para aplicativos móveis e em