Slack admite ter vazado senhas com hash por três meses

A popular ferramenta de colaboração Slack (não deve ser confundida com o apelido da distribuição Linux mais antiga do mundo, Slackware) acaba de assumir um SNAFU de segurança cibernética.

De acordo com um boletim de notícias intitulado Aviso sobre redefinições de senha do Slack, a empresa admitiu que estava inadvertidamente compartilhando dados pessoais em excesso “quando os usuários criaram ou revogaram um link de convite compartilhado para seu workspace.”

De 2022/04/17 a 2022/07/17 (assumimos que ambas as datas são inclusivas), o Slack disse que os dados enviados aos destinatários desses convites incluíam…

…espere por isso…

…a senha com hash do remetente.

O que deu errado?

O aviso de segurança do Slack não explica a violação com muita clareza, dizendo apenas que “[esta] senha com hash não era visível para nenhum cliente do Slack; descobrir isso exigia monitorar ativamente o tráfego de rede criptografado vindo dos servidores do Slack.”

Estamos supondo que isso se traduz da seguinte forma:

“A maioria dos destinatários não teria percebido que os dados recebidos incluíam qualquer informação de senha com hash, porque essa informação, embora incluída nos pacotes de rede enviados, nunca foi exibida deliberadamente para eles. E como os dados foram enviados por uma conexão TLS, os bisbilhoteiros não conseguiriam farejá-los ao longo do caminho, porque não seriam descriptografados até chegarem ao outro lado da conexão.”

Essa é a boa notícia.

Mas os pacotes de rede geralmente incluem dados que normalmente nunca são usados ​​ou vistos pelos destinatários.

Os cabeçalhos HTTP são um bom exemplo disso, pois são instruções para o seu navegador, não dados para exibição na página da Web que você está visualizando.

E os dados irrelevantes ou invisíveis para os usuários geralmente acabam em logs de qualquer maneira, especialmente em logs de firewall, onde podem ser preservados indefinidamente.

Essa é a má notícia.

Sal, haxixe e estiramento…

De acordo com o Slack, os dados vazados não foram meramente hash, mas salgado também, o que significa que a senha de cada usuário foi primeiro misturada com dados aleatórios exclusivos para esse usuário antes que a função de hash fosse aplicada.

Hashes são essencialmente funções matemáticas “não reversíveis” que são fáceis de calcular em uma direção, mas não na outra.

Por exemplo, é fácil calcular que:

  SHA256("DUCK") = 7FB376..DEAD4B3AF008

Mas a única maneira de trabalhar “para trás” de 7FB376..DEAD4B3AF008 para DUCK é trabalhar encaminha de todas as palavras possíveis no dicionário e veja se alguma delas sai com o valor que você está tentando corresponder:

  SHA256("AARDVARK") = 5A9394..467731D0526A [X] SHA256("AARON") = C4DDDE..12E4CFE7B4FD [X] SHA256("ABACUS") = BEDDD8..1FE4DE25AAD7 [X] . . . 3400 ignorado SHA256("BABBLE") = 70E837..CEAD4B1FA777 [X] SHA256("BADGER") = 946D0D..7B3073C1C094 [X] SHA256("BAGPIPE") = 359DBE..BE193FCCB111 [X] . . . 3200 ignorado SHA256("CABAL") = D78CF4..85BE02967565 [X] SHA256("CACHE") = C118F9..22F3269E7B32 [X] SHA256("CAGOULE") = 5EA530..5A26C5B56DCF [X] . . . 5400 ignorado SHA256("DAB") = BBCC8E..E8B98CAB5128 [X] SHA256("DAFFODIL") = 75121D..D6401AB24A98 [X] SHA256("PERIGO") = 0BD727..4C86037BB065 [X] . . . 3500 ignorados SHA256("PATO") =  7FB376..DEAD4B3AF008 [ENCONTRADO!]

E ao incluir um sal por usuário, que não precisa ser secreto, apenas exclusivo para cada usuário, você garante que, mesmo que dois usuários escolham a mesma senha, eles não terão o mesmo hash de senha.

Você pode ver o efeito da salga aqui, quando usamos o hash da palavra DUCK com três prefixos diferentes:

  SHA256("RANDOM1-DUCK") = E355DB..349E669BB9A2 SHA256("RANDOM2-DUCK") = 13D538..FEA0DC6DBB5C <-- Alterar apenas um byte de entrada produz um hash totalmente diferente SHA256("ARXXQ3H-DUCK") = 52AD92. .544208A19449

