Primeiros passos
Integração / SDKs
Verificação de usuários
Verificação de empresas
Monitoramento de transações
Registro de alteraçõesConfigurar a proteção
Leia e altere as configurações comGET e PATCH em protection/ na API de gerenciamento de autenticação da sua aplicação, ou pelo console.
enabled e breached_password_check são false por padrão. Os modos acima são os padrões depois que você ativa a proteção.
Políticas
As políticas
vpn e travel usam a análise de IP da Didit. Se essa consulta estiver indisponível, a tentativa continua; um login nunca falha por causa dela. A localização para travel só é atualizada depois de um login concluído.
Força bruta e bloqueio de conta
O modo debrute decide o que acontece após 5 falhas:
- Block: a pessoa precisa redefinir a senha antes de poder fazer login novamente.
- Challenge: a conta fica bloqueada por 15 minutos, e a próxima tentativa exige uma prova adicional.
- Off ou Log: nenhum bloqueio.
Pontuação de bot e sinais do dispositivo
Envie sinais do dispositivo nas chamadas de runtime com estes cabeçalhos. As páginas hospedadas os enviam por você.
Esses sinais são contexto para uma decisão, não prova de identidade. Eles também acompanham cada evento de login, em que as regras podem ler
event.device.bot_score.
AUTOMATION_FRAMEWORK_DETECTED é uma verificação diferente. É um aviso da análise de IP e dispositivo em sessões de verificação, gerado quando o SDK de verificação informa a detecção de um framework de automação de navegador. Ele não é executado no login. No login, a automação é detectada pela política bots acima.Desafios
Uma tentativa sujeita a um desafio retorna isto em vez de um código de login:POST protection/complete/:
{"challenge", "method": "email_code", "code"}com o código de 6 dígitos enviado ao e-mail da pessoa, ou{"challenge", "method": "passkey", "response"}com a resposta WebAuthn.
403 {"error": "protection_factor_unavailable"}.
Senhas vazadas
Combreached_password_check: true, a Didit verifica senhas novas e redefinidas em relação a senhas vazadas conhecidas. A senha em si nunca é enviada a lugar nenhum. Uma senha vazada é rejeitada com password_breached. No login, uma senha vazada conta como uma correspondência de stuffing. Se a verificação estiver indisponível, a senha é aceita.
Modo de ataque
Ative o modo de ataque durante um ataque em andamento:POST protection/attack-mode/com{"duration_hours": 1}(ou6ou24) retorna201.DELETE protection/attack-mode/o encerra antes do previsto. Ele também termina sozinho após o período definido.
- todos os cadastros e logins precisam passar por um desafio de passkey. Um código por e-mail não é aceito. Novos cadastros e pessoas sem passkey não conseguem concluir o cadastro até o modo de ataque terminar.
- um cadastro feito a partir de uma VPN, do Tor ou de uma rede de data center é bloqueado.
Limites de requisições
Toda rota de runtime é limitada por IP, por aplicação:
Acima do limite, a chamada retorna
429. Respeite o cabeçalho Retry-After quando ele for enviado. As tentativas de login também são limitadas por minuto: 60 por IP, 15 por conta, 30 por dispositivo, 1.000 por aplicação e 20 requisições de código por SMS ou WhatsApp por prefixo de número de telefone.
Eventos
Cada decisão é registrada como um evento de autenticação:risk_logged, attempt_challenged, attempt_blocked, challenge_passed, challenge_failed, attack_mode_started e attack_mode_ended. O evento mostra qual política foi correspondida.