Sinalização de Dispositivo e Rede para Detectar Abuso de Contas em APIs de IA (PT-BR-1)

Uma conta é uma linha em um banco de dados. Um dispositivo é um objeto físico pelo qual alguém pagou.

Essa assimetria é a base da detecção de abuso em nível de dispositivo, e é por isso que uma operação de fraude que pode gerar 20.000 contas gratuitamente não pode gerar 20.000 dispositivos gratuitamente. Em algum lugar abaixo da camada de contas, há um conjunto finito de hardware real, caminhos de rede reais e um conjunto de truques usados para fazer esse pequeno conjunto parecer grande.

Esses truques têm assinaturas. Este post é um tour pelos sinais que a análise de dispositivo e rede da Didit emite, o que cada um realmente significa e como ponderá-los — por US$ 0,03 por verificação, ou incluído no pacote de verificação completa de US$ 0,33.

Principais conclusões

• Operações de fraude reutilizam um substrato físico pequeno por trás de uma grande superfície de contas. A reutilização é detectável.
• Três famílias de sinais importam: duplicação (mesmo dispositivo ou endereço, mais de uma vez), integridade (este não é um cliente normal) e rede (este caminho não é o que afirma ser).
• DEVICE_RECOVERED_HIGH_CONFIDENCE é o código único de maior valor para este problema — ele detecta um dispositivo retornando após uma limpeza, que é o movimento padrão de regeneração.
• Códigos de integridade como AUTOMATION_FRAMEWORK_DETECTED e DEVICE_EMULATOR_DETECTED são fortes por si só. Códigos de duplicação são fracos por si só e precisam de corroboração.
• As ações de aviso são configuráveis por código — recusar, revisar ou registrar — então a escada de escalonamento é sua.
• US$ 0,03 por verificação avulsa; incluído no pacote de verificação de US$ 0,33.

As três famílias de sinais

Duplicação — já vi isso antes?

Código	Significado
DUPLICATED_DEVICE_FINGERPRINT	O mesmo dispositivo aparece por trás de mais de uma verificação
DUPLICATED_IP_ADDRESS	O mesmo endereço aparece por trás de mais de uma verificação
DEVICE_RECOVERED_HIGH_CONFIDENCE	Um dispositivo visto anteriormente retornando após uma redefinição ou reinstalação
EXPECTED_IP_ADDRESS_MISMATCH	O endereço difere do esperado para esta sessão

A Didit faz uma distinção explícita entre um dispositivo duplicado e um dispositivo recuperado, e a diferença é a parte interessante.

Um dispositivo duplicado são duas verificações do mesmo dispositivo — comum, muitas vezes inocente. Um tablet familiar. Uma estação de trabalho compartilhada. Um agente de suporte ajudando um usuário em um fluxo.

Um dispositivo recuperado é um dispositivo que foi limpo, redefinido ou teve o aplicativo reinstalado, e agora voltou. A Didit ainda o reconhece.

Para a fraude de contas, esse segundo caso é o sinal de ouro. O procedimento operacional padrão após um banimento é redefinir o dispositivo e registrar novamente — é precisamente isso que faz uma rede hidra se regenerar mais rápido do que é podada. DEVICE_RECOVERED_HIGH_CONFIDENCE em uma conta nova diz: este hardware já esteve aqui antes, sob uma conta diferente, e alguém se deu ao trabalho de tentar apagar isso. Quase nada legítimo produz essa combinação em uma primeira verificação.

Integridade — este é um cliente normal?

Código	Significado
AUTOMATION_FRAMEWORK_DETECTED	O cliente está sendo operado por automação, não por uma pessoa
DEVICE_EMULATOR_DETECTED	Um dispositivo emulado em vez de hardware real
DEVICE_ROOTED_OR_JAILBROKEN	O modelo de segurança do sistema operacional foi removido
DEVICE_RUNTIME_HOOKING_DETECTED	Instrumentação de tempo de execução está anexada ao processo
DEVICE_APP_TAMPERED	O binário do aplicativo foi modificado
DEVICE_DEBUGGER_ATTACHED	Um depurador está anexado
DEVICE_INTEGRITY_SIGNALS_MISSING	Sinais de integridade esperados estão ausentes

