Autenticação de usuário móvel / global? (Sem domínio e sem empresa)

5

Qual é a maneira atual de autenticar usuários de maneira móvel / global? Em outras palavras, assuma um aplicativo para dispositivos móveis. E se houver um servidor de banco de dados no back-end, como esses usuários normalmente se registram / logam? Existe um padrão atual para autenticação não corporativa e não corporativa?

Eu estava pensando em ter apenas uma combinação básica de nome de usuário / senha e hashing (e salgando) a senha no registro e no login, e passar isso para o banco de dados em nuvem. Isso fica um pouco confuso com a redefinição de senha, envio por e-mail etc., no entanto.

Existe uma maneira mais fácil (API, metodologia, etc.) ou forma mais aceita para fazer isso? É simples, mas essa simplicidade é uma coisa boa, eu acho. Não preciso das complexidades de outras estruturas de associação. Estou mais curioso para saber se essa é uma abordagem aceita e segura.

Estou ciente do modelo de associação do ASP.NET, mas a complexidade é demais para um modelo de segurança unidimensional (usuários e autenticação, sem necessidade de funções, autorização, etc.). Sem mencionar que, fora de um aplicativo ASP.NET, o que seria usado?

    
por user3175663 22.03.2014 / 15:46
fonte

1 resposta

2

Em geral, se seu aplicativo móvel for baseado em serviços da Web remotos, você deverá estabelecer uma conexão segura (ssl / tls) com o servidor remoto e passar o nome de usuário / senha diretamente ao servidor para processamento no servidor, não em o cliente.

Eu presumo que isso seja algum tipo de servidor web. Você definitivamente não vai se conectar diretamente do seu aplicativo móvel a um servidor de banco de dados, não é?

O que você faria não seria codificar a senha fornecida pelo usuário no telefone e passar o hash pelo fio para comparação no servidor. O trabalho do servidor de autenticação é confirmar que a parte remota sabe a senha correta para o nome de usuário fornecido, não que a parte remota saiba a senha correta hash para o nome de usuário.

Caso contrário, um invasor que possa ter obtido acesso ao seu banco de dados de credenciais pode simplesmente passar um nome de usuário e senha hash e nunca precisar saber a senha real. Opa! : -) .

Se você for criar sua própria autenticação no servidor, precisará armazenar pelo menos três campos:

  • o nome de usuário
  • hash de senha
  • sal (entropia gerada aleatoriamente, única por usuário)

Você também deve considerar o armazenamento:

  • um ID de versão hash de senha, para que você possa alternar para um algoritmo atualizado no futuro sem automaticamente invalidar todas as suas senhas existentes

  • uma data / hora de expiração da senha (ou alguma variação desse conceito) para que você possa expirar as senhas quando precisar ou para que elas expirem automaticamente após uma determinada idade

O hash de sal e senha são matrizes de bytes quando totalmente reconstituído na memória do computador. Converta-os em sequências codificadas em Base64 para armazenamento.

Simplesmente hashing a senha é considerada insuficiente agora:

  • mesmo se você usar sal e até mesmo se você usar um algoritmo de hash substancial como SHA256 ou SHA512

    • o uso de hashing direto sem sal foi o que colocou um certo serviço de rede de grandes empresas em tantos problemas com a última violação de conta de usuário
  • métodos de ataque de dicionário usando GPUs em placas de vídeo poderosas combinadas com dicionários ou tabelas de arco-íris torna necessário tornar as comparações de senha lentas o suficiente para não valer o esforço

  • O MD5 simplesmente não está à altura da tarefa e não faz muito tempo

  • O SHA1 tem explorações teóricas e é considerado fraco agora (pelo menos potencialmente, apenas uma questão de tempo antes de ser explorado)

  • SHA256 ou SHA512 são melhores, mas ainda são muito rápidos

Use um algoritmo realmente projetado para hashing de senhas, como bcrypt , scrypt ou PBKDF2 .

  • Esses tipos de algoritmos são construídos em algoritmos hash como SHA1 ou SHA256, além de algoritmos HMAC , e depois iteram muitos vezes (talvez milhares, ou mais) alimentando o resultado de cada iteração de volta ao algoritmo para torná-lo lento demais para um atacante de força bruta executar bilhões de comparações a partir de uma tabela de dicionário / arco-íris, sendo ainda rápido o suficiente para verificar razoavelmente logins de usuários.

  • Você pode variar o número de iterações para atender às suas próprias finalidades (velocidade versus segurança).

  • Um invasor terá que saber qual algoritmo você usa e também saber o número de iterações que você escolheu

  • O ID do algoritmo de autenticação entra em jogo aqui; se você aumentar o número de iterações, você quebrará todas as suas credenciais de usuário existentes, a menos que tenha identificado o algoritmo e continue a suportar o antigo algoritmo (digamos, PBKDF2 com 1.000 iterações) para senhas existentes, exigindo o novo algoritmo (digamos PBKDF2 com 10.000 iterações) para senhas novas e atualizadas

Se a carga de processamento se tornar muito grande para o seu servidor (presumivelmente um servidor da Web), você poderá descarregar a autenticação em um servidor separado.

Muitas crianças legais estão fazendo PBKDF2, embora o bcrypt alegadamente torne mais difícil para um ataque baseado em GPU comparar muitas senhas rapidamente. O Scrypt pode ser uma melhoria em relação ao bcrypt. Eu não estou fazendo nenhum juízo de valor aqui. Faça sua própria pesquisa sobre isso. PBKDF2 pode ser compatível com FIPS, por exemplo, enquanto bcrypt e scrypt não são, mas a conformidade com FIPS pode não ser um requisito para você.

    
por 24.03.2014 / 23:04
fonte

Tags