[MASOCH-L] RES: Phishing Santander

[Rubens Kuhl]

Problema 1: A RFB não disponibiliza para o Registro.br a data de nascimento.
Problema 2: Muitos cadastros de identidades à venda incluem nome completo
correto e data de nascimento.

Quanto ao algoritmo, acho que o Levenshtein distance é mais apropriado ao
caso do que o LCS, apesar de computacionalmente mais intensivo.

https://en.wikipedia.org/wiki/Levenshtein_distance


Rubens


2017-08-16 8:55 GMT-03:00 Leandro Carlos Rodrigues <
leandro at allchemistry.com.br>:

> Eu ainda acredito que a melhor forma de resolver grande parte deste
> problema é validando a documentação do sujeito, já que o CPF é uma
> informação obrigatória no registro.br.
>
> Existem duas formas de fazer uma validação superficial do CPF:
>
> 1. comparação da data de nascimento e
> 2. comparação do nome.
>
> Para 1, a comparação é direta pois não existe subjetividade. Para 2, como
> existe um problema de subjetividade na escrita e antecipada pelo Rubens, é
> possível construir um algoritmo, baseado no LCS, para determinar se o
> comprimento do LCS entre as duas cadeias de caracteres normalizadas é
> proporcional ao tamanho da cadeia do nome real:
>
>    https://en.wikipedia.org/wiki/Longest_common_subsequence_problem
>
> Sendo 1 inválido, o processo de cadastro é automaticamente interrompido.
> Sendo 2 inválido, levando-se em conta um limiar pré-definido, conclui-se o
> cadastro mas o sistema lança um alerta para que o responsável pelos
> registros possa investigar.
>
> Eu poderia construir esse algorítimo como código aberto para a comunidade
> e o registro.br teria apenas que implementar ele no processo de cadastro
> de titularidade com CPF.
>
> Resolvendo essa parte de cadastros fraudados, a gente pensa em outras
> soluções para a parte restante do problema, quando o CPF é aparentemente
> válido mas está sendo usado para phishing.
>
> Leandro Carlos Rodrigues
> TI All Chemistry do Brasil
> (11) 3014-7100
>
>
> Em 16/08/2017 08:15, Douglas Fischer escreveu:
>
>> Uma sugestão que acredito que não faça parte do registro.br, mas talvez
>> faça do CERT, seria um mecanismo extra que validasse por um período de
>> 30-45 dias a aparência do site inicial.
>>
>> Sei que isso envolve muitas técnicas complexas como bots de varredura, IA,
>> e outras coisas de alto nível de complexidade... Mas o resultado pode ser
>> bastante eficaz...
>>
>> A lógica é mais ou menos a seguinte:
>> Porque o "Zé das couves" iria lançar na internet um site(independente da
>> string do domínio) que tem a mesma aparência do site do Itaú?
>>
>> A ideia inclusive não é nova e inspirada em filme.
>>
>>
>> O "senão" nesse caso é a delimitação de onde termina o papel o
>> CGI/CERT/Registro e onde começa o papel das instituições alvo(maioria
>> bancos) e suas respectivas entidades representativas(?febraban?).
>>
>>
>>
>> Em 15 de agosto de 2017 18:17, Rubens Kuhl <rubensk at gmail.com> escreveu:
>>
>> 2017-08-15 17:49 GMT-03:00 Eduardo Schoedler <listas at esds.com.br>:
>>>
>>> Não existe um gatilho, baseado em palavras chaves óbvias (como
>>>> "santander", por exemplo) que vá para aprovação?
>>>>
>>>> Não, e isso não resolve o problema. Por exemplo, que palavra chave
>>> limitar
>>> em atualizainicial2.com.br (caso real de agora há pouco) ? Ou em iatu,
>>> bardesco, satader ?
>>>
>>> O que existe é uma combinação de monitoração das palavras chaves óbvias
>>> com
>>> fontes de inteligência.
>>>
>>>
>>>> Ou pelo menos não liberar imediatamente, mesmo com essas formas de
>>>> pagamento com liberação rápida?
>>>>
>>>> Só se fosse possível avaliar algo como 1/3 ou 1/2 dos domínios
>>> registrados
>>> todos os dias, ou reverter a lógica de ativação, como acontece com o
>>> b.br(exclusivo
>>> para bancos), jus.br e gov.br.
>>>
>>> Por sinal, o Santander é mais um dos bancos que não aderiu a usar
>>> maciçamente o b.br... o que se tivesse acontecido, evitaria que os
>>> usuários
>>> incautos caíssem em golpes envolvendo nomes dos bancos, pois teriam se
>>> habituado a só confiar em domínios b.br.
>>>
>>> Assim, ponha isso também na conta do marketing de quem preferiu continuar
>>> no com.br mesmo dispondo de um "safe haven" para seu setor de atuação.
>>>
>>>
>>> Rubens
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>
>>>
>>
>>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>