Curso MIT "Segurança de sistemas de computadores". Aula 17: Autenticação de Usuário, Parte 1

Instituto de Tecnologia de Massachusetts. Curso de Aula nº 6.858. "Segurança de sistemas de computador". Nikolai Zeldovich, James Mickens. 2014 ano

Computer Systems Security é um curso sobre o desenvolvimento e implementação de sistemas de computador seguros. As palestras abrangem modelos de ameaças, ataques que comprometem a segurança e técnicas de segurança baseadas em trabalhos científicos recentes. Os tópicos incluem segurança do sistema operacional (SO), recursos, gerenciamento de fluxo de informações, segurança de idiomas, protocolos de rede, segurança de hardware e segurança de aplicativos da web.

Palestra 1: “Introdução: modelos de ameaças” Parte 1 / Parte 2 / Parte 3
Palestra 2: “Controle de ataques de hackers” Parte 1 / Parte 2 / Parte 3
Aula 3: “Estouros de Buffer: Explorações e Proteção” Parte 1 / Parte 2 / Parte 3
Palestra 4: “Separação de Privilégios” Parte 1 / Parte 2 / Parte 3
Palestra 5: “De onde vêm os sistemas de segurança?” Parte 1 / Parte 2
Palestra 6: “Oportunidades” Parte 1 / Parte 2 / Parte 3
Palestra 7: “Sandbox do Cliente Nativo” Parte 1 / Parte 2 / Parte 3
Aula 8: “Modelo de Segurança de Rede” Parte 1 / Parte 2 / Parte 3
Aula 9: “Segurança de aplicativos da Web” Parte 1 / Parte 2 / Parte 3
Palestra 10: “Execução Simbólica” Parte 1 / Parte 2 / Parte 3
Aula 11: “Linguagem de Programação Ur / Web” Parte 1 / Parte 2 / Parte 3
Aula 12: Segurança de rede Parte 1 / Parte 2 / Parte 3
Aula 13: “Protocolos de Rede” Parte 1 / Parte 2 / Parte 3
Palestra 14: “SSL e HTTPS” Parte 1 / Parte 2 / Parte 3
Palestra 15: “Software Médico” Parte 1 / Parte 2 / Parte 3
Palestra 16: “Ataques de Canal Lateral” Parte 1 / Parte 2 / Parte 3
Palestra 17: “Autenticação de Usuário” Parte 1 / Parte 2 / Parte 3

Então, vamos começar. Com o retorno de vocês, espero que as férias para todos tenham sido um sucesso. Hoje falaremos sobre autenticação de usuário. Então, o tópico da palestra é descobrir como os usuários podem provar sua identidade ao programa? Em particular, o artigo, destinado à lição de hoje, aborda os próprios fundamentos da existência de uma comunidade de segurança. Existe algo melhor para autenticação do que senhas?



No nível mais alto, parece que as senhas são uma péssima idéia, porque têm entropia muito baixa e é fácil para os invasores resolvê-las. As perguntas secretas que usamos para recuperar senhas esquecidas têm ainda menos entropia do que as próprias senhas, e isso também parece ser um problema.

E ainda pior, os usuários geralmente usam a mesma senha em muitos sites diferentes. Isso significa que uma vulnerabilidade em uma senha facilmente adivinhada compromete o trabalho do usuário em muitos sites.

Gostei da seguinte citação de um artigo da palestra de hoje: "o domínio contínuo de senhas entre todos os outros métodos de autenticação de usuários é um grande obstáculo à pesquisa de segurança". Assim, a comunidade de pesquisa de segurança deseja ter uma alternativa melhor do que as senhas. No entanto, não está claro se existe realmente um esquema de autenticação que possa substituir completamente as senhas, sendo mais conveniente, mais amplo e mais seguro.

Hoje vamos considerar três questões. Primeiro, veremos como as senhas existentes funcionam. Depois disso, falaremos sobre as propriedades globais desejadas da senha para qualquer esquema de autenticação. Por fim, examinamos o que o artigo da palestra sobre métricas ou recursos de autenticação analisa e como alguns outros esquemas de autenticação são comparados em termos de eficiência com senhas.



Então, o que é uma senha? A senha é um segredo compartilhado para o usuário e o servidor. Portanto, uma implementação primitiva de um esquema de senhas deve basicamente ter apenas uma tabela do lado do servidor que mapeie nomes de usuários para suas senhas.

Essa é a maneira mais fácil de imaginar a implementação de um dos esquemas de autenticação - o usuário digita seu nome e senha, o servidor os procura nesta tabela, compara a senha com o nome e, se tudo corresponder, o usuário será autenticado. Claramente, o problema é que, se um invasor invade o servidor, ele pode apenas olhar para esta tabela e assumir todas as senhas. Então isso é claramente uma coisa ruim.

