PSD2: parecer da EBA permite mais tempo para implementação da autenticação forte de cliente

Em 21 de junho de 2019, a Autoridade Bancária Europeia ( EBA ) publicou um Opinião sobre autenticação forte do cliente (SCA) sob a Diretiva de serviços de pagamento revisada ( PSD2 ) O parecer da EBA permite que as autoridades competentes (CAs) concedam excepcionalmente tempo adicional além de 14 de setembro de 2019 a prestadores de serviços de pagamento específicos (PSPs) para cumprir os requisitos da SCA. Também fornece esclarecimentos sobre a conformidade de métodos de autenticação comuns com os requisitos de SCA do PSD2.

Neste artigo, discuto os esclarecimentos do parecer da EBA e também levanto algumas áreas em que são necessários esclarecimentos adicionais.

Âmbito de extensão

O parecer permite que as autoridades competentes (CAs) concedam excepcionalmente tempo adicional além de 14 de setembro de 2019 a prestadores de serviços de pagamento (PSPs) específicos para cumprir os requisitos da SCA. Mais especificamente, o parecer afirma que " As CAs podem decidir trabalhar com os PSPs e as partes interessadas relevantes, incluindo consumidores e comerciantes, para fornecer tempo adicional limitado para permitir que os emissores migrem para abordagens de autenticação compatíveis com a SCA, como as descritas nesta Opinião, e que os adquirentes migrem seus comerciantes para soluções que suportam SCA. "

Como tal, a Opinião se refere fortemente a emissores, adquirentes e comerciantes ao discutir a possibilidade de obter mais tempo para cumprir. Essa terminologia é normalmente usada no contexto de pagamento com cartão para comércio eletrônico. Provavelmente, esse é o caso, porque a maioria dos pedidos para adiar o prazo de setembro veio de empresas de comércio eletrônico.

Isso levanta a questão de saber se as autoridades competentes concederão apenas tempo adicional no contexto de pagamentos com cartão para comércio eletrônico, e talvez não no contexto de outros aplicativos que exijam autenticação forte, como banco on-line e banco móvel. Solicitamos que a EBA esclareça isso.

RELATÓRIO BRANCO

Habilitando o monitoramento de fraudes em conformidade à PSD2 com Análise de Risco OneSpan

Os novos requisitos do PSD2 exigem que as organizações de serviços financeiros realizem o monitoramento de transações. Aprenda os requisitos específicos e como o OneSpan Risk Analytics pode mantê-lo em conformidade neste white paper.

Baixar Agora

Momento da extensão

Como mencionado acima, o parecer permite que as autoridades de certificação forneçam “ tempo adicional limitado ”Aos PSPs para atender aos requisitos de SCA. No entanto, o parecer não impõe um prazo. 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, seis meses, então o adquirente poderá enviar uma solicitação de pagamento sem SCA ao emissor. Mas, o emissor recusará o pagamento, porque exige SCA. Como conseqüência, os pagamentos podem ser recusados, embora o emissor e o adquirente ajam corretamente. Isso claramente levanta a necessidade de as CAs concederem extensões de maneira coordenada.

Alinhamento de SCA e cronogramas de operações bancárias abertas

Até agora, a introdução das APIs do Open Banking e do SCA andava de mãos dadas e seguia o mesmo cronograma, com o prazo sendo 14 de setembro de 2019 para ambos. O parecer da EBA permite tempo adicional para implementar os requisitos de SCA, mas não permite tempo adicional para implementar APIs do Open Banking, o outro pilar do PSD2. Como conseqüência, os bancos poderiam oferecer APIs do Open Banking para fornecedores de terceiros (SCP) sem SCA.

Isso tem várias consequências:

• Impacto na segurança: Se um banco não proteger contas bancárias com o SCA e se oferecer suporte à autenticação por meio do modelo incorporado, os TPPs obterão credenciais fracas usadas para proteger as contas bancárias. Por exemplo, se uma conta bancária estiver protegida com um nome de usuário e uma senha estática, o TPP poderá obter essas credenciais. Como conseqüência, o TPP pode acessar essas contas bancárias e talvez efetuar pagamentos sem que os titulares da conta estejam cientes.