Esta família é qualitativamente diferente da duplicação, e vale a pena ser claro sobre o porquê: esses códigos descrevem intenção.

DUPLICATED_IP_ADDRESS pode acontecer com qualquer um em uma universidade. AUTOMATION_FRAMEWORK_DETECTED em um fluxo de verificação significa que alguém está executando uma verificação de identidade com um script. DEVICE_EMULATOR_DETECTED significa que o "telefone" que completa sua verificação é um software rodando em um servidor — a maneira mais barata de fazer uma máquina parecer cem. DEVICE_APP_TAMPERED significa que o binário do cliente foi modificado, que é o que você faz quando quer que ele relate coisas que não são verdadeiras.

Fazendas de emuladores e frameworks de automação são as ferramentas industriais da fraude de contas. Quando aparecem em uma verificação, a explicação inocente é tênue.

DEVICE_INTEGRITY_SIGNALS_MISSING é o mais sutil. Ele não diz que algo está errado — ele diz que os sinais que diriam que nada está errado não chegaram. Trate a ausência como um negativo fraco em vez de neutro, porque suprimir a telemetria é uma técnica em si.

Rede — este caminho é o que afirma ser?

Código	Significado
PRIVATE_NETWORK_DETECTED	Um caminho de rede privado ou anonimizador
COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP	A geografia do documento e da rede não coincidem
IP_LOCATION_NOT_ALLOWED	A localização está fora da sua política configurada
IP_ADDRESS_IN_BLOCKLIST / IP_ADDRESS_IN_ALLOWLIST	O endereço correspondeu a uma de suas listas
DEVICE_FINGERPRINT_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_ALLOWLIST	O dispositivo correspondeu a uma de suas listas
LOCATION / NO_ACTION	Informativo

Os sinais de rede são a família mais fraca e devem ser ponderados de acordo. Desenvolvedores preocupados com a privacidade usam rotineiramente redes anonimizadoras, e a população de uma API de IA é mais técnica que a média — uma taxa base mais alta de uso de rede privada é esperada, não suspeita.

COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP é mais útil que a geografia bruta porque é uma contradição em vez de uma localização. As pessoas viajam e se mudam, então não é condenatório por si só, mas combinado com um sinal de duplicação, ele se torna consideravelmente mais nítido.

Os códigos de blocklist e allowlist são a metade da aplicação — abordados em detalhes no post sobre propagação de blocklist.

Ponderação: o que é forte, o que é fraco

O erro de implementação mais comum é tratar cada aviso como equivalente. Eles não são nem um pouco equivalentes.

Fortes por si só — base razoável para recusar ou revisar rigorosamente:

DEVICE_EMULATOR_DETECTED · AUTOMATION_FRAMEWORK_DETECTED · DEVICE_APP_TAMPERED · DEVICE_RUNTIME_HOOKING_DETECTED · IP_ADDRESS_IN_BLOCKLIST · DEVICE_FINGERPRINT_IN_BLOCKLIST

Fortes no contexto — escalar quando combinados com qualquer outra coisa:

DEVICE_RECOVERED_HIGH_CONFIDENCE · DEVICE_ROOTED_OR_JAILBROKEN · COUNTRY_FROM_DOCUMENT_DOES_NOT_MATCH_COUNTRY_FROM_IP

Fracos sozinhos — corroborar antes de agir:

DUPLICATED_IP_ADDRESS · PRIVATE_NETWORK_DETECTED · DUPLICATED_DEVICE_FINGERPRINT · DEVICE_INTEGRITY_SIGNALS_MISSING

O padrão é consistente: códigos que descrevem manipulação deliberada do cliente são fortes; códigos que descrevem recursos compartilhados são fracos. Recursos compartilhados têm milhares de explicações inocentes. Um binário modificado não.

Configurando a resposta

As ações de aviso são configuráveis por código, para que você possa construir uma verdadeira escada de escalonamento em vez de um único portão de aprovação/reprovação.

Um padrão de trabalho para uma API de IA:

