Apropriação de conta: encare o desafio em vez de bloquear o cliente.

Quando uma tentativa de login parece ser uma invasão de conta, a melhor resposta geralmente não é permitir o acesso nem bloquear a conta. Deixe a sessão continuar com privilégios limitados e solicite comprovação que somente o cliente legítimo possa fornecer antes de qualquer ação sensível: um pagamento, um novo beneficiário, uma alteração de número de telefone ou senha.

Essa comprovação deve estar vinculada à pessoa que você verificou no momento do cadastro, e não a algo que um invasor já possa controlar. Uma selfie recente, que mostre que a pessoa está viva e que foi comparada com o cadastro do cliente, é a opção mais segura para o dia a dia. Um código enviado por SMS para um número que o invasor pode ter acabado de alterar é a opção mais frágil.

Por que bloquear está configurado como padrão errado?

A maioria dos logins que parecem arriscados não são ataques. As pessoas compram celulares novos, viajam, reinstalam aplicativos e pegam emprestado o aparelho de um irmão ou irmã. Uma regra que bloqueia todo novo dispositivo geralmente bloqueia os clientes, e cada bloqueio resulta em uma chamada para o suporte, uma transação perdida ou uma conta encerrada.

Deixar tudo passar é pior. Uma tentativa de invasão que chega à tela de pagamento pode esvaziar uma conta em minutos, e o cliente espera que você tenha percebido.

Uma etapa intermediária se encontra entre as duas. Para um cliente legítimo, ela custa segundos. Para um atacante, custa toda a tentativa, desde que o desafio exija algo que ele não possua.

O que faz um login parecer uma invasão de conta?

Os sinais que sugerem uma aquisição geralmente descrevem uma mudança em relação ao histórico do cliente:

• Um dispositivo que o cliente nunca usou antes.

• Uma mudança de país tão rápida que é impossível de se perceber em uma viagem , como estar em Lagos há uma hora e agora estar em outro continente.

• Um novo dispositivo foi rapidamente seguido por uma ação delicada , como adicionar um beneficiário poucos minutos após o login.

• Uma redefinição de senha ou alteração de número de telefone pouco antes de um saque.

• Um endereço IP proveniente de um provedor de hospedagem, e não de uma rede móvel ou banda larga residencial.

Cada um desses casos tem uma explicação inocente por si só. Juntos, e seguidos por uma tentativa de movimentação de dinheiro, merecem ser questionados.

Qual é um bom desafio de subida de nível?

Classifique os desafios de acordo com a probabilidade de um invasor que assumiu o controle da conta conseguir completá-los.

O padrão é simples: os desafios mais rigorosos estão vinculados à pessoa verificada, e não a uma credencial. Reserve a opção mais complexa para os momentos de maior risco e nunca use um código enviado para dados de contato que foram alterados na mesma sessão.

Onde deve estar o desafio?

Apresente o desafio antes da ação que causa a perda, não apenas no momento do login. Uma política ilustrativa para um aplicativo de carteira digital:

1. Entrar a partir de um dispositivo conhecido: permitir.

2. Ao iniciar sessão a partir de um novo dispositivo, sem mais nada de anormal: permitir, mas ocultar os saldos ou limitar as transferências até ao passo seguinte.

3. Novo dispositivo e beneficiário adicionados na mesma sessão: é necessária uma selfie correspondente ao cadastro antes que o beneficiário seja ativado.

4. Novo dispositivo, mudança rápida de país e um saque acima do valor habitual do cliente: o saque será retido e será necessária uma nova verificação completa.

5. O plano Step-up falhou ou foi abandonado duas vezes: congelar os pagamentos de saída e abrir um processo de revisão.

Isso mantém o cliente no aplicativo em todos os casos, exceto no último, e mesmo assim ele sabe o que fazer em seguida.

Como usar um resultado em etapas

Uma avaliação positiva bem-sucedida é uma prova recente de que a pessoa certa está presente. Registre isso e permita que a restrição seja removida para aquela sessão ou ação.

Uma tentativa de acesso não aprovada é um dos sinais mais fortes de invasão que você pode receber. Analise com cuidado um desafio abandonado: um cliente legítimo pode simplesmente estar ocupado, mas um invasor não consegue concluí-lo; portanto, o abandono repetido de uma sessão de risco merece ser investigado.

Sempre informe ao cliente, por meio de um canal de confiança antes do início da sessão, que um novo dispositivo foi utilizado e que uma verificação foi solicitada.

Como Toden suporta esse fluxo

As peças se encaixam como sinais, um desafio e um resultado.

Sinais. Seu sistema pode enviar logins, redefinições de senha, adições de beneficiários, alterações de dispositivo, pagamentos e saques paraPOST /api/v1/activities, com a referência do seu dispositivo, o endereço IP e a localização do cliente, e receba umallow,reviewoublockA decisão é baseada nas regras que foram acionadas ( documentação de monitoramento de atividades (abre num novo separador) ). Reutilizar uma referência de dispositivo estável gera evidências de novos dispositivos ao longo do tempo, e as regras integradas incluem novos dispositivos e mudanças rápidas de país. Esta área de Monitoramento de Fraudes requer a autorização de Prevenção de Fraudes e um perfil comercial aprovado.

Desafio. Para indivíduos, uma nova verificação adicional pode ser solicitada a partir de um fluxo de trabalho, através do API ou pelo painel de controle. Você recebeentity.step_up_requestedcom um desafio hospedado URL e sua data de validade, que você envia ou mostra ao cliente ( webhooks de decisão de atividade (abre num novo separador) ). Trate isso URL como informação sensível. Para clientes recorrentes que já se inscreveram, a reautenticação biométrica compara uma nova selfie diretamente com a referência de inscrição.

Resultado. entity.step_up_completedIndica se o cliente foi aprovado; continue somente quandopassedÉ verdade. Elimine as duplicatas de cada webhook pelo seu ID de evento.

Sua plataforma aplica o resultado. Toden Pode recomendar a revisão ou reportar um desafio falhado, mas não pode desativar um login, conta ou carteira hospedada em seus próprios sistemas.

Uma lista de verificação antes do envio.

1. Liste as ações que podem causar prejuízos e apresente um desafio para cada uma delas.

2. Decida quais sinais desencadeiam qual desafio, começando com um novo dispositivo e uma ação sensível.

3. Remova qualquer desafio que dependa de dados de contato alterados na mesma sessão.

4. Certifique-se de que um desafio aprovado remova a restrição sem a necessidade de abrir um chamado de suporte.

5. A rota falhou e abandonou repetidamente os desafios a um caso, e notifique o cliente por meio de um canal confiável.

6. Analise um mês de desafios: quantos clientes legítimos foram atendidos e quantos ataques foram interrompidos durante o desafio.

Saiba mais sobre prevenção e detecção de fraudes com Toden .