É um dado adquirido que grande parte das aplicações multi-utilizador têm algum mecanismo de identificação. Na maior parte dos casos este mecanismo resume-se à identificação de um utilizador através de um identificador único e uma password. Geralmente o identificador único é um ‘username’, ou algo idêntico.
No entanto alguns programadores não levam em conta que a base de dados onde se armazenam as palavras-passe, podem ser consultadas com recurso a técnicas muito simples para obtenção de acesso não autorizado. Algumas dessas técnicas estão muito bem documentadas, e um programador menos experiente terá pouca dificuldade em as utilizar.
Disto isto, parece óbvio que a informação mais sensível deverá ser codificada, ou melhor ainda, ser armazenada com recurso a técnicas que permitam a identificação sem se guardar a palavra-chave original.
Mais uma vez, irei recorrer a um artigo para explicar este ponto de vista. Nele são apresentadas algumas técnicas, e é exemplificada a sua utilização com recurso a tecnologia da Oracle. No entanto as ideias apresentadas podem ser utilizadas em qualquer plataforma de desenvolvimento.
Acerca de mim
- Tiago Franco
- CEO, cosmopolita e com gosto pelo mercado de capitais. Sonha um dia viver em hotéis de 5 estrelas, mas ainda não descobriu como lá chegar. Tem um blogue com um 'look' giro mas comum, onde publica artigos de utilidade duvidosa.
9 comentários:
Por acaso pensei que era mais ou menos um dado adquirido, isso de guardar um resumo da pass, ou pelo manos guardá-la codificada... o que me intriga e me parece um acrescento à segurança é guardar tb o user codificado. Pq? Se um artista menos sério tiver acesso à BD e conseguir ver um username e o resumo da sua pass não precisa de mais nada porque o que se envia para a BD é o user e o resumo da pass... aqui é que é preciso algum cuidado porque tb n se podem ter só resumos na BD...
Logo: O que fazer com o user? ou a solução passa mais por manter a informação segura no canal entre a aplicação e a BD?
Existem duas situações distintas no teu comentário. A primeira trata-se da segurança no canal de comunicação, e a segunda refere-se à forma como os dados são guardados na base de dados.
Quanto à primeira situação, um canal de comunicação cifrado é sempre uma boa opção. Isto baixa consideravelmente a taxa de sucesso de um ataque do tipo “man in the middle”. Mas a ideia passa sempre por transmitir o username e a password no seu estado inicial, isto é, as funções de síntese (hash functions) devem ser sempre aplicadas no lado do servidor.
Se um intruso interceptar o username e a password de um utilizador pouco há a fazer, mesmo que se usem funções de sintese no servidor. No futuro o intruso pode facilmente fazer-se passar pela vitima do ataque.
A segunda situação visa apenas prevenir que um intruso tenha acesso às verdadeiras passwords dos utilizadores. A maioria das pessoas utiliza um número restrito de palavras-chave nas mais variadas aplicações, o que torna este tipo de informação muito sensível.
A vantagem das funções de síntese foca-se no facto de ser praticamente impossível obter os dados originais, por isso é que são geralmente referenciadas como “one way functions”.
O exemplo foca uma técnica utilizada exaustivamente nos sistemas Linux e Unix (pelo menos). Esta técnica consiste em concatenar o username com a password e utilizar o resumo desta nova ‘string’ como palavra-chave. Isto serve para criar entropia no resultado da função de síntese.
Espero que tenha sido elucidativo :)
Um abraço,
Gama Franco
sim, claro... perfeitamente de acordo. A questão, no entanto, é: porque é que não se usa uma sintese de cada lado? Isto é: Sintese da pass na aplicação(mesmo com "man in the middle" esse "man" só vai poder usar essa info aqui porque não consegue recriar a pass a partir da sintese) e depois sintese do user (ou [user]+[MD5[pass]]... como se queira) na BD (assim, mesmo acedendo à bd nunca será possível saber de quem se está a roubar a (sintese da) pass).
Não será esta uma solução simples e eficaz para mais do que 1 prob de segurança?
Vou apenas focar a situação de segurança no canal, visto que essa solução resolve o problema inicial. Pode-se considerar uma variante da solução descrita no artigo, com o cálculo de uma função de síntese adicional (no lado do cliente).
Para responder à tua pergunta vou deixar aqui um pequeno desafio :)
Vamos supor que no nosso problema temos três entidades distintas: a Alice, o Bob e a Susan.
A Alice vai identificar-se perante o Bob, e a Susan está à escuta no canal.
A Alice envia o seu nome de utilizador e a síntese da sua palavra-chave.
O Bob efectua os cálculos necessários e chega à conclusão que está perante a Alice.
A Susan interceptou a mensagem, e mais irá enganar o Bob fazendo-se passar por Alice.
A questão é, o que necessita a Susan de fazer para enganar o Bob?
Um abraço,
Gama Franco
Pronto, está bem, eu escrevo. Mas só porque tu pediste com jeitinho!
Já agora, precisas de fundos ou opiniões para aquilo-que-nós-sabemos? Diz coisas. Se não, até sexta!
Beijinhos!
Já agora, que raio faz a Alice no meio da Susan e do Bob? Que trio mais estranho... Onde é que os descobres?
E tu, ó Recursos Humanos, não devias estar a trabalhar? :p
Patrão fora...
;))
Aqui a "man" Susan n tem de fazer grande coisa a não ser reenviar a mensagem já que com este cenário nem sequer
existe controlo de mensagens repetidas.
Por outro lado, a solução para a segurança no canal: Chaves Públicas (eventualmente com sinteses pelo meio para
evitar o não repudio do envio.... mas isso é outra questão e vamos ficar pela segurança).
temos portanto:
Alice -[mensagem1]-> Susan -[mensagem2]-> Bob
em que todos conhecem a chave publica de todos os outros (é suposto ser publica....)
Para evitar que a Susan se faça passar por Alice pode então enviar a seguinte mensagem:
PuB(A, PrA(M, t, A), MD5(M, t, A)), que significa:
PrA(M, t, A) -- envio os dados M(mensagem), t(numero de sequencia) e A(identidade) codificados com a chave privada da Alice (que só ela conhece)
MD5(M, t, A) -- Sintese dos mesmos dados. Se alguem alterar alguma coisa pode verificar-se a sintese para confirmação.
PuB(A, ....) -- No fim codifico tudo com a chave publica do Bob e portanto só o Bob é que consegue descodificar estes dados com a sua chave privada. O Bob vai saber que foi mesmo a alice porque vai a sua identidade e porque só a Alice é que pode codificar coisas com qa sua chave privada e só as coisas criadas com a sua chave privada é que podem descodificadas com a sua chave publica....
Parece que a Susan vai ficar só a fazer "relay" das mensagens sem poder entender ou alterar nada daquilo que está a passar... :)
Que te parece?
Parece bem. Isto leva à conclusão que estar a enviar a síntese da password como tinhas proposto anteriormente é desnecessário. Basta enviar a palavra-chave e evitar o processamento adicional da síntese :p
Ps: Quanto áquilo que nós sabemos... quem é que pode passar pela FNAC?
Um abraço,
Gama Franco
Eu posso ir à Fnac amanhã à tarde. Depois combinamos melhor a minha missão. ;)
Um abraço,
Cepeda Alves
Enviar um comentário