Quão seguro é a autenticação de formulários básicos em asp.net?

Question

Imagine que você tem um site simples, com apenas 2 páginas: login.aspx e secret.aspx. Seu site é protegido usando nada além ASP.net autenticação de formulários e um controle de servidor ASP.net Entrada em login.aspx. Os detalhes são os seguintes:

• O site está configurado para usar o SqlMembershipProvider
• O site nega todos os usuários anônimos
• Os cookies são desativados

O são obviamente muitas coisas a considerar em relação à segurança, mas eu estou mais interessado no código de zero experiência fora do caixa que vem com o .NET Framework.

Se, por causa desta questão, o único ataque pontos são o nome de usuário / senha caixas de texto em login.aspx, um hacker pode injetar código que lhes permitirá aceder à nossa página secret.aspx?

Como seguro é o código zero de experiência out-of-box que a Microsoft fornece?

Answer 1

Você ainda tem algumas variáveis ??que não são contabilizados para:

• Segurança no armazenamento de dados usado pelo seu provedor de associação (neste caso, o banco de dados SQL Server).
• segurança de outros sites hospedados no mesmo IIS
• segurança de rede geral das máquinas envolvidas na hospedagem do site, ou na mesma rede onde o site está hospedado
• segurança física das máquinas que hospedam o site
• Você está usando medidas adequadas para o tráfego de autenticação criptografar? (HTTPS / SSL)

Nem todas essas questões são MS específico, mas eles são vale a pena mencionar, porque qualquer um deles poderia facilmente superar o problema que você está perguntando sobre, se não tomar cuidado. Mas, com o propósito da sua pergunta eu vou assumir que não existem quaisquer problemas com eles.

Nesse caso, eu tenho certeza que a autenticação de formulários faz o que é suposto fazer. Eu não acho que há explorar qualquer ativo lá fora.

Answer 2

Tanto quanto eu sei senha será enviada como texto simples (mas codificado). Então, a coisa mais importante a fazer é usar o protocolo HTTPS em telas de login.

O outro cenário parece ser seguro para mim.

Answer 3

Com HTTP autenticação básica, que é o que o .NET autenticação de formulários básicos está usando, a fim de visualizar a página secret.aspx, o navegador deve enviar um Base64 codificado concatenação do nome de usuário e senha.

A menos que você utilizar SSL, qualquer pessoa que tenha acesso a digitalizar a rede entre o servidor eo navegador pode ler esta informação. Eles podem decodificar o nome de usuário e senha. Eles podem repetir o nome de usuário e senha no futuro para ter acesso à página secret.aspx.

Dito isto, a menos que você use SSL, alguém também pode digitalizar toda a sessão de outra pessoa usando secret.aspx, então em vigor, eles teriam acesso ao conteúdo da página também.

Answer 4

Bem, tentar e olhar por trás das cenas:

Proteção de senha

Os aplicativos que armazenar os nomes de usuário, senhas e outras autenticação informações em um banco de dados nunca deve armazenar senhas em texto simples, para que a base de dados ser roubado ou comprometida. Para esse fim, SqlMembershipProvider suporta três formatos de armazenamento ( "codificações") para senhas e respostas de senha. O provedor é propriedade PasswordFormat, que é inicializado a partir do passwordFormat atributo de configuração, determina qual o formato é usado:

• MembershipPasswordFormat.Clear, que armazena senhas e senha respostas em texto simples.
• MembershipPasswordFormat.Hashed (o padrão), que armazena salgada hashes gerados a partir de senhas e respostas de senha. O sal é um aleatória valor de 128 bits gerada pelo .NET RNGCryptoServiceProvider do quadro classe. Cada resposta de senha / password par é salgado com este valor original, e o sal é armazenado no PasswordSalt tabela aspnet_Membership campo. O resultado do hash da senha e o sal é armazenado no campo de senha. Da mesma forma, o resultado de hash da resposta de senha ea sal é armazenado no PasswordAnswer campo.
• MembershipPasswordFormat.Encrypted, que armazena senhas criptografadas e respostas de senha. criptografa SqlMembershipProvider senhas e respostas senha usando o simétrica de criptografia / descriptografia chave especificada no decryptionKey da seção de configuração atributo, e encriptação algoritmo especificado na seção de configuração do atributo de descriptografia. SqlMembershipProvider lança uma exceção se ele é solicitado para criptografar senhas e respostas senha, e se decryptionKey está definido para Autogenerate. Isso evita que um banco de dados de membros contendo senhas criptografados e respostas de senha de se tornar inválida se movido para outro servidor ou de outra aplicação.

Assim, a força de sua segurança (fora da caixa) vai depender de qual estratégia formato proteção de senha que você está usando:

• Se você usar texto claro, é obviamente mais fácil de invadir seu sistema.
• Usando criptografados por outro lado, a segurança vai depender de acesso físico à sua máquina (ou, pelo menos, machine.config).
• Usando hash de senhas (o padrão) vai garantir a segurança dependendo: a.) Reversões conhecidos da estratégia de hashing de classe RNGCryptoServiceProvider e b) o acesso ao banco de dados para comprometer o sal gerado aleatoriamente

Eu não sei se é possível usar algum tipo de rainbow table invadir o sistema padrão Hash-base.

Para mais detalhes, confira este link: http://msdn.microsoft.com/en-us/library/aa478949. aspx

Answer 5

Se configurado corretamente através do provedor de associação, você terá um nível adequado de segurança. Fora isso, o acesso a essa página pode ser acessível através de ataques canônicas, mas que tem a ver com a sua segurança geral. Eu dei uma apresentação sobre o uso do href="http://msdn.microsoft.com/en-us/library/cc309508.aspx" rel="nofollow noreferrer"> Enterprise Security Application Blocks . Você pode querer ler sobre esses e olhar para que, quando a implementação de segurança em seu site, e apenas estar ciente das ameaças de segurança comuns. Nenhum site nunca vai ser 100% unhackable, uma vez que você está em uma rede compartilhada aberta e total segurança seria um servidor desconectado trancada em um cofre guardado 24/7 pelos militares (cerca de DoD "A" segurança nível, com base do livro Laranja ). Mas o fora da funcionalidade caixa dos provedores de associação (quando configurado corretamente) vai oferecer uma boa quantidade de segurança.

Edit: Sim, eu concordo com o outro comentário que foi feito, HTTPS, pelo menos, o log em telas é um dado, se você quiser proteger o nome de usuário / senhas de sniffers e monitores de rede.

Answer 6

Asp.Net suporta sessões cookieless, como neste blog post mostra . Em vez de um cookie de sessão, ele usa um identificador na url para rastrear usuários.

Não estou certo o quão seguro é isso, mas eu acho que é um seguro como a dificuldade de força bruta a string de identidade.

Parece que ele funciona mais ou menos fora da caixa, no entanto, quando o redirecionamento de um usuário e querendo manter o estado da sessão é necessário incluir o ID de sessão. O blog post mostra como fazer isso, assim como muitos outros artigos sobre a web.

Answer 7

Aqui estão dois bons artigos da Microsoft sobre o assunto:

Como: Proteger a autenticação de formulários no ASP.NET 2.0

INFO: Ajuda autenticação de formulários seguro usando Secure Sockets Layer (SSL)

Answer 8

Biscoitos mais de URL não é suficiente seguro, existem tantos problemas diferentes com ele (vazamento especialmente referrer se você tem qualquer) e uso de HTTPS.