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

Eduardo Coelho eduardocoelholima em gmail.com
Sexta Dezembro 6 17:29:46 UTC 2013


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?
>>>
>>> Eu acredito que sim, pois nesse caso não há certificado digital. Sei que
>>> existe a assinatura digital, porém essa também é enviada pelo mesmo meio do
>>> comando.
>>>
>>> Ainda não consegui entender como mitigar isso. Mas sei que existe.
>>> Detalhe, gostaria que fosse o mais próximo do tempo real possível.
>>>
>>> Se alguém poder auxliar ai, fico grato.
>>> Abraços!
>>>
>>> --
>>> 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.
>>>
>>
>>  --
>> 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!!!
>
> --
> 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.
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.owasp.org/pipermail/owasp-natal/attachments/20131206/514bec63/attachment-0001.html>


More information about the Owasp-natal mailing list