|
Sal (criptografia)
Em criptografia, sal (salt em inglês) é um dado aleatório que é usado como uma entrada adicional para uma função unidirecional que "quebra" os dados, uma senha ou frase-passe. Os sais são usados para proteger as senhas no armazenamento. Historicamente, uma senha era armazenada em texto simples em um sistema, mas com o tempo, salvaguardas adicionais foram desenvolvidas para proteger a senha de um usuário contra a leitura pelo sistema. O sal é um desses métodos. Um novo sal é gerado aleatoriamente para cada senha. Em uma configuração típica, o sal e a senha (ou sua versão após o alongamento de chave) são concatenados e processados com uma função hash criptográfica e a saída resultante (mas não a senha original) é armazenada com o sal em um banco de dados. O hash permite a autenticação posterior sem manter, e, portanto, pôr em risco, a senha em texto puro, caso o armazenamento de dados de autenticação seja comprometido. Sais permitem defender-se contra ataques de dicionário ou contra seu equivalente em hash, um ataque pré-computado de tabela arco-íris.[1] Como os sais não precisam ser memorizados por humanos, eles podem tornar o tamanho da tabela arco-íris necessário para um ataque bem-sucedido, proibitivamente grande sem sobrecarregar os usuários. Como os sais são diferentes em cada caso, eles também protegem as senhas comumente usadas ou os usuários que usam a mesma senha em vários sites, tornando todas as instâncias hash "salgadas" para a mesma senha, diferentes umas das outras. Sais criptográficos são amplamente usados em muitos sistemas de computadores modernos, desde credenciais do sistema Unix até segurança na Internet. Os sais estão intimamente relacionados ao conceito de um nonce criptográfico. Implementações em UnixVersões anteriores do Unix usavam um gerenciador de senhas ( Versões anteriores do Unix eram limitadas a senhas de 8 caracteres e usavam um sal com 12 bits, o que permitia alcançar 4.096 valores de sais possíveis. Enquanto 12 bits eram o suficiente para 1970s, mas em 2005 o armazenamento em disco tornou-se tão barato que um atacante poderia pré-computar os hashs de milhares de senhas comuns, incluindo todas as suas 4.096 possíveis variações quando concatenadas com o sal, e guardar estes valores em um único disco rígido. Um atacante com mais orçamento poderia guardar os valores pré-computados de todas as senhas com 6 caracteres e as senhas mais comuns com 7 e 8 caracteres, incluindo todas as suas 4.096 variantes com sal. Exemplo práticoA listagem a seguir demonstra usuários e respectivas senhas que não são armazenadas no banco de dados, apenas sendo usadas para a autenticação.
A partir dessa técnica, mesmo que os dados do banco de dados estejam comprometidos quanto ao sigilo, o atacante não tem a senha revelada porque há apenas um hash guardado, uma vez que ele é apenas calculado pela aplicação em tempo de autenticação do usuário. Implementações em aplicações de WebÉ comum uma aplicação de web armazenar em um banco de dados os valores de hash das senhas dos usuários. Sem um sal, um ataque bem sucedido de Injeção de SQL poderia acontecer facilmente, quebrando a segurança e integridade do banco de dados. Além disto, muitos usuários reutilizam suas senhas em múltiplos sites, então o uso do sal torna-se um importante componente geral de segurança de aplicações para Web. Afinal, cada aplicação terá gerado seu próprio sal, resultando em um hash diferente para a mesma senha. BenefíciosO sal, mesmo público, torna mais demorado quebrar uma lista de senhas. No entanto, isto não acontece quando um ataque de dicionário é executado em uma única senha. O atacante tem acesso a ambas as informações, senha e sal, então enquanto roda o ataque de dicionário, o atacante simplesmente pode usar o sal conhecido enquanto tenta quebrar a senha. Para entender a diferença entre quebrar uma única senha e um conjunto delas, considere um único arquivo de senhas que contenha centenas de nomes de usuários e senhas. Sem o sal, um atacante pode computar hash(tentativa_dicionario[0]) e então checar se este hash aparece em algum lugar do arquivo. A probabilidade de uma correspondência aumenta proporcionalmente ao número de senhas do arquivo. Se o sal está presente, então o atacante terá que computar hash(sal[a] . tentativa_dicionario[0]), onde "." significa concatenação, comparar com a entrada A, e então computar hash(salt[b] . tentativa_dicionario[0]), comparar com entrada B, e assim por diante. Isto derrota a reutilização de hash na tentativa de quebrar múltiplas senhas. Sais também combatem o uso de rainbow tables para quebrar senhas. Uma rainbow table é uma longa lista de hashes pré-computadas para as senhas mais comumente usadas. Para um gerenciador de senhas sem sal, um atacante pode ir através de cada entrada e verificar se ela corresponde com algum valor na tabela. Se a verificação for consideravelmente mais rápida que a função de hash (o que geralmente é), isto irá aumentar consideravelmente o tempo de quebra do gerenciador. No entanto, se o gerenciador de senhas utilizar sal, então a rainbow table terá de conter o hash pré-computado de "sal . senha". Se o sal for o suficientemente longo e o randômico, isto é muito improvável de ser feito. Senhas sem sal escolhidas por humanos tendem a ser vulneráveis a ataques de dicionário uma vez que eles precisam ser pequenas e claras o suficiente para serem memorizadas. Mesmo um pequeno dicionário (ou seus hashs equivalentes, uma rainbow table) tem chances grandes de quebrar as senhas mais comumente usadas. Devido aos sais não terem de ser memorizados por humanos, eles podem fazer com que o tamanho da rainbow table seja alto o suficiente para se tornar proibitivo sem ter que fazer o usuário da senha ter mais trabalho. Mais tecnicamente, sais protegem contra rainbow tables porque eles, na prática, estendem exponencialmente a complexidade da senha. Se a rainbow table não tem senhas compatíveis com o tamanho (i.e. uma senha de 8-bytes com um sal de 2 bytes é, efetivamente, uma senha de 10 bytes) e com a complexidade (incluir caracteres não alfanuméricos aumentam a complexidade da senha) da senha com sal, então esta senha não será encontrada. Se for encontrada, então alguém terá que tirar o sal da senha antes que ele possa ser usado, até que o usuário entre novamente com sua senha e um novo sal possa ser gerado. Benefícios adicionaisO moderno sistema shadow password, no qual o hash da senha e outros dados de segurança são guardados em um arquivo não público, de alguma forma atenua estas preocupações. No entanto, elas ainda continuam sendo relevantes em instalações multi-servidor onde usa-se uma senha central para ativar um gerenciador de senhas para ter acesso a senhas ou hashes de senhas para múltiplos sistemas. Nestas instalações, as contas raiz de cada sistema individual podem ser tratadas como menos confiáveis do que os administradores do sistema de senhas centralizada, então continua sendo útil garantir a segurança através de um algoritmo de hash de senhas, incluindo a geração de valores exclusivos de sais. [carece de fontes?] Sais também fazem ataques de dicionário e ataques de força bruta para quebrar um grande número de senhas vagarosos (mas não no caso de apenas uma senha). Sem sal, um atacante que está tentando quebrar muitas senhas ao mesmo tempo precisa apenas usar hash em um palpite de senha, e compará-lo com todos os outros. No entanto, com sal, cada senha provavelmente terá um sal diferente, o que torna consideravelmente mais devagar do que apenas comparar. Outro benefício (menor) do sal segue: dois usuários podem escolher a mesma string para suas senhas, ou um mesmo usuário pode escolher usar a mesma senha em duas máquinas diferentes. Sem sal, a senha seria armazenada como a mesma hash de string no gerenciador de senhas. Se for divulgado que ambas as contas tem a mesma senha, isto permite que qualquer pessoa que conheça uma das senhas tenha acesso a outra conta. Salgando as senhas com caracteres aleatórios, mesmo se as duas contas usarem a mesma senha, ninguém poderá descobrir isto olhando apenas para o gerenciador de senhas, já que todas as entradas irão tender a ser diferentes devido ao fator de aleatoriedade. Referências
Ligações externas
|
