Autenticação/Confidencialidade de SessãoA autenticação é uma questão fundamental quando duas entidades trocam dados entre sí (sessão). Em grande parte trata-se de um problema de distribuição de chaves. Como foi referido, uma implementação segura de distribuição de chaves obriga a:
Neste tipo de situação especifico pretende-se que seja gerada uma chave Ks (tipicamente de criptiografia convencional) que será usada apenas para a sessão a ser estabelecida, esta chave tem de ser distribuida pelas duas entidades participantes de sessão. Numa abordagem de criptografia convencional o esquema seguinte mostra-se seguro numa sessão A para B, baseia-se no facto de apenas o KDC conhecer as chaves secretas de A e B, a entidade KDC vai ter a responsabilidade de gerar a chave secreta para a sessão:
Numa abordagem de criptografia de chave publica é usado o esquema seguinte:
"Passwords"O estabelecimento de uma sessão entre um utilizador (aplicação cliente) e um sistema central (aplicação servidora) deve ser visto como qualquer outro tipo de sessão e recaindo por isso na abordagem anterior. Na prática corrente as medidas de validação e autenticação são contudo muito mais reduzidas. Geralmente a autenticação resume-se ao envio ao servidor de um conjunto (LOGIN-NAME + PASSWORD), onde "LOGIN-NAME" é o nome do utilizador em versão reduzida e de conhecimento mais ou menos público, e a "PASSWORD" é secreta, apenas do conhecimento do utilizador e do sistema, proporciona por isso autenticação do utilizador perante o sistema. Geralmente apenas se pratica a referida autenticação de clientes perante servidores, contudo num ambiente de rede pouco controlado não é complicado a um intruso simular um dado sistema central, podendo assim obter "password's" de utilizadores que nele tentam entrar. O facto de o sistema fornecer algum tipo de informação como por exemplo a data/hora do último "login" pode facilitar a detecção deste tipo de situações. Um solução que também se pode praticar é enviar uma "password" falsa e so depois a verdadeira. Frequentemente as "password's" são enviadas pela rede sem cifrar, situação apenas admissivel se existir um total controlo sobre a rede, que deverá sempre ser do tipo comutado. Como são digitadas pelos utilizadores em local público, podem ser obtidas por terceiros por simples observação. Ficheiros de "password's"Um outro problema deste mecanismo é a necessidade de o sistema armazenar as "password's" directa ou indirectamente sobre a forma de ficheiros, que além do risco próprio são depois replicados em "backup's". Neste aspecto a solução mais segura é usar um mecanismo de cifragem não reversivel, isto é apenas é possivel cifrar, decifrar é impossivel ("one-way encryption"). Quando o utilizador envia a "password" o sistema cifra-a e verifica se o resultado coincide com o que se encontra no ficheiro. Mesmo este mecanismo apresenta alguns problemas, pode por exemplo acontecer de dois utilizadores usarem a mesma "password", então o resultado cifrado seria o mesmo, o que não é admissivel. Nos sistemas Unix este problema é resolvido com o "salt", número de 12 bits composto pela hora e PID na altura em que a "password" é definida, o "salt" de cada utilizador é também armazenado pelo sistema e é sempre adicionado à "password" antes da cifragem. Gestão de "password's"Mesmo sendo elementar e porque envolve utilizadores existem vários cuidados básicos a ter com a autenticação por "password":
Os UtilizadoresO principal problema dos sistemas de autenticação de utilizadores por "password" são os próprios utilizadores. Um utilizador raramente está alertado para os aspectos de segurança, os seguintes comportamentos são mais ou menos vulgares:
Os utilizadores podem ser obrigados a alterar a sua "password" periodicamente, mas uma escolha sob pressão pode não ser boa ideia, por outro lado os utilizadores tentarão alternar entre duas "passwords". Para precaver esta última possibilidade alguns sistemas armazenam as n últimas "password´s" de cada utilizador, assim para voltar à "password" inicial terão de alterar a "password" n vezes. Para evitar este truque alguns sistemas apenas permitem a alteração da "password" uma vez em cada periodo, o que também tem inconvenientes. Gerar "password's" aleatórias que os utilizadores são obrigados a usar seria uma boa solução, mas devido à dificuldade em serem memorizadas existe uma forte tendência para as escrever algures. Existe "software" para "quebrar" "password's" que os administradores podem usar periodicamente, verificando assim a existencia de contas com "password" menos sólida. Contudo a melhor solução é realizar verificações na altura em que os utilizadores definem a "password". Autenticação com "password" protegidaQuando se procede à autenticação remota por "USERNAME/PASSWORD" a password circula pela rede sob forma legivel. Uma forma de resolver este problema é usar uma sessão em que todos os dados são cifrados, como foi visto no inicio deste documento existem mecanismos que permitem definir uma chave simétrica de sessão que é transmitida usando criptografia de chave pública. A confidencialidade de toda a sessão nem sempre é necessária. Muitas vezes, o único dado que necessita de ser mantido confidencial é a "password" do utilizador. Para atender a estas situações foram desenvolvidos mecanismos que garantem que a "password" não é transmitida pela rede, são conhecidos por autenticação com "password" protegida. A utilização de "USERNAME/PASSWORD" coloca-se normalmente num contexto cliente-servidor em que o cliente (utilizador) tem de se autenticar perante o serviço. O procedimento é o seguinte:
Este mecanismo simples garante uma elevada segurança, sendo impraticavel qualquer tentativa de obter a password na rede. Uma outra designação habitual para esta técnica é "passwords encriptadas", mas não se trata de uma verdadeira cifragem. O grande inconveniente desta técnica é a necessidade de o servidor dispor da "password" do utilizador já que tem de calcular HASH(PASSWORD+CODIGO) para comparar com o valor enviado pelo cliente. Por exemplo os sistemas Unix, por razões de segurança, não permitem dispor da "password" dos utilizadores. Pode-se dizer que este sistema aumenta a segurança das passwords na rede, mas diminui a segurança no servidor. A autenticação com "password" protegida pode ainda funcionar como mecanismo de distribuíção de chaves simétricas de sessão, prescindindo assim da criptografia de chave pública para esse efeito. Após autenticação tanto o servidor como o cliente conhecem algo que mais ninguem conhece, a "password" do utilizador. Sendo assim pode ser usado um algoritmo tipo HASH para gerar uma chave secreta apartir da "password", tanto o cliente como o servidor executam este algoritmo e vão obter exactamente a mesma chave que não é do conhecimento de mais ninguém. Não se trata exactamente de uma distribuíção de chaves, mas sim de uma geração em paralelo. Seja como for fica resolvido o problema da distribuição da chave de sessão sem recorrer a criptografia de chave pública. Como para qualquer mecanismo de geração de chaves é importante garantir que elas variam de sessão para sessão, ou seja é necessário introduzir um parâmetro que garanta chaves diferentes de sessão para sessão, mesmo que a "password" se mantenha, por exemplo gerar o chave a partir de "CODIGO+PASSWORD" em lugar da "password" apenas. Sessões sem encriptaçãoA autenticação de utilizadores por "password" não proporciona qualquer tipo de segurança após o estabelecimento da sessão, quando os dados não são cifrados, esta pode sofrer ataques passivos (monitorização) e pode também sofre ataques activos. Por ataque activo entenda-se aqui uma "aquisição" da sessão. A facilidade deste ataques a sessões não cifradas dependem em grande parte dos meios de transmissão e protocolos usados:
Num ambiente de rede o ataque activo a uma sessão não cifrada depara com algumas dificuldades: Nestes ambientes as sessões geralmente assentam sobre protocolos de transporte como o TCP que procedem à numeração dos dados para efeito de controlo de erros e de fluxo. Mesmo supondo que o cliente licito simplesmente desaparece, tomar o lugar desse cliente exige a simulação de uma conexão TCP, exactamente no mesmo estado. Terá ainda de se entrar em consideração com o protocolo de sessão/aplicação que também exige que o estado seja o mesmo do cliente licito. Por outro lado os protocolos de transporte, ou directamente os protocolos de sessão, assentam sobre níveis de rede que definem endereços de nó, isto significa que será necessário usar o mesmo endereço do nó lícito. Isto é práticamente impossível de conseguir a nível de Internet (devido ao "routing"). Numa rede local obrigaria a provocar algum tipo de bloqueio na máquina licita para de seguida tentar tomar o seu lugar. Note-se que numa rede local teria de ser simulado não só o endereço de rede (nível 3) como também o endereço físico (nível 2). |