Sal (criptografia)

Origem: Wikipédia, a enciclopédia livre.
Ir para: navegação, pesquisa
Ambox important.svg
Foram assinalados vários aspectos a serem melhorados nesta página ou se(c)ção:

Em criptografia, sal é um dado aleatório que é usado como uma entrada adicional junto a uma senha ou algo semelhante em uma "função de mão única", que gera como saída um hash. A função primária do sal é defender contra ataques de dicionário aliados a aplicação da função hash nesta lista (já que a função hash é conhecida segundo os principios de Kerckhoffs) e contra ataques pré-computados como rainbow table.

Um novo sal é gerado aleatoriamente para cada senha. Em uma configuração típica, o sal e a senha são concatenados e processados com uma função de hash criptográfica, então apenas o resultado e o sal são guardados no banco de dados. O hash permitirá futuras autenticações, como também protege a senha purotexto em situações em que o banco de dados pode estar comprometido. Afinal, apenas o usuário saberá a senha purotexto e o hash poderá ser recalculado com o sal guardado, e o resultado garantirá a integridade do banco de dados.

Sais criptográficos são amplamente usados em muitos sistemas modernos de computadores, desde sistemas Unix até segurança de internet.

Implementações em Unix[editar | editar código-fonte]

Versões anteriores do Unix usavam um gerenciador de senhas (/etc/passwd) que guarda os hashes "salgados" das senhas (na prática, senhas com dois caracteres de sal pré-definidos randomicamente.) Nestas versões anteriores do Unix, o sal também era guardado no gerenciador (como um purotexto) junto com o hash da senha salgada. O gerenciador de senhas era legível para todos os usuários do sistema. Isto era necessário para que ferramentas de software privilegiados executados pelo usuário pudessem achar nomes de usuários e outras informações. A segurança das senhas é, portanto, garantida apenas pela função de mão-única (seja de encriptação ou de hash) usadas para este propósito.

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.

Implementações em aplicações de Web[editar | editar código-fonte]

É comum uma aplicação de web armazenar em umbanco 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ícios[editar | editar código-fonte]

O 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 adicionais[editar | editar código-fonte]

O 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.

Ligações externas[editar | editar código-fonte]