1. Este site usa cookies. Ao continuar a usar este site está a concordar com o nosso uso de cookies. Saber Mais.

Qual das duas formas a mais segura?

Discussão em 'Dúvidas e Suporte—Internet, Redes, Segurança' iniciada por paperless, 19 de Outubro de 2007. (Respostas: 11; Visualizações: 1150)

  1. paperless

    paperless Power Member

    Hoje decidi voltar a configurar o meu router e fiquei indeciso numa questão.

    Seria mais seguro ter o DHCP ligado e que apenas atribuisse IPs automaticamente num intervalo bastante limitado (por exemplo o numero de PCs que queremos que sejam ligados ao router) [PIC1] ou desligar o DHCP e definir o IP manualmente em cada um deles?

    A mais segura não é a primeira opção? No meu caso pus um range no meu router bastante pequeno (so dois IPs possiveis), assim mesmo que alguem passasse pelas outras verificações (passe, mac adress..etc) não conseguiria obter um IP na rede interna, o que estragava tudo para o emplastro.

    Cumps.

    PIC1

    [​IMG]
     
    Última edição: 19 de Outubro de 2007
  2. IcePicK

    IcePicK Power Member

    Mas a questão é que isso não impede ninguém de utilizar a tua rede. Numa rede com servidor de DHCP, não é obrigatório obter os endereços através dele. Podem ser atribuidos manualmente.

    Esse tipo de artimanhas não impede ninguém de entrar na tua rede. Uma pessoa que consegue quebrar a segurança "imposta" por outros métodos, consegue muito facilmente saber qual a gama de endereços utilizada (sejam eles atribuidos por DHCP ou manualmente). A única coisa que podias utilizar a teu favor aí era colocar uma mascara de rede para limitar o número de IPs válidos na rede, por exemplo 255.255.255.254 para uma rede com os endereços 192.168.2.0 e 192.168.2.1.
     
  3. paperless

    paperless Power Member

    Ah..bom que grande confusão que estava a fazer então.

    Já percebi, não me lembrei que com o DHCP ligado os IPs podiam ser atribuidos manualmente a mesma..(:D)

    Então ja que não posso restringir os IPs manuais possiveis de forma directa no configurador do router vou tentar isso que sugeriste.

    Obrigado.

    EDIT: Tambem nao posso mudar a subnet mask..bla bosta.
     
    Última edição: 19 de Outubro de 2007
  4. IcePicK

    IcePicK Power Member

    Ops, pois também não reparei nisso. Eu penso que com WPA e uma MAC White List é suficiente para o nível de segurança que necessitas.

    Por mais segurança que introduzas no sistema não vais impedir que uma pessoa determinada entre, portanto simplesmente dificulta acesso aos leechers que por aí andam.
     
  5. nickie

    nickie Power Member

    A mais segura é a WPA2 com encriptação AES. Se conseguires configurar desta forma tanto melhor. Para além disso deves gerar uma key com 63 chars retirados da tabela ASCII. Não convém usar palavras completas e conhecidas porque pode ser quebrada por brute force.
     
    Última edição: 19 de Outubro de 2007
  6. PrOdG

    PrOdG Power Member

    Brute force e ataque de dicionário são coisas diferentes. As chaves com combinações conhecidas são mais facilmente quebráveis por ataque de dicionário, por brute force qualquer chave pode ser quebrada (teóricamente e não fisicamente),

    PS: Já para não falar que uma chave de 128 bits (16 caracteres) é mais do que suficiente.
     
    Última edição: 19 de Outubro de 2007
  7. ShadeX

    ShadeX Power Member

    Certo mas errado. Uma password de complexidade e tamanho extremos validada por um algoritmo complexo pode ter um tempo de "break" em termos de brute forcing que seja incompativel com o tempo de vida do sistema solar...

    Basta teres um keyspace/keysize suficientemente grande e estás nesse barco. As melhores cryptos's baseiam-se no principio que uma pass decente com um algoritmo decente vai pura e simplesmente demorar uma porrada de tempo a ser vitima de brute-force. Se passares para keyspaces/keysizes mesmo grandes passa a ser tipo como acertar no totoloto, mas pior :)

    p.s. as de 128 já não são consideradas suficientes. O risco já é suficiente passar à fase seguinte. Lol, só gostava de saber pq raio não passam já para 2048b como eu e têm decadas de descanso.
     
    Última edição: 19 de Outubro de 2007
  8. nickie

    nickie Power Member

    Tens razão.
     
  9. PrOdG

    PrOdG Power Member

    Uma chave de 128 bits é computacionalmente impossível de quebrar por brute force, tanto hoje em dia como muito (mas mesmo muito) provavelmente durante os próximos anos. Além da enormidade de tempo utilizado existem ainda os princípios de consumo de energia (dei isso quando estudei Criptografia, não me recordo do nome do teorema) que ditam esta impossibilidade.

    Não concordo contigo quando dizes que os melhores algoritmos se baseiam na premissa de quanto maior a chave, maior a segurança. A grande maioria dos ataques criptográficos visam directamente os algoritmos e não as chaves em si, pelo que utilizar uma chave grande num algoritmo fraco é o mesmo que andar com um Ferrari na A8: não é pela potência do motor que andamos mais rápido numa estrada com buracos.

    A razão de não passarem ainda a chaves de 2048b por default é que tem de haver um compromisso entre o tempo dispendido para quebrar a chave e o tempo dispendido para decifrar a mensagem original. Não vale a pena demorar o triplo a decifrar a mensagem original se o acréscimo de segurança é virtualmente nulo.

    O melhor algoritmo criptográfico (no sentido do mais eficaz) é na realidade aquele que conseguir o maior potencial de segurança consumindo o menor índice de energia possível (problema aplicado a grandes redes de sensores, por exemplo).
     
  10. ShadeX

    ShadeX Power Member

    Isso não é bem assim, tanto que foi o downfall de um certo algoritmo que foi "libertado" mas só a 56b, quando todo o design tinha assumido 64b. Um algoritmo "artificalmente capado" que atm pode ser quebrado por uma ninharia em $$$ (relativamente...) e em umas horas.

    E como podes calcular, a unica razão pela qual os srs da NSA o quiseram assim foi precisamente pq sabia que podiam quebrar uma chave em tempo util. E isto à uns bons tempos atrás. Imagina em que tipo de hw eles estão sentados atm. Hw que o publico em geral nunca vai ver mais gordo, mas que não tem hipoteses de não existir, ou não fossem eles o cumulo da paranoia...

    Quando eu disse keyspace/keysize não queria dizer que um bom algoritmo dependia disso, nem por sombras. Queria dizer que um bom algoritmo nessas condições passava de "possivel mesmo que só hipoteticamente" a "esquece, vamos tomar café..." ,)
     
  11. PrOdG

    PrOdG Power Member

    Presumo que estejas a falar do DES. E a redução nem foi assim tão pouca, o design original do Lucifer (o algoritmo que deu origem ao DES) utilizava chaves de 128b.
    A razão pela qual a NSA "aconselhou" a IBM a reduzir o tamanho das chaves é a mesma razão pela qual ainda hoje em dia é probido nos EUA utilizar comercialmente algoritmos com chaves maiores de 64b ou exportar algoritmos com chaves maiores de 40b: estas chaves são relativamente fáceis de quebrar e garantem que o Big Brother -- erm, o Patriot Act continue em funcionamento.

    No fundo, resume-se a isto. Imaginemos que temos algo que consegue percorrer um milhão de bilhões de bilhões de chaves por segundo para percorrer todo o keyspace de uma chave de 128b.
    Código:
    2^128 = 3.4 x 10^38 chaves para comparar
    10^30 chaves comparadas por segundo
    
    3.4 x 10^38 / 10^30 = 3.4 x 10^8 segundos para percorrer todo o keyspace
    3.4 x 10^8 segundos ~ 11 anos
    A diferença entre as nossas opiniões é que tu acreditas que existe tal poder computacional, eu sei que não existe nem há de existir nas próximas décadas.


    Em relação a este assunto, li há uns tempos um artigo escrito por alguém da PGP Company que fazia uma analogia engraçada:
     
  12. ShadeX

    ShadeX Power Member

    Si. O pobre Lucifer era uma ideia morta à nascença. Nunca o iam deixar existir. IIRC tinha um problema de vulnerabilidade descoberto mais tarde, mas naquela alltura para a NSA 128b devia ser o demo :) Rios, DES64 era o demo quanto mais...

    E não estas a querer insinuar que o Echelon ainda por ai anda pois não... É só más linguas... ;)

    Os teus cálculos estão correctos, o problema é que nem sempre as chaves são geradas da melhor maneira, aka por uma ferramenta feita para o efeito. Obvio que com uma tal tool e um bom RNG e um bom gerador de entropia isso se aplica. Mas e quando a chave é "man-made".

    Tens uma boa analogia com as passwords. Uma pass de 16c ocupa 128b mas não são 128b. Se assumires num primeiro ataque que não foram usados numeros/simbolos o teu keyspace ainda é mais reduzido.

    E ainda depende da complexidade do algoritmo e da velocidade de processamento dos dois membros da "transação". Pq disso depende quantas tentativas/s vais poder efectuar.

    Eu pela parte que me toca prefiro um bocado de paranóia "adiantada" que remendo tardio.

    Qqr modo, e entendendo a vertente de poupaça de energia já me dava por feliz que a auth e negociação de canal seguro fosse feita a 2048b e o resto a 128b. Pelo menos assim garantias que ninguem nos milénios mais próximos ia saber de nada :D

    Mas não vejo a acontecer. Raio, se os bancos e afins com tudo o que representam usam medidas que deixam a desejar, então o resto... E nisso não me lixem, o processamento/energia que se gastasse a subir o nível de segurança em termos de chaves era uma gota de água no oceano. Mas o povo nem um PIN de 4 digitos, quanto mais uma pass complexa...
     

Partilhar esta Página