[Owasp-natal] [hackerspace-natal] Re: [InfraRN] Como mitigar ataques de duplicação (replay)

Eduardo Santos - Barros cebsjg3ster em gmail.com
Sexta Dezembro 6 18:17:14 UTC 2013


Muito interessante essa técnica OTP - One Time Password:
http://en.wikipedia.org/wiki/One-time_password
Não a conhecia e serve para evitar ataques de repetição.


Em 6 de dezembro de 2013 15:13, Eduardo Santos - Barros <
cebsjg3ster em gmail.com> escreveu:

> Obrigado, Welkson!
>
> Entendi, Eduardo, é que na situação não teria CAs. Mas sua expliação me
> ajudou a exemplificar e massificar os conceitos de PKI. Muito obrigado!
> É uma situação hitpotética para sistemas não ligados à Internet, porém com
> comunicação segura entre eles, entendes?!
>
> Vlw!
>
>
>
> Em 6 de dezembro de 2013 15:06, Eduardo Coelho <
> eduardocoelholima em gmail.com> escreveu:
>
> Cara,
>>
>> PKI pressupoe uso de certificados verificados junto a CAs. Uma maquina
>> tentando se passar por outra nao teria o certificado validado. Entao nao eh
>> pra ter esse problema que vc mencionou, saca?
>>
>>
>> On Friday, December 6, 2013, Eduardo Santos - Barros wrote:
>>
>>> Verdade, entendi!
>>>
>>> Mas mesmo assim, seria possível um terceiro capturar esses dados, mesmo
>>> sem entender nada, e reenviá-los de forma legítima?
>>> Porque na verdade ele não alteraria em nada a mensagem, apenas guardaria
>>> e enviaria em outro momento, apenas para prejudicar (como um script kid).
>>>
>>> Será que é possível um atacante fazer isso ou ele não consegue capturar
>>> nada por que está criptografado, assinado e com certificado?
>>>
>>>
>>> Em 6 de dezembro de 2013 14:29, Eduardo Coelho <
>>> eduardocoelholima em gmail.com> escreveu:
>>>
>>> Rpz, na verdade se você usar SSL com PKI, por exemplo, ele usa
>>> criptografia assimétrica no estabelecimento do canal e depois simétrica pra
>>> troca de dados, exatamente por conta do custo computacional da criptografia
>>> simétrica ser bem inferior. Então já é basicamente o melhor dos mundos.
>>>
>>> Se você optar somente por criptografia simétrica, você não consegue
>>> todas as garantias de segurança necessárias. Por exemplo, fica difícil
>>> garantir autenticidade.
>>>
>>>
>>>
>>>
>>> # Eduardo Coelho Lima
>>> # http://www.coelho.pro.br
>>>
>>>
>>> 2013/12/6 Eduardo Santos - Barros <cebsjg3ster em gmail.com>
>>>
>>> Fala ai chará, muito obrigado pela resposta.
>>> Entendo que se proteger o meio com PKI, seria a melhor opção, porém
>>> gostaria que fosse algo o mais próximo possível do tempo real.
>>> E como sabemos a estrutura de criptografia assimétrica é bastante lenta
>>> em relação a simétrica. (*RSA is much, much slower*<http://stackoverflow.com/questions/118463/what-is-the-performance-difference-of-pki-to-symmetric-encryption>
>>> )
>>>
>>> Teria alguma forma de fazer isso com chaves simétricas (AES, DES ou
>>> 3DES) ou existira alguma outra estrutura, com autenticação, por exemplo,
>>> que conseguisse ser liver do ataque de replay?
>>>
>>> Abraços!
>>>
>>>
>>> Em 6 de dezembro de 2013 14:03, Eduardo Coelho <
>>> eduardocoelholima em gmail.com> escreveu:
>>>
>>> Caro chará,
>>>
>>> Existe um conhecido recurso usado no armazenamento de senhas que é o
>>> "salt" (tradução literal: sal). Tentando explicar de forma ultra simplista,
>>> consiste em uma string a ser adicionada à entrada de uma função
>>> criptográfica/hash, para garantir que duas senhas iguais gerem saídas
>>> diferentes. O salt não precisa ser mantido em segredo, mas precisa ser
>>> único para cada usuário.
>>>
>>> Este recurso é usado principalmente para evitar ataques a bancos de
>>> hashs de senhas usando "rainbow tables", que é basicamente uma tabela
>>> computada com saídas da função hash e entradas possíveis (lembrando que
>>> funções hash normalmente aceitam entradas de qualquer tamanho e saídas de
>>> tamanho fixo).
>>>
>>> No caso específico que você levantou, existem ainda a questão do canal
>>> de troca de dados. As técnicas de spoofing e de man-in-the-middle podem ser
>>> usados para tentar um ataque de replay. A principal linha que vejo como
>>> possível para mitigação para estes riscos seria através da proteção do
>>> canal de comunicação, por exemplo, uso de PKI e criptografia, buscando a
>>> fórmula autenticidade/não repúdio, integridade, confidencialidade,
>>> disponibilidade [1].
>>>
>>> [1] http://en.wikipedia.org/wiki/Information_security#Key_concepts
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> # Eduardo Coelho Lima
>>> # http://www.coelho.pro.br
>>>
>>>
>>> 2013/12/6 Eduardo Santos - Barros <cebsjg3ster em gmail.com>
>>>
>>>  Companheiros (as), boa tarde!
>>> Estava estudando sobre criptografia aqui e fiquei com uma dúvida em
>>> relação a como mitigar ataques de repetição (replay).
>>>
>>> Observem essa situação no qual desejo enviar um comando de um chute em
>>> um jogo (video game), essa mensagem é criptografada com criptografia
>>> simétrica (DES, por exemplo) no qual apenas o jogador (Alice) e o jogo
>>> (Bob) detêm a chave.
>>>
>>> Caso uma terceira pessoa (Carlos) intercepte o comando do chute
>>> (criptografado), ele não sabe o que é, mas ai reenvia o comando, o que
>>> acontece com o jogo (Bob), irá chutar? Carlos consegue fazer isso?
>>>
>>>
>>>
>>>
>>> --
>>> Que a graça e a paz que excede todo o entendimento seja com todos, para
>>> todo o sempre...amém!!!
>>>
>>> --
>>> Você está recebendo esta mensagem porque se inscreveu no grupo "InfraRN"
>>> dos Grupos do Google.
>>> Para cancelar a inscrição neste grupo e parar de receber seus e-mails,
>>> envie um e-mail para infrarn+unsubscribe em googlegroups.com.
>>> Para postar neste grupo, envie um e-mail para infrarn em googlegroups.com.
>>> Visite este grupo em http://groups.google.com/group/infrarn.
>>> Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
>>>
>>
>>
>> --
>>
>> # Eduardo Coelho Lima
>> # http://www.coelho.pro.br
>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "hackerspace-natal" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to hackerspace-natal+unsubscribe em googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>
>
> --
> Que a graça e a paz que excede todo o entendimento seja com todos, para
> todo o sempre...amém!!!
>



-- 
Que a graça e a paz que excede todo o entendimento seja com todos, para
todo o sempre...amém!!!
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.owasp.org/pipermail/owasp-natal/attachments/20131206/64b95bbe/attachment-0001.html>


More information about the Owasp-natal mailing list