Talvez a solução para esse problema seja armazenar a tabela no servidor, com a seguinte aparência: o nome de usuário não corresponde à própria senha, mas ao seu hash. Nesse caso, o usuário digita a senha em texto sem formatação, o servidor verifica seu código de hash e o compara com o valor da tabela. A vantagem desse esquema é que essas funções de hash são projetadas de tal maneira que é difícil inverter o hash para uma senha. Se essa tabela for perdida, houver um vazamento de dados ou o invasor invadir o servidor e se apossar dela, ele verá seqüências de caracteres alfanuméricos aleatórios em vez de senhas de texto, e será difícil restaurar a imagem original.

Pelo menos em teoria, usar hashes é uma coisa muito boa. Mas agora, na prática, os atacantes não precisarão usar um ataque de força bruta para determinar a imagem inversa do valor do hash.



Os invasores podem realmente tirar proveito do fato de que, na prática, as senhas têm uma distribuição desigual. E pela distribuição desigual, quero dizer ... digamos que sabemos que todas as senhas têm até 20 caracteres. Na prática, os usuários não usam todo esse intervalo, preferindo senhas como 123, todd ou algo semelhante. No entanto, estudos empíricos mostraram como essas senhas funcionam e verificou-se que cerca de 20% dos usuários usam as 5000 senhas mais populares. Em outras palavras, isso significa que, se um invasor tiver um banco de dados dessas 5.000 senhas, ele poderá hash-las facilmente e, em seguida, ao visualizar a tabela de senhas roubadas, simplesmente corresponderá aos hashes. Portanto, empiricamente, um hacker poderá recuperar cerca de 20% das senhas que estão na tabela do servidor.

Os especialistas do Yahoo descobriram que as senhas contêm de 10 a 20 bits de entropia, de 10 a 20 bits de aleatoriedade. De fato, isso não é tanto. Considerando a complexidade da criação de uma função hash, as máquinas modernas calculam milhões desses hashes a cada segundo. Assim, uma função de hash deve ser facilmente computável no design para que os computadores possam facilmente senhas de hash. No entanto, a combinação desse fato com a aleatoriedade insuficiente de senhas significa que, em princípio, esse esquema não é tão seguro quanto parece.

Há uma coisa com a qual você pode tentar complicar a vida de um hacker - essa é uma função complexa da formação de chaves. Nesse caso, quero dizer que o hash da senha é usado como dados de origem, com base no qual o servidor gera uma chave que é armazenada no servidor.



O que é bom nessas funções de geração de chaves é que elas têm uma complexidade personalizável, ou seja, é possível girar um determinado botão e fazer com que essa função funcione mais lenta ou mais rapidamente, dependendo de quanto você deseja economizar no desempenho do processo.

Suponha que você queira gerar uma chave. Um exemplo é o padrão de geração de chaves PBKDF2 ou, possivelmente, BCrypt, você pode aprender mais sobre eles na Internet. Vamos imaginar que uma dessas funções de geração de chaves exigisse um segundo inteiro, e não alguns milissegundos, para calcular. De fato, isso tornará o trabalho do invasor muito mais difícil, porque a tentativa de gerar valores para as senhas “top” de 5.000 demorará muito mais tempo.

No nível interno, essas funções de geração de chaves geralmente funcionam chamando repetidamente um hash, acessando-o muitas vezes, para que tudo seja bem simples. Mas o uso do processo demorado de geração de chaves resolve o problema de segurança que estamos enfrentando? A resposta é não, porque um dos problemas é que o adversário pode construir algo chamado tabelas arco-íris, ou "tabelas arco-íris". Uma tabela arco-íris é simplesmente um mapa de como uma senha corresponde a um valor de hash. Portanto, mesmo que o sistema use uma dessas funções caras de geração de chaves, um invasor pode calcular uma dessas tabelas uma vez. Isso pode ser um pouco complicado, porque o processamento de cada função de geração de chaves é algo bastante lento, mas um invasor pode criar essa tabela uma vez e usá-la para quebrar todos os sistemas subsequentes com base nos mesmos algoritmos de função de geração de chaves. É assim que essas tabelas do arco-íris funcionam.

Repito mais uma vez - para maximizar os benefícios econômicos da criação da tabela Rainbow, um invasor pode tirar proveito da distribuição desigual de senhas, sobre a qual falei anteriormente. Assim, um invasor pode criar essa tabela apenas para um pequeno conjunto de todas as senhas possíveis.

Aluno: provavelmente "salgar" torna muito mais difícil?

Professor: sim, sim, exatamente. Iremos para a "salga" em alguns segundos. Em geral, se você não usar salga, as tabelas arco-íris permitem que um invasor, com algum esforço no modo offline, calcule essa tabela e se beneficie da capacidade de calcular senhas básicas com base no trabalho realizado.

