[MASOCH-L] RES: Phishing Santander

Wed Aug 16 16:09:29 -03 2017

Do meu ponto de vista o caso do phishing em si não deve ser tratado pelo
registro.br, isso deveria ser uma preocupação das empresas que tem suas
páginas clonadas. Imagina a complexidade para rastrear todos os sites no
.br que possuem um e-commerce (já que não seria muito justo identificar
fraudes para os grandes e conhecidos, mas não para os que estão iniciando).

No caso da restrição de registro, o que já vi em outros ccTLD é que a
documentação exigida é maior. Já vi alguns que usam algo que seria parecido
com o nosso número do recibo do IR, comprovante de residência, fotos, etc.
Isso aumentaria consideravelmente o trabalho manual dentro do registro.br,
mas creio que teria uma redução expressiva para esses casos.

PS: Na minha opinião mesmo se esse tipo de restrição fosse adotado não muda
o fato do phishing funcionar... Uma pessoa que cai num phishing de
satader.com.br muito provavelmente vai cair num com satader.com e muitos
outros mais.

2017-08-16 15:32 GMT-03:00 Leandro <leandro at spfbl.net>:

> Oi Rubens. Eu sempre tento achar algum registro do CPF fraudado no Google
> e, muito raramente, retorna algo com um nome bem diferente do registrado no
> registro.br. Tipo aquele caso da mulher na base de dados do TRE, onde o
> fraudador usou um nome de homem bem diferente.
>
> Sei que a amostragem aqui é pequena demais para afirmar algo, mas pode ser
> que as fontes que eu encontrei estejam erradas ou pode também ser que a
> informação que deram ao registro.br estava errado.
>
> Independente de ser representativo ou não esse grupo de fraudadores
> criativos, só existem três hipóteses possíveis se a validação superficial
> do CPF for feita:
>
>    1. O resultado ser o mesmo, indicando que realmente a grande massa vem
>    de registros completos roubados;
>    2. O resultado melhorar, indicando que existe sim uma parcela que
>    inventa CPF e nomes ou
>    3. O problema ser completamente resolvido.
>
> A hipótese que numa ocorrerá, caso a validação superficial for implementada
> é:
>
>    1. O resultado ser pior que já é hoje.
>
> Visto que o risco do pior cenário se concretizar ser algo sem prejuízo
> algum, o risco do melhor cenário se concretizar me parece bem convidativo
> em troca o esforço adicional empregado.
>
> Leandro
> SPFBL.net
>
> Em 16 de agosto de 2017 15:14, Rubens Kuhl <rubensk at gmail.com> escreveu:
>
> > Mas isso pressupõe que o conjunto de fraudes realizados com quem só tem o
> > CPF é representativo, e isso não bate com a nossa experiência.
> > E a experiência bate com com as grandes fontes de dados no mercado
> > underground: vazamentos de grandes massas de cadastros como a da
> > Ingresso.com ou da declaração de IR, vazamentos de senhas de acesso ao
> > SERASA ou seus parceiros...
> >
> >
> > Rubens
> >
> >
> > 2017-08-16 10:20 GMT-03:00 Leandro Carlos Rodrigues <
> > leandro at allchemistry.com.br>:
> >
> > > Só para deixar claro a minha intenção, essa solução não resolve a parte
> > do
> > > problema onde grupo de fraudadores tem acesso ao nome e à data de
> > > nascimento do dono do CPF.
> > >
> > > Antes que resolver esta parte do grupo com acesso, é necessário
> > dificultar
> > > a fraude para o grupo que  não tem este acesso. Uma vez resolvida esta
> > > parte, a gente parte para solucionar a parte do grupo com o acesso.
> > >
> > > A gente tem que resolver problemas complexos por divisão e conquista.
> Se
> > a
> > > gente tentar achar uma solução definitiva logo de cara, chegaremos a
> > lugar
> > > nenhum.
> > >
> > > Leandro Carlos Rodrigues
> > > TI All Chemistry do Brasil
> > > (11) 3014-7100
> > >
> > > Em 16/08/2017 09:36, Leandro Carlos Rodrigues escreveu:
> > >
> > >> Show. Que tal então rodar o Levenshtein distance com a normalização
> das
> > >> cadeias e pegar a data de nascimento somente para tentar acessar a
> > consulta
> > >> no site da Receita, somente quando o limiar for ultrapassado?
> > >>
> > >> A data de nascimento neste caso serviria somente para uma ação humana,
> > >> quando o algorítimo estiver acusando uma diferença grande demais.
> Vocês
> > nem
> > >> precisariam pedir a data de nascimento a priori. Deixe o sujeito se
> > >> estrepar no Levenshtein distance e peçam a data, numa tela posterior,
> > caso
> > >> a distância seja grande demais. Se a distância for pequena, bola pra
> > frente.
> > >>
> > >> Só de vocês pedirem a data de nascimento em casos bem específicos, já
> > vai
> > >> causar um certo medo no sujeito com más intenções.
> > >>
> > >> Leandro Carlos Rodrigues
> > >> TI All Chemistry do Brasil
> > >> (11) 3014-7100
> > >>
> > >> Em 16/08/2017 09:26, Rubens Kuhl escreveu:
> > >>
> > >>> 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
> > >>>
> > >>
> > >> __
> > >> masoch-l list
> > >> https://eng.registro.br/mailman/listinfo/masoch-l
> > >>
> > >
> > > __
> > > masoch-l list
> > > https://eng.registro.br/mailman/listinfo/masoch-l
> > >
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>

-- 
*Victor*