Quanto è sicura l'autenticazione dei moduli di base in asp.net?

Question

Immagina di avere un sito semplice con solo 2 pagine: login.aspx e secret.aspx. Il tuo sito è protetto utilizzando nient'altro che ASP.net forma l'autenticazione e un controllo server ASP.net Login su login.aspx. I dettagli sono i seguenti:

• Il sito è configurato per utilizzare SqlMembershipProvider
• Il sito nega tutti gli utenti anonimi
• I cookie sono disabilitati

Ovviamente ci sono molte cose da considerare per quanto riguarda la sicurezza, ma sono più interessato all'esperienza zero code out of the box fornita con il framework .net.

Se, per il bene di questa domanda, gli unici punti di attacco sono le caselle di testo nome utente / password in login.aspx, un hacker può inserire codice che consentirà loro di accedere alla nostra pagina secret.aspx?

Quanto è sicura l'esperienza predefinita del codice zero fornita da Microsoft?

Answer 1

Hai ancora alcune variabili che non sono state prese in considerazione:

• Sicurezza nell'archivio dati utilizzato dal proprio provider di appartenenza (in questo caso, il database Sql Server).
• sicurezza di altri siti ospitati nello stesso IIS
• sicurezza generale della rete delle macchine coinvolte nell'hosting del sito o sulla stessa rete in cui è ospitato il sito
• sicurezza fisica delle macchine che ospitano il sito
• Stai utilizzando le misure appropriate per crittografare il traffico di autenticazione? (HTTPS / SSL)

Non tutti questi problemi sono specifici degli Stati membri, ma vale la pena menzionarli perché nessuno di essi potrebbe facilmente superare il problema di cui ti stai chiedendo, se non risolto. Ma, ai fini della tua domanda, suppongo che non ci siano problemi con loro.

In tal caso, sono abbastanza sicuro che l'autenticazione dei moduli faccia quello che dovrebbe fare. Non credo che ci siano exploit attualmente attivi là fuori.

Answer 2

Per quanto ne so, la password verrà inviata come testo normale (ma codificata). Quindi la cosa più importante da fare è utilizzare il protocollo HTTPS nelle schermate di accesso.

L'altra impostazione sembra essere sicura per me.

Answer 3

Con l'autenticazione di base HTTP, che utilizza l'autenticazione basata su moduli di base .NET, per visualizzare la pagina secret.aspx, il browser deve inviare una concatenazione codificata Base64 di nome utente e password.

A meno che non si utilizzi SSL, chiunque abbia accesso alla scansione della rete tra il server e il browser può leggere queste informazioni. Possono decodificare il nome utente e la password. Possono riprodurre il nome utente e la password in futuro per accedere alla pagina secret.aspx.

Detto questo, a meno che tu non usi SSL, qualcuno può anche scansionare l'intera sessione di qualcun altro usando secret.aspx, quindi in effetti avrebbero accesso anche al contenuto della pagina.

Answer 4

Beh, prova a guardare dietro le quinte:

  

Protezione password

     

Applicazioni che memorizzano nomi utente,   password e altra autenticazione   le informazioni in un database non dovrebbero mai   memorizzare le password in chiaro, per evitare che   il database viene rubato o compromesso. A   a tal fine, SqlMembershipProvider   supporta tre formati di archiviazione   (" codifiche ") per password e   risposte password. Il provider   Proprietà PasswordFormat, che è   inizializzato da passwordFormat   attributo di configurazione, determina   quale formato viene utilizzato:

     

  
• MembershipPasswordFormat.Clear, che memorizza password e password   risposte in testo semplice.
  
• MembershipPasswordFormat.Hashed (impostazione predefinita), che memorizza salato   hash generati da password e   risposte password. Il sale è un caso   Valore a 128 bit generato da .NET   RNGCryptoServiceProvider di Framework   classe. Ogni password / risposta password   la coppia viene salata con questo valore unico,   e il sale è immagazzinato nel   PasswordSalt della tabella aspnet_Membership   campo. Il risultato dell'hash del   password e il sale è memorizzato nel file   Campo password. Allo stesso modo, il risultato   di hashing della risposta della password e del   salt è memorizzato in PasswordAnswer   campo.
  