A próxima coisa que você pode pensar em melhorar a situação é salgar. Como isso funciona? O princípio básico é introduzir alguma aleatoriedade adicional no método de geração de senha. Você pega essa função de hash, coloca o “salt” nela, e depois a senha, e tudo isso é armazenado em uma tabela no servidor.



O que é sal? Essa é apenas uma sequência longa que representa a primeira parte dessa função de hash. Então, por que é melhor usar esse esquema? Observe que o “salt” é realmente armazenado em texto não criptografado no lado do servidor. Você pode pensar: Bem, se esse "salt" é armazenado em texto não criptografado no servidor e um invasor pode roubar uma tabela de nomes de usuários para senhas, então por que ele também não pode roubar esse "salt"? Qual é a utilidade dessa solução?

Aluno: porque se você escolher a senha mais comum, não poderá usá-la apenas uma vez e encontrar um novo usuário.
Professor: absolutamente verdade. Basicamente, o que o sal faz é impedir que o invasor crie uma única tabela arco-íris que possa ser usada contra todos os hashes. Em princípio, você pode considerar o "salt" uma maneira de tornar únicas as mesmas senhas. Na prática, muitos sistemas usam o conceito de "salga".

De fato, o “salt” torna possível adicionar o maior número possível de bits a essa pseudo-senha, pois quanto mais bits, melhor. O que mais precisa ser feito é levar em consideração que sempre que o usuário altera sua senha, o “salt” também deve ser alterado. Porque um dos motivos dessa decisão é a preguiça dos usuários que desejam usar a mesma senha várias vezes. Alterar o “salt” garantirá que o que está armazenado no banco de dados de senhas realmente diferirá, mesmo que uma senha seja substituída exatamente pela mesma senha.

Público: por que é chamado de "sal"?

Professor: Essa é uma boa pergunta, e não posso responder com certeza. No entanto, tenho certeza de que há alguma justificativa para isso. Por que os cookies são chamados de cookies? A Internet provavelmente sabe o porquê, mas eu não sei.

Aluno: talvez porque “sal” acrescente um pouco de “sabor” ao hash?

Professor: bom, estou feliz que estamos filmando isso porque claramente temos a chance de ganhar um prêmio de cinema. Estou certo de que existe algum tipo de resposta na Internet, portanto, procurarei depois.
Portanto, as abordagens acima são bastante simples. Eu assumi que o usuário de alguma forma envia a senha para o servidor, mas não especificou como isso acontece. Então, como passamos essas senhas?

Primeiro, você pode simplesmente enviar a senha pela rede em texto não criptografado. Isso é ruim porque pode haver um intruso na rede que monitora o tráfego que você envia. Ele pode simplesmente atribuir uma senha e se passar por você.

Portanto, sempre começamos com um homem de palha, antes de eu mostrar os outros homens de palha, que, é claro, também são fatalmente falhos. Portanto, a primeira coisa que você deve pensar é enviar a senha em texto não criptografado. Do ponto de vista da segurança, é muito melhor enviar uma senha por meio de uma conexão criptografada, por isso usamos criptografia. É possível que tenhamos algum tipo de chave secreta usada para converter a senha antes de enviá-la pela rede. Portanto, no nível mais alto, parece que a criptografia sempre faz as coisas melhor, como uma marca registrada que garante a qualidade do produto.

Mas o problema é que, se você não pensar cuidadosamente sobre como usar criptografia e hash, não poderá tirar proveito dos benefícios de segurança com os quais está contando. Por exemplo, se houver alguém sentado entre você - o usuário e o servidor, esse intruso notório, o "homem do meio" que realmente monitora seu tráfego, enquanto finge ser um servidor.

Se você enviar dados criptografados sem autenticar o outro lado, poderá encontrar um problema. Como o cliente simplesmente seleciona uma chave aleatória e a envia para um destino do outro lado, que pode ou não ser o servidor.

Na verdade, você está enviando algo para uma pessoa que depois disso terá a oportunidade de se apossar de todos os seus segredos.

Diante disso, as pessoas podem pensar que é muito melhor enviar não a senha em si, mas seu hash. De fato, isso por si só não fornece nada, porque, se você envia uma senha ou um hash de senha, esse hash de senha tem a mesma força semântica que a senha original e não ajudará se você não tiver autenticado o servidor.

Portanto, o ponto principal é que apenas adicionar criptografia ou adicionar hash não necessariamente oferece benefícios adicionais de segurança. Se o cliente não puder se autenticar para quem ele envia a senha, o cliente poderá divulgar a senha erroneamente para alguém que não pretenda divulgá-la.

