Mecanismo de autenticação de resposta de desafio salgado - Salted Challenge Response Authentication Mechanism

Na criptografia, o Salted Challenge Response Authentication Mechanism ( SCRAM ) é uma família de modernos mecanismos de autenticação de desafio-resposta baseados em senha que fornecem autenticação de um usuário a um servidor. Como é especificado para Simple Authentication and Security Layer (SASL), pode ser usado para logins baseados em senha para serviços como SMTP e IMAP ( e-mail ) ou XMPP (chat). Para XMPP, o suporte é obrigatório.

Motivação

Alice deseja fazer login no servidor de Bob. Ela precisa provar que é quem afirma ser. Para resolver esse problema de autenticação, Alice e Bob concordaram com uma senha, que Alice conhece e que Bob sabe como verificar.

Agora Alice poderia enviar sua senha por meio de uma conexão não criptografada para Bob em um formato de texto não criptografado, para ele verificar. Isso, no entanto, tornaria a senha acessível a Mallory, que está escutando a linha. Alice e Bob podem tentar contornar isso criptografando a conexão. No entanto, Alice não sabe se a criptografia foi configurada por Bob e não por Mallory ao fazer um ataque man-in-the-middle . Portanto, Alice envia uma versão em hash de sua senha, como em CRAM-MD5 ou DIGEST-MD5 . Por ser um hash, Mallory não consegue a senha por conta própria. E como o hash é temperado com um desafio, Mallory poderia usá-lo apenas para um processo de login. No entanto, Alice deseja fornecer algumas informações confidenciais a Bob e quer ter certeza de que é Bob e não Mallory.

Para resolver isso, Bob registrou-se em uma autoridade de certificação (CA), que assinou seu certificado. Alice só poderia contar com esse sistema de assinatura, mas ela sabe que ele tem pontos fracos . Para dar a ela uma garantia adicional de que não há ataque man-in-the-middle, Bob cria uma prova de que ele conhece a senha (ou um hash salgado) e inclui seu certificado nessa prova. Essa inclusão é chamada de vinculação de canal, pois o canal de criptografia inferior é 'vinculado' ao canal de aplicativo superior.

Alice então tem uma autenticação de Bob e Bob tem uma autenticação de Alice. Juntos, eles têm autenticação mútua . O DIGEST-MD5 já habilitou a autenticação mútua, mas muitas vezes foi implementado incorretamente.

Quando Mallory executa um ataque man-in-the-middle e forja uma assinatura de CA, ela pode recuperar um hash da senha. Mas ela não conseguiu personificar Alice nem mesmo para uma única sessão de login, pois Alice incluiu em seu hash a chave de criptografia de Mallory, resultando em uma falha de login de Bob. Para fazer um ataque totalmente transparente, Mallory precisaria saber a senha usada por Alice ou a chave secreta de criptografia de Bob.

Bob ouviu falar de violações de dados de bancos de dados de servidor e decidiu que não deseja armazenar as senhas de seus usuários em texto não criptografado. Ele já ouviu falar dos esquemas de login CRAM-MD5 e DIGEST-MD5, mas sabe que, para oferecer esses esquemas de login a seus usuários, ele teria que armazenar senhas com hash fraco e sem sal. Ele não gosta da ideia e, portanto, opta por exigir as senhas em texto simples. Em seguida, ele pode hash-los com esquemas de hash seguros como bcrypt , scrypt ou PBKDF2 e salgá- los como quiser. No entanto, Bob e Alice ainda enfrentariam os problemas descritos acima. Para resolver esse problema, eles usam SCRAM, onde Bob pode armazenar sua senha em formato salgado, usando PBKDF2. Durante o login, Bob envia a Alice seu salt e a contagem de iteração do algoritmo PBKDF2 e, em seguida, Alice os usa para calcular a senha com hash que Bob tem em seu banco de dados. Todos os cálculos posteriores no SCRAM baseiam-se neste valor que ambos conhecem.

Visão geral do protocolo

Embora todos os clientes e servidores tenham que suportar o algoritmo de hashing SHA-1 , o SCRAM é, ao contrário do CRAM-MD5 ou DIGEST-MD5 , independente da função hash subjacente. Todas as funções hash definidas pela IANA podem ser usadas em seu lugar. Conforme mencionado na seção Motivação, o SCRAM usa o mecanismo PBKDF2 , que aumenta a força contra ataques de força bruta , quando ocorre um vazamento de dados no servidor. Seja Ha função hash selecionada, dada pelo nome do algoritmo anunciado pelo servidor e escolhido pelo cliente. 'SCRAM-SHA-1' por exemplo, usa SHA-1 como função hash.

Chave derivada baseada em senha ou senha salted

O cliente deriva uma chave, ou senha com salt, a partir da senha, um salt e uma série de iterações computacionais da seguinte maneira:

SaltedPassword = Hi(password, salt, iteration-count) = PBKDF2(HMAC, password, salt, iteration-count, output length of H).

Mensagens

O RFC 5802 nomeia quatro mensagens consecutivas entre o servidor e o cliente:

cliente primeiro
A mensagem cliente primeiro consiste em um cabeçalho GS2 (compreendendo um sinalizador de vinculação de canal e um nome opcional para informações de autorização), o desejado usernamee um nonce cliente gerado aleatoriamente c-nonce.
servidor primeiro
O servidor anexa a esse cliente nonce seu próprio nonce s-noncee o adiciona à mensagem do servidor primeiro , que também contém um saltusado pelo servidor para salting o hash de senha do usuário e uma contagem de iteração iteration-count.
cliente final
Depois disso, o cliente envia a mensagem final do cliente contendo a vinculação de canal , o cabeçalho GS2 e os dados de vinculação de canal codificados em base64, a concatenação do cliente e do servidor nonce e a prova do cliente proof.
final do servidor
A comunicação é encerrada com a mensagem final do servidor , que contém a assinatura do servidor verifier.

Provas

O cliente e o servidor provam um ao outro que possuem a mesma Authvariável, consistindo em:

Auth = client-first-without-header + , + server-first + , + client-final-without-proof (concatenado com vírgulas)

Mais concretamente, assume a forma:

= r=c‑nonce,[extensions,]r=c‑nonce‖s‑nonce,s=salt,i=iteration‑count,[extensions,]c=base64(channel‑flag,[a=authzid],channel‑binding),r=c‑nonce‖s‑nonce[,extensions]

As provas são calculadas da seguinte forma:

ClientKey = HMAC(SaltedPassword, 'Client Key')
ServerKey = HMAC(SaltedPassword, 'Server Key')
ClientProof = p = ClientKey XOR HMAC(H(ClientKey), Auth)
ServerSignature = v = HMAC(ServerKey, Auth)

onde a operação XOR é aplicada a cadeias de bytes do mesmo comprimento, é um hash normal de . e são strings textuais. H(ClientKey)ClientKey'Client Key''Server Key'

O servidor pode autorizar o cliente através do cálculo ClientKeyde ClientProofe em seguida, comparando H(ClientKey)com o valor armazenado.

O cliente pode autorizar o servidor computando e comparando ServerSignaturediretamente.

Senha armazenada

Apenas o servidor armazena o nome de usuário, salt, iteration-count, , . O servidor tem acesso temporário à medida que é recuperado da prova do cliente, tendo sido criptografado com . H(ClientKey)ServerKeyClientKeyH(ClientKey)

O cliente precisa apenas do password.

Vinculação de canal

O termo vinculação de canal descreve a estratégia de prevenção de ataque man-in-the-middle para 'vincular' uma camada de aplicativo , que fornece autenticação mútua, a uma camada inferior (principalmente criptografia), garantindo que os pontos de extremidade de uma conexão sejam os mesmos em ambos camadas. Existem duas direções gerais para vinculação de canal: vinculação de canal exclusivo e terminal . O primeiro garante que uma conexão específica seja usada, o segundo que os terminais sejam os mesmos.

Existem vários tipos de vinculação de canal, em que cada tipo possui um prefixo exclusivo de vinculação de canal . Cada tipo de vinculação de canal especifica o conteúdo dos dados de vinculação de canal , que fornecem informações exclusivas sobre o canal e os terminais. Por exemplo, para a ligação do canal do ponto de extremidade do servidor tls , é o certificado TLS do servidor.

Um exemplo de caso de uso de canal binding com SCRAM como camada de aplicação, poderia ser com Transport Layer Security (TLS) como camada inferior. O TLS protege contra espionagem passiva, pois a comunicação é criptografada. No entanto, se o cliente não autenticar o servidor (por exemplo, verificando o certificado do servidor), isso não impede ataques man-in-the-middle. Para isso, os terminais precisam garantir suas identidades entre si, o que pode ser fornecido pelo SCRAM.

A variável SCRAM gs2-cbind-flag especifica se o cliente suporta ligação de canal ou não, ou pensa que o servidor não suporta ligação de canal, e c-bind-input contém o sinalizador gs2-cbind junto com o prefixo único de ligação de canal e os próprios dados de ligação do canal .

A vinculação de canal é opcional no SCRAM, e a variável gs2-cbind-flag evita ataques de downgrade .

Quando um servidor suporta associação de canal, ele adiciona a sequência de caracteres '-PLUS' ao nome do algoritmo SCRAM anunciado.

Forças

  • Armazenamento de senhas fortes: quando implementado de maneira correta, o servidor pode armazenar as senhas em um formato hash com sal e iterado, tornando mais difíceis os ataques offline e diminuindo o impacto das violações do banco de dados.
  • Simplicidade: Implementar SCRAM é mais fácil do que DIGEST-MD5.
  • Interoperabilidade internacional: o RFC requer que o UTF-8 seja usado para nomes de usuários e senhas, ao contrário do CRAM-MD5.
  • Como apenas a versão com sal e hash de uma senha é usada em todo o processo de login, e o sal no servidor não muda, um cliente que armazena senhas pode armazenar as versões com hash e não expor a senha em texto não criptografado aos invasores. Essas versões em hash são vinculadas a um servidor, o que torna isso útil na reutilização de senhas.

Referências

links externos