• Recusar em DEVICE_APP_TAMPERED, DEVICE_EMULATOR_DETECTED, AUTOMATION_FRAMEWORK_DETECTED e qualquer acerto de blocklist. Uma correspondência de blocklist força uma recusa por design.
• Revisar em DEVICE_RECOVERED_HIGH_CONFIDENCE e em DEVICE_ROOTED_OR_JAILBROKEN.
• Somente registrar em DUPLICATED_IP_ADDRESS, PRIVATE_NETWORK_DETECTED e LOCATION — capture-os para correlação, mas nunca aja apenas com base neles.

Os códigos somente registrados não são desperdiçados. Eles são o que torna uma investigação possível seis semanas depois, quando sua camada de tráfego sinaliza uma conta e você precisa saber o que mais ela toca. Coletá-los no nível mais barato, conforme descrito na arquitetura de acesso com camadas de risco, é o que faz a correlação posterior funcionar.

Lendo os sinais em uma sessão

Os resultados de dispositivo e rede chegam com a decisão da sessão:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

Encaminhe com base nos avisos, não apenas no status de nível superior. Uma sessão aprovada que contém DUPLICATED_DEVICE_FINGERPRINT e DEVICE_RECOVERED_HIGH_CONFIDENCE é aprovada e vale a pena uma análise mais detalhada — e se você ler apenas o status, nunca saberá.

A Didit também exibe correspondências entre sessões, que é como você passa de um único aviso para o conjunto de outras sessões que compartilham aquele dispositivo ou endereço. Esse é o pivô de uma conta para um cluster.

Casos de uso

Plataformas de API de IA coletando sinais de dispositivo e rede no nível pago mais barato para que os dados de correlação existam antes que sejam necessários.

Programas de teste gratuito e crédito onde fazendas de emuladores são o vetor de abuso dominante e DEVICE_EMULATOR_DETECTED sozinho remove a maior parte do volume.

Marketplaces e plataformas de gig economy detectando vendedores ou entregadores removidos retornando em hardware limpo.

iGaming aplicando regras de conta única e autoexclusão, onde a recuperação de dispositivo é a evasão padrão.

Perguntas frequentes

Isso funciona na web ou apenas em aplicativos móveis?

Ambos. A profundidade dos sinais de integridade é maior em dispositivos móveis nativos, onde o sistema operacional expõe mais — códigos como DEVICE_ROOTED_OR_JAILBROKEN e DEVICE_APP_TAMPERED são conceitos de aplicativos nativos. As sessões da web ainda produzem sinais de rede e correlação de dispositivos.

Um atacante determinado pode derrotar o fingerprinting de dispositivo?

Sim, parcialmente — é por isso que é uma família entre várias, em vez da resposta completa. O objetivo não é a identificação perfeita, é o custo. Cada camada de evasão que um operador adiciona custa dinheiro e tempo de engenharia, e as ferramentas de evasão em si acionam códigos de integridade. Um atacante que derrotou o fingerprinting de dispositivo geralmente é visível em uma das outras famílias de sinais.

O que US$ 0,03 realmente compra?

Uma verificação de análise de IP e dispositivo em uma sessão, retornando o catálogo completo de avisos. É cobrado por verificação bem-sucedida sem mínimo, e já está incluído quando você executa o pacote de verificação completa de US$ 0,33.

Um sinal de rede privada é suficiente para recusar?

Não, e recusar por isso custará desenvolvedores reais. Para um público técnico, redes anonimizadoras são comuns. Registre-o e use-o como corroboração.

Como isso se relaciona com a detecção de destilação no tráfego?

Não detecta destilação. Os sinais de dispositivo e rede informam sobre o cliente e a conta, nunca sobre o conteúdo do seu tráfego de API. A detecção semântica é uma camada separada que vive em sua própria pilha. Esses sinais informam quantas contas um operador está executando; sua camada de tráfego informa o que eles estão fazendo com elas.

Pronto para começar?

A análise de dispositivo e rede é uma única verificação em qualquer sessão de verificação.

• Leia a documentação — Visão geral da Análise de IP e Dispositivo e o catálogo completo de avisos.
• Veja o produto — Verificação de Usuário.
• Verifique os preços — US$ 0,03 por verificação, incluído no pacote de US$ 0,33, sem mínimos.
• Comece gratuitamente — business.didit.me, 500 verificações KYC por mês sem custo.