Portanto, talvez uma idéia melhor do que as duas anteriores seja usar o chamado protocolo de desafio / resposta ou protocolo de desafio / resposta. Aqui está um exemplo de um protocolo de chamada / resposta muito simples. Aqui temos um cliente e aqui temos um servidor. O cliente diz ao servidor: "Oi, eu sou Alice", após o qual o servidor responde com uma chamada C. Em seguida, o cliente responde com um hash dessa chamada enviada pelo servidor, combinando-a com a senha.



O servidor sabe a resposta, portanto, no momento, ele pode aceitar essa sequência - a resposta do cliente. O servidor também conhece o desafio que enviou e, presumivelmente, conhece a senha, para que o servidor possa calcular o valor do hash recebido e verificar se ele realmente corresponde ao enviado pelo usuário.

Uma característica positiva desse protocolo, se ignorarmos a existência de um "homem no meio" por um segundo, é que o servidor terá certeza de que o usuário é realmente Alice, porque apenas Alice conhecerá essa senha. Ao mesmo tempo, se Alice enviar isso não para o servidor, mas para a pessoa que fingiu ser o servidor, ele não saberá a senha. Como um invasor pode usar C, mas ainda não sabe a senha, e para descobrir a senha, ele precisa inverter essa função de hash novamente. Você tem alguma pergunta?

Aluno: um cliente, em vez de enviar uma senha para um servidor e receber uma chamada de servidor com hash, pode simplesmente enviar uma senha com hash para o servidor?

Professor: ou seja, você pergunta por que o cliente simplesmente não envia a senha com hash para o servidor? Existem 2 razões para isso. Discutiremos um posteriormente, ele é chamado de proteção Antihammering e foi criado para se defender de clientes "ruins", perguntando constantemente: "essa é uma senha ou é uma senha, talvez seja uma senha?" Esse mecanismo de autenticação simplifica o processo para o servidor e o cliente, mas você pode essencialmente criar um hash no lado do cliente, usando JavaScript ou algo assim. Mas a idéia básica é que, de alguma forma, você precise garantir a máxima complexidade de autenticação para impedir que o invasor adivinhe rapidamente a senha. Mais alguma pergunta?



Aluno: Eu só queria observar que, mesmo que o cliente faça hash, no caso em que alguém assuma o controle da tabela do servidor e a use para hash, ele poderá entrar na rede.

Professor: absolutamente verdade. Sim, torna-se um pouco perigoso, dependendo de quem pode se apossar dessa chamada C. Como se o cliente e o servidor puderem escolher os valores desse C, isso complica a capacidade do cliente de organizar esses ataques. Um dos problemas com o uso desse protocolo é que o cliente não pode randomizar esse valor HCC. Pode-se imaginar que você pode tornar esse protocolo mais complicado para a inversão do servidor, se o cliente puder selecionar alguma chamada C na parte HCC, mas nesse caso haverá uma justaposição de chamadas do cliente e do servidor.
Se não houver mais perguntas, assumiremos que terminamos a discussão sobre mecanismos de transferência de senha do cliente para o servidor. , , brute-force, -, .

, , , HCC. , «». « ».

, , , , « ». «» , « » .

Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».



-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .
, , , - . , , - , , . – . , , .

, — , , — . , , . , . , , .

, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .



«», , , , , «».



«» , . Telepathwords? , , . , .



, . , , . , .

, Telepathwords , , , , , . .
, — , , , .

: , , IP- , Antihammer .

: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .

, . , . , .

: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …

: , ?

: ?

:sim, são usados. Esses protocolos fornecem garantias mais fortes de criptografia. Na maioria dos casos, eles não são compatíveis com os sistemas atuais; portanto, na prática, você não percebe com que frequência eles são usados. Mas existem alguns protocolos que permitem que o servidor não saiba qual é a senha, como o ZKP, que é realmente usado na prática.

27:20 min

Curso MIT "Segurança de sistemas de computadores". Aula 17: Autenticação de Usuário, Parte 2


A versão completa do curso está disponível aqui .

Obrigado por ficar conosco. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando a seus amigos, um desconto de 30% para os usuários da Habr em um análogo exclusivo de servidores básicos que inventamos para você: Toda a verdade sobre o VPS (KVM) E5-2650 v4 (6 núcleos) 10GB DDR4 240GB SSD 1Gbps de US $ 20 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 núcleos) 10 GB DDR4 240 GB SSD de 1 Gbps até dezembro de graça quando pagar por um período de seis meses, você pode fazer o pedido aqui .

Dell R730xd 2 vezes mais barato? Somente nós temos 2 TVs Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 a partir de US $ 249 na Holanda e nos EUA! Leia sobre Como criar um prédio de infraestrutura. classe usando servidores Dell R730xd E5-2650 v4 custando 9.000 euros por um centavo?