Quando se trata da declaração passwd/user-password-crypted em um arquivo preseed, a maioria dos exemplos usa um hash MD5. Exemplo:
# Normal user's password, either in clear text #d-i passwd/user-password password insecure #d-i passwd/user-password-again password insecure # or encrypted using an MD5 hash. #d-i passwd/user-password-crypted password [MD5 hash]
De Apêndice B. do Debian Automatizando a instalação usando pré-configuração .
Algumas fontes mostram que também é possível usar o SHA-512:
Try using a hashed password like this:
$ mkpasswd -m sha-512[...]
And then in your preseed file:
d-i passwd/user-password-crypted password $6$ONf5M3F1u$bpljc9f1SPy1w4J2br[...]
De Não é possível automatizar a criação de usuários com pré-configuração no AskUbuntu .
Isto é um pouco melhor que o MD5, mas ainda não resiste bem contra as tabelas de força bruta e arco-íris.
Que outros algoritmos posso usar? Por exemplo, é suportado PBKDF2, ou eu estou limitado pelos algoritmos utilizados em /etc/shadow , que é MD5, Blowfish, SHA- 256 e SHA-512 ?
Eu acho que você pode usar qualquer coisa que seja suportada no arquivo / etc / shadow. A string dada no arquivo preseed é apenas colocada em / etc / shadow. Para criar uma senha salgada para tornar mais difícil, basta usar o mkpasswd com a opção salt (-S):
mkpasswd -m sha-512 -S $(pwgen -yns 16 1) mypassword
$6$bLyz7jpb8S8gOpkV$FkQSm9YZt6SaMQM7LPhjJw6DFF7uXW.3HDQO.H/HxB83AnFuOCBRhgCK9EkdjtG0AWduRcnc0fI/39BjmL8Ee1
No comando acima, o sal é gerado por pwgen .
Olhando a parte apropriada da fonte debian-installer
código nós
pode ver que ele simplesmente chama usermod USER --password=CRYPTED-PASSWORD dentro
o alvo chroot.
Além disso, a manpage de usermod sugere que a opção --password aceite "The
senha criptografada, conforme retornado por crypt (3). "e que" A senha será
escrito no arquivo local / etc / passwd ou / etc / shadow. ". Isso sugere que podemos
use somente os formatos de senha criptografados descritos na página crypt(3) man.
Toda a esperança não está perdida no entanto. Da página man acima mencionada, aprendemos que
crypt na verdade inclui um campo salt na string de senha criptografada, o formato
sendo $hash_id$salt$hash . Portanto, pelo menos em princípio, ele deve ser resistente a tabelas de arco-íris.
Além dos ataques de arco-íris, ainda temos que considerar ataques de força bruta. Se analisarmos a implementação da glibc de
crypt
vemos que, na verdade, implementa o alongamento de senhas usando várias rodadas de
SHA-512 não totalmente ao contrário, mas, infelizmente, não usando uma abordagem padrão, como
PBKDF2.
Além disso, vemos que podemos controlar o número de rodadas de hash
aplicado por crypt usando um campo adicional na senha criptografada
(%código%). Olhando para a página $rounds=$ man, vemos isso exposto como o
mkpasswd(1) opção. Usando esse recurso, podemos aumentar significativamente o número padrão de
rodadas de 5000 (veja -R no código fonte) que na minha máquina
leva menos de um par de milissegundos para calcular, digamos, 10 milhões que
leva alguns segundos:
> mkpasswd -R 10000000 -m sha-512 mypassword
$6$rounds=10000000$Rq30Hdd.0LzWq3x$XRXHvd5MnIi5MD2H8Jtn5W0cjvq4siGtUgWUaETc4QZyvuR4iY0Af.DoNfj1E6SvoHaVotAEjIiOPS3GvwJjM0
As tabelas do arco-íris e a força bruta não são relevantes aqui.
A senha do sha-512 é salgada. Isso significa que, para qualquer hash que você tenha, a senha começa com um valor salt (ONf5M3F1u, neste caso). Para gerar uma tabela de arco-íris, você deve gerar uma lista completa de hashes do sha-512 para todas as cadeias tipáveis começando com "ONf5M3F1u".
Digamos que você tenha usado o algoritmo de hash teórico "CSUM-2", que simplesmente adiciona os caracteres e produz um hash de 2 bits dos bits menos significativos. Uma tabela de arco-íris para o CSUM-2 é semelhante à abaixo:
0 d
1 a
2 b
3 c
Note que apenas os dois LSB são relevantes, então você realmente tem quatro sais: d, a, b e c.
Então imagine estes quatro hashes da senha 'b', com sais. O sal prepends, então você hash por exemplo "db" para obter apenas "b" ou "ab" para obter "c".
$-1$d$b
$-1$a$c
$-1$b$d
$-1$c$a
Para usar uma tabela de arco-íris para quebrar o CSUM-2, você precisa de quatro tabelas de arco-íris separadas de quatro entradas cada.
Para decifrar o sha-512 com um sal de nove caracteres como acima, você precisa de 62 tabelas completas de arco-íris. Uma tabela de arco-íris sha-512 suficiente para até 9 caracteres alfanuméricos tem 864 GB de tamanho; com este tipo de salga, você precisa de 62 desses, ou 52TB de tabelas.
Note que 2 ^ 512 é muito mais do que apenas senhas de 9 caracteres podem fornecer. Existem 1,3 x 10 ^ 154 hashes e 1,35 x 10 ^ 19 senhas alfanuméricas de 9 caracteres. Senhas mais longas significam um espaço de senha maior, mais entradas e tabelas maiores. Isso se multiplica linearmente pelo número de sais e exponencialmente pelo comprimento do sal.
Alguém precisa gerar e armazenar todas essas tabelas.
O PBKDF2 simplesmente executa o cálculo várias vezes; no entanto, uma saída PBKDF2 será sempre a mesma, e você estará de volta às tabelas rainbow quebrando o PBKDF2 como qualquer outro algoritmo.
O PAM pode usar o parâmetro rounds para executar o alongamento de teclas também; o padrão é 5.000 e o mínimo é 1.000. rounds=65536 executaria o SHA-512 2 ^ 16 vezes em cada tentativa de login. Isso faria com que a força bruta fosse mais lenta, embora uma mesa de arco-íris pré-computada ainda não se importe. Construir e armazenar essa mesa de arco-íris é, como dito acima, difícil.