Isso também significa que os invasores não podem criar uma lista pré-computada de hashes prováveis ​​ou criar uma tabela de cálculos parciais de hash, conhecida como mesa arco-íris, que pode acelerar a verificação de hash. (Eles precisariam de uma nova hashlist, ou um conjunto exclusivo de tabelas de arco-íris, para cada sal possível.)

Em outras palavras, senhas com hash e salt não podem ser quebradas trivialmente para recuperar a entrada original, especialmente se a senha original for complexa e escolhida aleatoriamente.

O que o Slack não disse é se eles esticada os hashes de senha também e, em caso afirmativo, como.

Alongamento é um jargão que significa repetir o processo de hash de senha repetidamente, por exemplo, 100,000 vezes, para estender o tempo necessário para testar um monte de palavras do dicionário contra hashes de senha conhecidos.

Se levar um segundo para colocar 100,000 palavras do dicionário em um processo simples de salt-and-hash, os invasores que conhecem seu hash de senha podem tentar 6 milhões de palavras e derivações de dicionário diferentes a cada minuto ou levar mais de um bilhão de palpites a cada três horas .

Por outro lado, se os cálculos de sal e hash fossem estendidos para levar um segundo cada, o atraso extra de um segundo quando você tentasse fazer login causaria pouco ou nenhum aborrecimento para você…

…mas reduziria um invasor a apenas 3600 tentativas por hora, tornando muito menos provável que eles tivessem tempo suficiente para adivinhar qualquer coisa, exceto as senhas mais óbvias.

Vários algoritmos de salt-hash-and-stretch são conhecidos, notavelmente PBKDF2, bcrypt, scrypt e Argon2, todos os quais podem ser ajustados para aumentar o tempo necessário para tentar adivinhar senhas individuais para reduzir a viabilidade dos chamados ataques de dicionário e de força bruta.

A ataque de dicionário significa que você está tentando apenas senhas prováveis, como todas as palavras que você pode pensar aardvark para zymurgy, e depois desistir. UMA ataque de força bruta significa tentar todas as entradas possíveis, mesmo as estranhas e impronunciáveis, de AAA..AAAA para ZZZ..ZZZZ (ou de 0000..000000 para FFFF..FFFFFF se você pensar em termos hexadecimais byte por byte).

O que fazer?

Slack diz isso sobre 1 em 200 de seus usuários (0.5%, presumivelmente com base em registros de quantos links de convite compartilhados foram gerados no período de perigo), e que isso forçará esses usuários a redefinir suas senhas.

Mais alguns conselhos:

• Se você for um usuário do Slack, poderá redefinir sua senha mesmo que não tenha sido notificado pela empresa para fazê-lo. Quando uma empresa admite que foi descuidada com seu banco de dados de senhas ao vazar hashes, você pode também presumir que o seu banco de dados foi afetado, mesmo que a empresa pense que não. Assim que você altera sua senha, você torna o hash antigo inútil para os invasores.
• Se você não estiver usando um gerenciador de senhas, considere obter um. Um gerenciador de senhas ajuda a escolha senhas adequadas, garantindo assim que sua senha acabe muito, muito abaixo na lista de senhas que podem ser quebradas em um incidente como esse. Os invasores normalmente não podem fazer um verdadeiro ataque de força bruta, porque há muitas senhas possíveis para experimentar. Assim, eles tentam primeiro as senhas mais prováveis, como palavras ou combinações óbvias de palavras e números, ficando mais longas e complexas à medida que o ataque prossegue. Um gerenciador de senhas pode lembrar uma senha aleatória de 20 caracteres com a mesma facilidade com que você lembra o nome do seu gato.
• Ative o 2FA, se puder. 2FA, ou autenticação de dois fatores, significa que você precisa não apenas de sua senha para fazer login, mas também de um código de uso único que muda sempre. Esses códigos são normalmente enviados para (ou gerados por) seu telefone celular e são válidos apenas por alguns minutos cada. Isso significa que, mesmo que os cibercriminosos quebrem sua senha, não basta que eles assumam sua conta.
• Escolha um algoritmo salt-hash-and-stretch respeitável ao lidar com senhas você mesmo.. No caso infeliz de que seu banco de dados de senhas seja violado, você poderá fornecer a seus clientes detalhes precisos do algoritmo e das configurações de segurança usadas. Isso ajudará os usuários bem informados a julgar por si mesmos a probabilidade de seus hashes roubados terem sido quebrados no tempo disponível para os invasores até agora.

---