• MembershipPasswordFormat.Encrypted,   che memorizza password crittografate e   risposte password.   Crittografia SqlMembershipProvider   password e password risposte utilizzando   la crittografia / decrittografia simmetrica   chiave specificata in   decryptionKey della sezione di configurazione   attributo e la crittografia   algoritmo specificato in    sezione di configurazione   attributo di decrittazione.   SqlMembershipProvider lancia un   eccezione se viene richiesto di crittografare   password e risposte password, e se   decryptionKey è impostato su Autogenerate.   Questo impedisce un database di appartenenza   contenente password crittografate e   la password risponde non diventando valida   se spostato su un altro server o un altro   applicazione.
  

Quindi la forza della tua sicurezza (pronta all'uso) dipenderà dalla strategia del formato di protezione password che stai usando:

• Se usi il testo in chiaro, è ovviamente più facile hackerare il tuo sistema.
• Utilizzando Encrypted invece, la sicurezza dipenderà dall'accesso fisico al tuo computer (o almeno, machine.config).
• L'uso delle password con hash (impostazione predefinita) garantirà la sicurezza in base a: a) ribaltamenti noti della strategia di hash della classe RNGCryptoServiceProvider eb) accesso al database per compromettere il salt generato in modo casuale.

Non so se è possibile utilizzare una sorta di hack della tabella arcobaleno nel sistema Hash-base predefinito.

Per maggiori dettagli, controlla questo link: http://msdn.microsoft.com/en-us/library/aa478949. aspx

Answer 5

Se configurato correttamente tramite il provider di appartenenze, avrai un livello di sicurezza adeguato. A parte ciò, l'accesso a quella pagina potrebbe essere accessibile attraverso attacchi cannonici, ma ciò ha a che fare con la tua sicurezza generale. Ho tenuto una presentazione sull'uso dei Security Enterprise Application Blocks . Potresti volerne leggere e approfondire questi aspetti durante l'implementazione della sicurezza sul tuo sito ed essere solo consapevole delle comuni minacce alla sicurezza. Nessun sito sarà mai irremovibile al 100%, dato che ci si trova su una rete condivisa aperta e la sicurezza totale sarebbe un server scollegato bloccato in una cassaforte custodita 24 ore su 24, 7 giorni su 7 dall'esercito (intorno al livello di sicurezza DoD "A", basato su Orange libro). Ma la funzionalità out of the box dei provider di appartenenza (se configurata correttamente) offrirà una buona quantità di sicurezza.

Modifica: Sì, sono d'accordo con l'altro commento che è stato fatto, HTTPS su almeno le schermate di accesso è un dato, se si desidera proteggere il nome utente / le password da sniffer di pacchetti e monitor di rete.

Answer 6

Asp.Net supporta sessioni senza cuoco, come questo post del blog mostra . Invece di un cookie di sessione, utilizza un identificatore nell'URL per tracciare gli utenti.

Non sono sicuro di quanto sia sicuro, ma penso che sia una sicurezza poiché la difficoltà di forzare la stringa di identità è bruta.

Sembra che funzioni più o meno immediatamente, tuttavia quando si reindirizza un utente e si desidera mantenere lo stato della sessione è necessario includere l'ID della sessione. Il post sul blog mostra come farlo, così come molti altri articoli sul web.

Answer 7

Ecco due buoni articoli di Microsoft sull'argomento:

Come: proteggere l'autenticazione dei moduli in ASP.NET 2.0

INFO: Guida all'autenticazione basata su moduli sicuri tramite Secure Sockets Layer (SSL)

Answer 8

I cookie su URL non sono abbastanza sicuri, ci sono così tanti problemi diversi (specialmente perdite di referrer se ne hai uno) e utilizzo di HTTPS.