• Impacto na experiência do usuário: Os usuários que acessam suas contas bancárias por meio de um TPP (ou mais especificamente de um provedor de serviços de informações da conta ou AISP) podem ser solicitados a executar o SCA para o Banco A, mas não para o Banco B. Como conseqüência, a experiência do usuário no aplicativo do AISP será diferente para bancos diferentes, o que pode ser confuso. Isso também se aplica a TPPs que atuam como PISP (Payment Initiation Service Provider).

WEBCAST

Webinar: Extensão do prazo de autenticação forte do cliente PSD2 - esclarecimentos sobre a opinião da EBA

Aprenda com o especialista em PSD2 SCA Frederik Mennes sobre o escopo e os prazos da extensão SCA e quais soluções de autenticação estão em conformidade.

Assista agora

 Conformidade dos elementos de autenticação

As Normas Técnicas de Regulamentação (RTS) sobre Autenticação Forte do Cliente e Comunicação Comum e Segura do PSD2 definem SCA como um " autenticação baseada no uso de dois ou mais elementos categorizados como conhecimento (algo que apenas o usuário conhece), posse (algo que apenas o usuário possui) e herança (algo que o usuário é) que são independentes […] ”. O parecer contém esclarecimentos sobre quais elementos de autenticação podem ser considerados fortes e em que categoria se enquadram (isto é, conhecimento, posse ou herança).

Abaixo estão alguns esclarecimentos dignos de nota do Parecer:

• SMS como elemento de posse: O parecer esclarece 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 ou 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 . A EBA deve fornecer esclarecimentos adicionais sobre isso.

• Aplicativos móveis como elemento de posse: O parecer reforça o artigo 7 do RTS, que implica que os aplicativos móveis são elementos de posse válidos, se estiverem protegidos por um mecanismo de ligação de dispositivo que vincula o aplicativo móvel ao dispositivo em que é executado. Um aplicativo móvel que não está protegido com um mecanismo de ligação de dispositivo não pode ser considerado um elemento de posse válido.

• Listas OTP como elemento de posse: As instituições financeiras às vezes usam cartões matriciais impressos ou listas OTP impressas (às vezes chamadas de "listas TAN") para autenticar o usuário final de um aplicativo bancário on-line. O parecer esclarece que esses cartões ou listas impressos não constituem um elemento de posse válido, porque podem ser facilmente copiados (por exemplo, tirando uma foto do cartão usando um dispositivo móvel).

Existem vários tópicos não abordados no parecer que se beneficiariam de esclarecimentos adicionais. Enviei perguntas sobre esses tópicos por meio do Ferramenta de perguntas e respostas da EBA :

• Uso de IBANs parciais ou completos na vinculação dinâmica: O requisito de vinculação dinâmica afirma que o código de autenticação deve ser calculado sobre um identificador do beneficiário. Suponha que um IBAN seja usado para identificar um beneficiário. É então necessário calcular o código de autenticação em todo o IBAN ou é suficiente usar uma parte dele? Da mesma forma, é suficiente mostrar apenas uma parte do IBAN para o pagador? Na prática, os bancos costumam usar apenas uma parte do IBAN por várias razões, porque é inconveniente digitar ou mostrar o IBAN completo.

• Uso de informações de hash de pagamento: Ainda no contexto da vinculação dinâmica, geralmente se questiona se é necessário calcular o código de autenticação sobre as informações de pagamento (valor, ID do beneficiário) ou se é suficiente calcular o código de autenticação em um hash das informações de pagamento. . Se o código de autenticação for calculado com base em um valor de hash e o pagador não visualizar quais informações de pagamento são usadas, os pagadores talvez não entendam em qual transação eles realmente estão se comprometendo. Ataques de engenharia social contra sistemas de autenticação freqüentemente exploram isso.

Esperamos que a EBA forneça esclarecimentos adicionais sobre esses tópicos.

Está disponível uma análise mais aprofundada dos requisitos de SCA do PSD2 no meu blog .

Este artigo, publicado originalmente em 2 de julho de 2019, apareceu pela primeira vez na página pessoal do LinkedIn de Frederik Mennes e no blog do Wordpress.