Lezioni di siti web di sicurezza anti-patterns da Tesco

Vorrei creare le premesse per questo post, condividendo un tweet semplice di ieri sera :

Ok allora, questo è come infrazioni di sicurezza quante Mi sa che può andare bene in 140 caratteri! Per coloro che chiedono, sì, questo è in realtà un account verificato e in realtà è Tesco risponde a me. Tornerò a molti punti di vista Tesco interessanti in materia di sicurezza un po 'più tardi, ma prima, alcuni retroscena:

Tengo un orologio sul menzioni del mio blog su Twitter e su un sacco di tweets in questo senso :

Curioso, come sempre, mi sono diretto verso tesco.com a dare un'occhiata. A pochi sguardi sommari intorno mostrato forse c'era un po 'di un'opportunita' - l'opportunità di istruzione per gli sviluppatori che vogliono imparare da anti-patterns, cioè vedere come coloro che li hanno preceduti hanno fatto male. Quindi, diamo uno sguardo ai molti errori di sicurezza semplici Tesco hanno consegnato e vedere come ci si avvicinerebbe in modo diverso quando si applicano i principi di sicurezza di base.

Oh - e per il pubblico al di fuori del Regno Unito, Tesco è una catena di supermercati importante del calibro di Coles in Australia o CostcoSafeway negli Stati Uniti. Sai, il tipo di multi-miliardi di dollari marchio che dovrebbe sapere come ottenere nozioni fondamentali sulla protezione web giusto, soprattutto quando si sta fornendo servizi di shopping online e gestire le tue informazioni di pagamento. Essi forniscono anche servizi bancari e assicurativi, anche se questo non è uno spazio prenderò in esame in questo post.

Password di archiviazione

Questo è ovviamente il primo posto per iniziare in commento di Dan. Come si è visto, anche se vivo a Sydney Mi hanno fatto un conto Tesco dal mio tempo di ritorno nel Regno Unito, a cavallo del millennio. Mi chiedo che la mia password era allora ...

Oh cara, beh certamente Dan inchiodato quando ha citato senza sale, chiaramente le password non viene eseguito l'hashing a tutti e tanto meno salato. Nella migliore delle ipotesi sono criptati ma le probabilità sono che stanno memorizzata in testo normale, purtroppo non ci sono prove del contrario.

La crittografia non è selettiva - i dati o è importante o non è

Quando si decide di dati vale la pena proteggere, è necessario essere coerenti nel vostro approccio. Non ha senso strettamente fissandolo in una posizione poi averlo sbattere in giro per la brezza in un altro.

A quanto pare, la crittografia è importante per mantenere i vostri dati personali privati:

Agli ordini, così come era esattamente quello protetto da password in email? Beh, certo non è stato protetto a tutti, è stato appena espulso volenti o nolenti.

Ma aspetta - Tesco mettere un grosso lucchetto giallo sulla pagina - che deve essere sicuro! Questo è esattamente il tipo di cosa che stavo parlando di un anno fa, quando ho detto che l'icona del lucchetto deve morire . E 'diventato nulla più di un gesto simbolico, che non garantisce uno dei tuoi contenuti siano effettivamente sicuro. E 'come quelle persone che hanno messo dei cartelli che dicono "attenti al cane", quando tutto quello che hai è un criceto geriatrica.

Contenuto misto e gli avvisi del browser

Tutti ricordare ciò che è contenuto misto? Questo è quando si carica una pagina su HTTPS - che implica un certo grado di sicurezza - ma poi si incorpora risorse caricate su HTTP che ti dà alcuna garanzia di sorta.

Questo è male. In effetti è così male che i browser di oggi vi darà un avvertimento molto evidente quando questo sta accadendo. Torna con la mente torna l'immagine qui sopra con il testo che dice "Perché è sicuro di fare shopping in Tesco.com". Sapere cosa che puntanofa? Questo:

Ok, quindi il browser è stato molto chiaro: non mi fido di questa pagina (quella di fiducia), in realtà non lo carica a tutti. Che diamine, mi piace vivere pericolosamente:

Quando si avvia ottenere grandi croci rosse nel browser, avere paura, molta paura. Ma probabilmente dovrebbe essere ancora più paura del paragrafo semplice apertura di Tesco:

E 'sicuro fare acquisti in Tesco.com

Beh, almeno sono diretto. Completamente sbagliato (almeno in base a ciò che abbiamo visto finora), ma diretto. Hanno un server sicuro (lo sappiamo perché abbiamo visto il loro lucchetto) in modo che tutti noi dovremmo avere la certezza che "transazione con noi sono private". Nizza.

Browser versione follia

Ma Tesco non lasciare che qualsiasi browser vecchio, oh no, è necessario utilizzare qualcosa di moderno come la versione 3.0 di "esploratore" o 3.02 di Netscape (questo è da più in basso nella schermata del grab precedente):

Ricordate ciò che questi ragazzi sembrava? Ti ricordi di Netscape? Molto probabilmente non perché c'è un pubblico considerevole là fuori l'esplorazione del Web che oggi sono stati ancora allattando quando ha lanciato a metà del 1996. Ecco un riassunto:

Fancy.

Perché Tesco sente il bisogno di indirizzare gli utenti per garantire il rispetto di una versione del browser 16 anni di età (o al di sopra, grazie) è piuttosto strano. In effetti dà l'impressione che nessuno è davvero prestare molta attenzione al sito. Heck, era strano quando ho inizialmente creato il mio account nel 1999!

Insicurezza persistente attraverso i cookie HTTP

Ricordate come Tesco è sicuro? Deve essere perché avevano l'icona del lucchetto, ma a loro credito, hanno fatto effettivamente fornire moduli di login su HTTPS. Ma poi vanno a fare questo:

Vedi il problema? Nessun HTTPS più - ma stiamo ancora registrato! Ah, ma la password è stata inviata tramite HTTPS al momento del login in modo che deve essere sicuro, diranno.Tranne, naturalmente, SSL non è sulla crittografia , o almeno non si tratta solo di crittografia delle credenziali di accesso.

Vedete, HTTP è stateless quindi l'unico (in pratica) così uno stato come essere collegati può essere persistente è passando cookie avanti e indietro tra il browser e il sito web. Ogni volta che l'utente effettua una richiesta, il browser dice: "Ehi, sono destinati ad essere connessi come Troy, ecco il mio biscotto per dimostrarlo". Potete vedere quei biscotti proprio qui per gentile concessione di Modifica questo cookie :

E perché sono stati inviati tramite una connessione HTTP, chiunque può osservare il trafficopuò vedere quei biscotti stessi. E copiarli. E dirottare la sessione. Suona complicato? Non è, infatti mi ha dimostrato quanto fosse facile nella parte 9 della mia OWASP per. sviluppatori NET serie sulla protezione insufficiente livello di trasporto quando l'ho fatto proprio questo.

Regole password

Devo confessare - io sono un peccatore. Non ho sempre creato password complesse. Li ho riutilizzato. A volte usato il nome del cane sanguinario, la maledizione! Ma sono riformate e ora sono un fervente sostenitore del mantra che L'unica password sicura è quella che non riesce a ricordare .

Quindi cerchiamo di saltare su oltre al "change password" pagina e generare me una forte con 1Password:

Oh cara, 10 caratteri. Tutto qui. La saggezza convenzionale - qualsiasi saggezza - afferma che le password dovrebbe essere lunga, casuale e unico nel suo genere, più di ogni, il migliore (e per favore, non pubblicare che f ****** XKCD comico batteria a cavallo come un contro-argomento) . Così che cosa sta succedendo a Tesco? Solo il 10? Te lo dico io cosa dice a me e risale fino al punto di memorizzazione delle password in precedenza: qualcuno si ha un varchar (10) là sotto da qualche parte ed è tutti seduti in testo normale. Certo che può solo speculare, ma le prove sembra suggerire questo su numerosi fronti.

Ma sai la cosa strana di questo? Ci sono 10 personaggi in entrambi i campi di password, in realtà il valore è "g'Szq \ 5tMk". Allora, perché il problema? Ho rispettato la regola, non è vero?

Ci vuole un po 'di indagini in giro per il sito per capire che cosa è andato storto:

Ah, solo lettere e numeri. Oh - e non preoccuparsi di caso, che confonde le cose. Si tratta ora mi solito uscire il palco per i tuoi vecchi e cera lirica per la facilità di brute forcing una password con queste regole, ma, beh, solo tendono a forza bruta una password quando è protetta per cominciare.

La mancanza di sensibilità caso è anche un altro puntatore a come le password possono essere memorizzate, quali sono le probabilità che la colonna password nel database è semplicemente un non-caso confronto sensibile e c'è una query che fa un confronto diretto con il nome utente fornito e la password? Certamente la password fornita all'accesso non viene eseguito l'hashing e rispetto a quella nel database o che non superano il test di sensibilità caso (e lo sappiamo perché sono comunque email password), e sappiamo anche la password fornita non è in corso criptato poi confrontato o che anche fallire. In realtà l'unica reale possibilità che lascia di credibilità è che la password memorizzata viene decodificato quindi confrontato con la password forniti al momento dell'accesso utilizzando un operatore di confronto non tra maiuscole e minuscole.

L'altra cosa strana sul fronte caso è che la password che è stato originariamente inviato a me era tutto maiuscolo. Ora so che non è così che ho creato, quindi forse sono solo la conversione in alto prima della memorizzazione? O in altre parole, la fedeltà si crea nella tua entropia password originale - anche all'interno della lunghezza restrittiva e vincoli di tipo di carattere - si perde non appena l'account è stato creato.

Ma questo è quello che mi piace di quella pagina (per inciso, è mostrato durante il processo di registrazione):

Si può essere al 100% negli acquisti con Tesco.com. Per garantire la vostra sicurezza online vi chiederà la password quando si accede a dati personali o andare a pagare. Questa informazione verrà sempre crittografato in modo che non è possibile per chiunque di accedervi.

Wow - sicuro al 100%! Sempre criptato! Liars.

Sicurezza errori di configurazione

Una delle cose che mi passano un sacco di tempo a guardare attraverso il mio lavoro suASafaWeb è errata configurazione di sicurezza. Questo si riferisce a tali impostazioni piccoli disponibili in pile moderne web al giorno che può facilmente andare a monte e iniziare a divulgare implementazioni interne che poi perdita di informazioni a un utente malintenzionato potrebbe sfruttare.

Un controllo semplice per errori di configurazione della sicurezza è quello di vedere se un gestore Trace.axd è presente. Una delle tre cose di solito accade:

1. E 'presente ed e' garantito esponendo così tutti i tipi di interni cattivi.
2. Un marchio, pagina di errore personalizzata viene restituito educatamente scusa per l'inconveniente (ovviamente il presupposto è che hai atterrato lì per caso)
3. Un errore interno del server viene restituito perché, anche se il gestore traccia non può essere visualizzato, il sito non è configurato in modo da visualizzare i messaggi di errore. Sembra esattamente come questo:

Così, in breve, Tesco ha un caso di errore di configurazione di sicurezza che potrebbe fuoriuscire implementazioni interne del codice. Nizza. In realtà quella schermata infame sopra è colloquialmente nota come un YSOD, o Schermo giallo della morte.

Molto vecchio server web e un quadro

Sai qual è il problema con le applicazioni web di oggi è? Parlano troppo dannatamente tanto .Infatti Tesco parla così dannatamente tanto è felice di dirvi molto a proposito di ciò che è in esecuzione sotto le coperte:

Quello che state vedendo qui sono le intestazioni di risposta restituiti insieme al precedente YSOD. Ho usato Fiddler per controllare le intestazioni e rivelano un po 'di raccontare le cose circa la scelta della tecnologia:

1. Sono ancora in esecuzione su IIS 6, ora a 7 web server anni e per due volte superato (in realtà, sarà tre volte sostituita in un futuro molto prossimo quando Windows Server 2012 con IIS 8 lanci)
2. Sono ancora in esecuzione ASP.NET 1.1. Questo è molto sorprendente - è ormai 9 anni e sostituito da NET 2, NET 3, NET 3.5, Framework 4 e.... quasi NET 4.5..

Ora, niente di tutto questo è per dire che si trattava di cattivi tecnologie nel giorno, non erano, ma è come dire che il disco floppy 5,25 pollici è una buona cosa. Aveva un tempo e un luogo e due di questi sono ormai passati. Il panorama della sicurezza è cambiato in modo significativo dal momento che queste tecnologie in cui avviate e la continua ricerca di nuove generazioni di razza compiere continui progressi nel garantire un'applicazione più sicura per impostazione predefinita.

Non sottovalutare il valore di mantenere componenti software fino ad oggi, in OWASP infatti specificamente chiamare questa nella parte 6 dei loro Top 10 dei rischi sicurezza delle applicazioni web :

Avete un processo per mantenere tutti i vostri software aggiornato? Questo include il sistema operativo, Web / App Server, DBMS, applicazioni e tutte le librerie di codice.

Questo non è necessariamente un alta intensità di esercizio, una volta ogni qualche anno è sufficiente assicurarsi che non sono caduti troppo dietro la palla otto. Certamente non lasciare componenti software chiave ottenere 9 anni e quasi 5 versioni su data.

Incompetenza inconscia

Mai sentito parlare di quattro stadi di competenza ? Si inizia con incompetenza inconscia:

L'individuo non capire o sapere come fare qualcosa e non necessariamente riconoscere il deficit.

Dopo tweeting per le carenze di sicurezza, Tesco ampiamente dimostrato che in termini di sicurezza web, stanno saldamente incollato in questa prima fase di competenza :

Mi piace la natura autorevole di questa risposta e la prodezza software di sicurezza dell'account Customer Care! L'altra affermazione che è sempre una bandiera rossa per me è "standard", nella mia esperienza, questa è la risposta canonica data da persone che in realtà non conoscono la meccanica di quello che stiamo parlando (che ovviamente è quello che che ci si aspetta da un reparto Customer Care). E 'come "best practice" e, mentre si guarda bene su un ponte di PowerPoint, ancora una volta, non è per nulla mezzi, che in realtà capire l'esecuzione di quello che stai parlando.

Chiaramente questo non era tipo da lasciarsi andare senza una risposta:

Ed è allora che abbiamo ottenuto che zinger da prima su:

In realtà è un zinger che è diventato piuttosto popolare:

C'è probabilmente una lezione da qualche parte di non lasciare che i tuoi genitori Customer Care rendere dichiarazioni tecniche attraverso i social media ...

Ma questo è stato veramente il tema per tutta la strada attraverso, Tesco continuamente sopravvalutare la loro abilità di sicurezza mentre chiaramente sotto-consegna nella loro esecuzione. Sì, questo è un account Customer Care ma condiscendente come può sembrare, questo è davvero un caso di incompetenza inconscia non solo da un semi-automatico account Twitter tirando linee standard del libro, ma dalle persone che creano le risorse web.E questo è imperdonabile.

Lezioni per gli sviluppatori di tutto il mondo

Come ho detto fin dall'inizio, diamo una visione costruttiva di Tesco approccio alla sicurezza web e imparare alcune lezioni lungo il percorso. Sono alcuna illusione che Tesco si girerà intorno e sistemare le cose in risposta a questo post, si conoscono su questi problemi abbastanza a lungo e, ovviamente, che hanno scelto di non fare nulla di loro.

Così le lezioni per gli sviluppatori:

1. Memorizzazione delle password dovrebbe sempre essere fatto utilizzando un algoritmo di hashing forte . Dovrebbe essere uno progettato per la memorizzazione delle password e anche l'uso un sale crittograficamente casuale. Inoltre deve essere un lento algoritmo di hashing - leggi il nostro hashing della password è nudo se questo è un concetto estraneo.
2. Recupero password dovrebbe mai accadere . Anzi, non se si è realizzato il passaggio precedente correttamente. Sempre in modo sicuro processo di reimpostazione della password. Leggi Tutto quello che avreste sempre voluto sapere sulla creazione di una sicura funzione di reimpostazione della password per alcuni consigli su questo.
3. Non mescolare il contenuto HTTP nelle tue pagine HTTPS . Se HTTPS è importante per voi - e dovrebbe essere - in modo esplicito riferimento al protocollo HTTPS nei vostri riferimenti oppure ancora più semplice, utilizzare URL relativi protocollo. C'è un sacco di informazioni in OWASP Top 10 per gli sviluppatori NET parte 9:. insufficiente protezione Transport Layer .
4. Sempre inviare cookie di autenticazione su HTTPS . Si tratta di quasi lo stesso valore come la stessa parola d'ordine, dà chi li tiene i diritti per eseguire le operazioni che l'utente che originariamente autenticato al sistema può. Vedi il link al punto precedente per ulteriori informazioni.
5. Non dovrebbero mai essere soggetto a restrizioni entropia la password . Non escludere i caratteri speciali, non tagliare la lunghezza in un breve, limite arbitrario (se si deve, ne fanno 100 caratteri o giù di lì) e sicuramente non implementare un sistema che è case-insensitive. Vedere Chi è chi di pratiche password errate - banche, compagnie aeree e altro ancora per ulteriori errori comuni.
6. Garantire che le configurazioni di sicurezza di base sono corrette. traccia è disattivata, gli errori personalizzati sono attivi, un predefinito reindirizzamento pagina esiste, la modalità di debug è disattivata, ecc Questo è, ovviamente, per ASP.NET, ma ci sono paralleli in pile web. Controlla le tue applicazioni. NET con ASafaWeb .

E, infine, non lasciate che il vostro ego scrittura controlla il tuo corpo non può incassare .GIF lucchetto e le dichiarazioni sulle pagine web non significano assolutamente nulla se quello che sta sotto ha buchi tutto attraverso. In effetti, proprio come quella commento classico Twitter nel paragrafo d'apertura ha dimostrato, rende le cose molto, molto peggio, come dimostra incompetenza inconscia.

Sai qual è la situazione Tesco mi ricorda? Quello che ho scritto sopra è molto, molto simile a quello che ho scritto su Billabong un paio di settimane fa . Non necessariamente le stesse vulnerabilità (anche se alcuni di loro sono molto vicino), ma i fallimenti rampante e rapidamente osservabili nelle pratiche di sicurezza di base. Ho scritto di Billabong , dopo che era stato violato e 21.000 dettagli dell'account pubblicato. Ho concluso il post dicendo:

Ora non sto dicendo che una delle vulnerabilità specifiche individuate sopra sono stati alla base di questa violazione, ma quello che sto dicendo è che essi indicano chiaramente Billabong mai preso sul serio la sicurezza. E 'ovvio che ci sia un processo fondamentale di sicurezza mancanti e se tali vulnerabilità lampante sono presenti - quelli che si possono osservare dal browser solo - che altro si trova all'interno? Il sito era una bandiera rossa - ha reso chiaro che un po 'di sondaggio sarebbe molto, molto probabile che alzare ancora gravi carenze.

Ora pensate a Tesco - che cosa possiamo concludere circa il loro profilo di rischio? Diciamo solo che se si dispone di un account di Tesco, farei maledettamente sicuri di non aver riutilizzato che la password in qualsiasi altro luogo.

Aggiornamento, 30 luglio: Un lettore mi ha indirizzato a questa risposta dal Customer Manager di Tesco servizio un paio di anni fa, quando la questione della sicurezza del sito Web è stata sollevata con loro. Ecco qui la parte interessante:

Ho avuto una parola con il mio team di supporto e ha chiesto loro se sono archiviati con 'una crittografia modo' o di crittografia e si dice che anche se le informazioni non vengono crittografati il ​​livello di sicurezza che circonda la password significa che solo il tecnico più anziano posizioni potrebbero accedere alle informazioni.

Questo è su Pastebin modo da prendere con un grano di sale, ma sicuramente il messaggio è coerente con il livello di comprensione Tesco sembra avere e password memorizzate senza crittografia significa quello che poteva essere coerente con quello che ho osservato in precedenza.

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla

Hashing delle password più forti in. NET con i fornitori universali di Microsoft

Il mese scorso ho scritto circa i nostri hashing delle password che senza vestiti che, per venire al sodo, hanno dimostrato come gli hash SHA salati (ad esempio creata dal provider di appartenenza ASP.NET), ha offerto quasi assenza di protezione da attacchi di forza bruta.Ho intenzione di assumere si ha familiarità con la storia di sfondo su questo (leggere l'articolo prima di questo in caso contrario), ma la linea di fondo era quella di hashing crittografico di password deve essere modo più lento. Non metà della velocità o anche un decimo della velocità, deve essere migliaia di volte più lento.

La conclusione del post era francamente, un po 'insoddisfacente. Perché? Perché in sostanza ha detto: "Se prendi il mio stack preferito utilizzare la tecnologia e l'implementazione di default per memorizzare le password, è insicuro". Sì, ho suggerito approcci alternativi ma questi non ha funzionato in modo nativo con il provider di appartenenze o richiesto l'accesso machine.config in modo che davvero non erano favorevoli al mondo di oggi di ottenere un app nella cloud in 5 minuti .

Ma si scopre che siamo sul punto di risolvere questo per ASP.NET e si può accedere a una soluzione migliore in questo momento. In realtà si può anche essere lo si utilizza già e solo che non lo so, perché fino ad ora, in realtà non è stata pubblicata.

I modelli di progetto sono morti - a lungo i modelli di progetto dal vivo!

Molto di questo ha a che fare con modelli di progetto e il modo migliore per illustrare ciò che sta cambiando è quello di dare un'occhiata a un progetto Web in Visual Studio 2010 e confrontarlo con uno nel 2012.

Cominciamo con un NET 4 Applicazione Web ASP.NET nella versione in uscita.:

Argh - i colori! Spostamento a destra lungo, ora faremo esattamente la stessa cosa in Visual Studio 2012. Si noti che questo è ancora di mira NET 4 così. in teoria , stiamo ottenendo la stessa cosa:

Solo che non sono la stessa cosa. Ecco quello che abbiamo ottenuto nel 2010, quando l'applicazione è stato eseguito:

Ed ecco quello che si ottiene nel 2012:

Questo non sarà una novità per molti di voi, molto è già stato discusso sui miglioramenti ai nuovi modelli. Sono più mobile friendly, si ottiene Modernizr e jQuery UI costruito in più tutti i componenti aggiuntivi sono ora NuGet pacchetti in modo che siano facili da aggiornare. Ci sono molte, tante buone ragioni per utilizzare i nuovi modelli, ma lasciate che vi mostri quello che non si è parlato molto.

Diamo uno sguardo alla configurazione del provider di appartenenze in ciascuno di questi progetti, in primo luogo nel 2010:

< add name = " AspNetSqlMembershipProvider " 
tipo = " System.Web.Security.SqlMembershipProvider "

Il provider di appartenenze SQL è il ragazzo che abbiamo usato per applicare sulla parte superiore di SQL Server (ovviamente) dopo l'esecuzione di aspnet_regsql per creare tutti gli oggetti DB appropriati. Ho fatto un screencast meraviglia 5 minuti su questo lo scorso anno e per la maggior parte, questo approccio ha funzionato bene. Significava il nostro livello di DB finito per assomigliare a questo:

Per motivi di brevità vi risparmio da tutte le stored procedure (ce ne sono 55 di loro), gli schemi (13) e ruoli (altri 13). Come posso mettere questo bene ... ha fatto il database di un pasticcio sanguinoso. Non è solo il volume degli oggetti, sono i "ASPNET" prefissi e dipendenze un'epoca passata di stored procedure (sì, sì, lo so alcune persone discutere con me con veemenza su questo) che ha reso l'atmosfera DB come un po 'di scarico a terra.

Non lasciare che il soffermarsi su ciò, però, ecco cosa troverete nel 2012:

< add name = " DefaultMembershipProvider " tipo = " System.Web.Providers.DefaultMembershipProvider, System.Web.Providers, 
Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35 "

Scott Hanselman ha scritto System.Web.Providers lo scorso anno in relazione a un pacchetto NuGet che tornerò ad un po 'più tardi. Per ora, però, facciamo un po 'di uno sguardo la magia alla base di questo. In primo luogo, non c'è più aspnet_regsql, basta assicurarsi che la stringa di connessione è impostata e l'account dotato di diritti DBO (non ti preoccupare, non deve rimanere in questo modo), quindi eseguire l'applicazione e tenta di eseguire qualsiasi azione che dovrebbe causare il provider di appartenenze per colpire il DB (cioè il log - non importa che non ci sia un conto). Ora diamo uno sguardo verso l'oggetto che sono stati creati:

Tutto qui. Nessun viste, stored procedure, non senza ruoli, senza schemi e nemmeno qualsiasi "ASPNET" prefissi. Questo è il modo in cui le persone normali costruire database! Ok, siamo in grado di discutere la pluralizzazione ma a parte questo, è una struttura DB ragionevole.

Prendiamo in considerazione le modifiche apportate dal vecchio provider di appartenenze SQL, vale a dire nella tabella che memorizza i dati di adesione (vecchio a sinistra, nuovo a destra):

Sono molto simili e francamente le omissioni non stanno andando a perdere da chiunque (una colonna dedicato per la posta elettronica in minuscolo -? Davvero). Ma è ciò che è memorizzato nel campo della password di questo tavolo che è il pezzo forte ...

Ciao a dire PBKDF2

Permettetemi di eseguire ogni applicazione e creare un'unica registrazione con la "password" password (non la gente, questo è solo un esempio!):

	Sale	Password
2010	SkFaUVXansqPe7lm9oHiQA ==	UEWkR0OVsY6sNQuxFgyXCkpUvrY =
2012	z1h310KsaE/FmxxXNHUiXg ==	saRtN7Aju vqYfX25c1QpnxESIHsy1s6UiR5z7UwixM + =

Ok, quello che sta succedendo qui? Perché è l'hash nel modello 2012 saltato fuori? Algoritmi di hash creano sempre la stessa lunghezza cifra indipendentemente dalla stringa di input, si deve dire che qualcosa di diverso sta accadendo. E non vi è - ciò che vedete qui è il risultato del provider di appartenenze universale che ora è chiamata direttamente nel metodo Crypto.HashPassword che abbiamo avuto in System.Web.Helpers per un po 'adesso.

Una delle grandi cose su porzioni significative di ASP.NET attualmente in fase di open sourceè che è più facile che mai a dare un'occhiata sotto le coperte. Per coloro che vogliono vedere cosa sta succedendo, l'intera implementazione crittografia è finita su CodePlex . La cosa più importante per questo post, i commenti che lo rendono molto facile da capire cosa sta succedendo:

 / * =======================
 * FORMATI password hashing
 * =======================
 * 
 * Versione 0:
 * PBKDF2 con HMAC-SHA1, sale a 128-bit, 256-bit sottochiave, 1000 iterazioni.
 * (Vedi anche: SDL linee guida crittografia v5.1, Parte III)
 * Formato: {0x00, sale, sottochiave}
 * /

E non si tratta - il provider di appartenenze sta attuando 1000 iterazioni di SHA1 così dal punto di vista della forza bruta, questo impone un notevole aumento del carico di lavoro sulla implementazione di default nel vecchio provider di appartenenze SQL.

In questo post precedente debolezza hashing ho scritto, ci sono voluti 44 minuti e 56 secondi per risolvere il 63% delle password comuni in un campione di quasi 40.000. Se il campione ha utilizzato il nuovo provider partecipazione universale, che il tempo avrebbe fatto saltare fuori per più di un mese - 31,2 giorni, per l'esattezza. Dove ho già usato il paradigma della seduta attraverso un paio di episodi di The Family Guy, questo è come guardare La minaccia fantasma back to back 330 volte. Chiaramente questo rende l'esperienza dolorosa che molti scoraggiare un hacker determinato.

Ora, naturalmente, questo non è mai stato su come rendere le password indecifrabile e, come per la maggior parte gli aspetti di sicurezza del software si tratta di aumentare il grado di difficoltà ad un livello che lo rende più fattibile per un numero maggiore di persone. Sarà la barra sollevata, è improbabile che si crepa hacktivisti password da una corsa del mulino sito web? Sì, molto probabile. Ma si fermerà il governo degli Stati Uniti da craccare le password su un sito web facilitare l'attività terrorista? Non scommettere su questo.

L'impatto sulle prestazioni

Che cosa significa questo per le prestazioni? Quanto tempo ci vuole un accesso ora prendere? E sarà la profezia di utilizzo della CPU a livelli inaccettabili essere vero? Diamo uno sguardo.

Che cosa ho intenzione di fare è accedere al sistema 1.000 volte e vedere quanto tempo ci vuole con il vecchio provider e poi con il nuovo. Ecco cosa sta succedendo:

var = sw nuovo Cronometro ();
sw.Start ();
per ( var i = 0; i <1000; i + +)
{
  Appartenenza . ValidateUser ( "troyhunt" , "password" );
}
sw.Stop ();
passwordDuration.Text = sw.ElapsedMilliseconds.ToString ( "n0" );

Ora tenere a mente che non si può davvero fidarsi della classe Stopwatch , almeno non con un certo grado di accuratezza, ma questo è un bene per durate indicative. Ho eseguito lo script di cui sopra con entrambi i provider di appartenenze a volte manciata in IIS Express e una media di fuori (per inciso, i risultati sono stati molto simili quando si esegue direttamente sotto IIS). Ecco che cosa ho ottenuto:

	SqlMembershipProvider	DefaultMembershipProvider
1000 iterazioni	2941 ms	102164 ms
Accessi al secondo	340	10

Ci sono un paio di cose interessanti da notare qui:

1. Il nuovo provider è più lento, ma non 1000 volte più lento. Questo perché il processo di hash stessa è solo una piccola parte di accesso. Oltre a questo vi è anche la gestione delle connessioni ADO.NET, l'esecuzione di query (più su quello a breve) e le spese generali per altre lavorazioni oltre la semplice generazione di un hash.
2. Dal punto di vista dell'utente, questo non è in alcun modo una durata troppo lungo per un accesso. Come per il punto precedente, c'è un mucchio di roba che succede quando si accede, ma la linea di fondo è che l'intero processo è in corso circa 100ms, che per una attività volta per sessione, è bene.

Ma per quanto riguarda l'impatto sulla CPU? Voglio dire in base alla progettazione di questi algoritmi di hashing hanno lo scopo di farlo funzionare piuttosto difficile, sta andando ad iniziare a causare picchi di brutto in termini di utilizzo efficace DoS'ing l'applicazione? Ecco quello che ho osservato in 1.000 corse sequenziali:

Questo è usare circa il 7,5% della CPU per la costante, back to back hashing. Ora, naturalmente, questo è solo accadendo in un singolo thread e la storia inizia a cambiare abbastanza rapidamente con più esecuzioni simultanee. Sia come sia, abbiamo ancora registrato 1.000 persone in tutto circa un minuto e mezzo, quindi mi bastone mia affermazione dal post precedente che la popolarità di quel livello è un problema mi piacerebbe avere! Effettivamente essere coscienti del overhead aggiuntivo, ma è improbabile che averlo causare problemi a meno che non hai a che fare con scala serio.

Quindi, parlando di esecuzione delle query, ricorda come il vecchio fornitore ha creato tutte quelle procedure memorizzate (tra gli altri oggetti di DB)? Ecco cosa avveniva quando vi siete collegati:

Una stored procedure. Tutto qui. Andando avanti nel provider universale, ecco cosa sta succedendo alla fine SQL per un accesso singolo :

DBA - mettere giù i forconi! Questo è dal RC di Visual Studio 2012 versione con 1.0 di fornitori universali e per fortuna le query eccessive sono qualcosa che Microsoft sa :

Ok, è eccessivo, ma almeno i ragazzi sono sul caso e chiaramente le cose che stanno rettifica. Speriamo che sarete in cima a questa prima VS2012 entra nel vivo e la gente inizia a creare dipendenze più su di esso. Per fortuna, perché i nuovi modelli associare la libreria per NuGet, quando un aggiornamento è disponibile sta andando essere un processo di aggiornamento molto semplice davvero.

Per l'amor di interesse, l'implementazione corrente sta eseguendo due serie identiche di quattro domande che si presentano come segue:

1. Selezionare il record utente e praticamente ogni colonna su di esso con il nome utente fornito al momento del login
2. Selezionare un record utente tagliata verso il basso da parte dell'utente ID della query precedente (non so perché una seconda query è necessario ...)
3. Aggiornare il LastLoginDate sul tavolo dei membri
4. Aggiornare il LastActivityDate sul tavolo Utenti

La seconda query sembra un po 'ridondante e quindi ripetendo tutti e quattro sembra moltoridondante quindi speriamo che i miglioramenti che Erik si allude nella sua Tweet portare questo fino ad un molto più DB amichevoli tre query.

BTW - anche questo è un buon esempio di dove profiling query DB è molto importante, soprattutto quando ci sono astrazioni tra il codice e la query, quali i fornitori o un ORM.Lancia il SQL Profiler e assicurarsi di sapere cosa sta succedendo.

Meglio hashing per grandi e piccoli

Una delle grandi cose su i modelli che vengono confezionati in Visual Studio 2012 è una dipendenza crescente NuGet. Questa è una mossa molto cosciente da parte di Microsoft - meno dipendenza da componenti del framework di base che solo vengono aggiornate ogni pochi anni e più dipendenza da pacchetti che possono essere aggiornati e spinto in modo indipendente.

Quando diamo uno sguardo all'interno dei pacchetti già installati nel modello VS2012, ecco quello che c'è dentro:

La buona notizia è che ora possiamo solo tornare subito su VS2010 e tirare i pacchetti stessi in:

O per i ninja della console:

PM> Install-Package Microsoft.AspNet.Providers.Core

Ora tutto ciò che facciamo è salto nel web.config e modificare il tipo di provider di appartenenze dal vecchio SqlMembershipProvider al DefaultMembershipProvider nuovo (solo i valori indicati in precedenza, più una trasformazione simile per il provider di ruoli, se si sta utilizzando), ha colpito il fidato F5 pulsante quindi tenta di accedere. Ora diamo un'occhiata al database:

Tutte le tabelle sono evidenziati i nuovi, proprio come abbiamo visto in precedenza quando si inizia con il modello 2012 da zero. Allora è così - hashing di oggi (domani è se si considera che siamo ancora in RC) è facilmente raggiungibile in VS2010.

Gli hash non è hash

Aggiornamento di un 2010 modello di progetto è facile - e potenzialmente catastrofico. Il problema è semplicemente che se si dispone di un esistente progetto con esistenti hash, seguendo il consiglio di cui sopra fondamentalmente rompere l'autenticazione. Anche se la migrazione di tutti i conti delle tabelle vecchio al nuovo (che è abbastanza facile), gli hash memorizzati dei vecchi tempi non corrisponderanno alle nuove hash dal modello PBKDF2.Nessuno sarà in grado di accedere.

Ora, naturalmente, ci sono modi per codificare la tua via d'uscita da questo, è solo bisogno di sapere quale algoritmo di hash è stato utilizzato per ogni utente. Se conosci questa si può sempre l'autenticazione con il vecchio algoritmo poi una volta verificato, hash la password con il nuovo algoritmo. Ma il provider di appartenenze non ti dà questa possibilità, ne avrete bisogno per iniziare tirandolo a parte e attuare la propria logica.

L'altra opzione è che si può semplicemente rotolare verso il nuovo modello quindi chiedere agli utenti esistenti di reimpostare le password. Si ha una sicura funzione di reimpostazione della password , non è vero? In ogni caso, questo non sarà possibile in molti casi, ma se c'è un piccolo gruppo di utenti che si è in grado di costringere a compiere un processo un po 'scomoda, che è una facile via d'uscita.

Se si desidera ripristinare su un sistema esistente, ecco quello che vi serve per i provider di appartenenze e il ruolo (questo non riguarda il provider di profili):

INSERT INTO dbo . Applicazioni SELEZIONA ApplicationName , ApplicationId , 
Descrizione FROM dbo . aspnet_Applications
 GO

INSERT INTO dbo . Ruoli SELEZIONA ApplicationId , ID ruolo , RoleName , Descrizione 
FROM dbo . aspnet_Roles
 GO

INSERT INTO dbo . utenti SELEZIONA ApplicationId , UserId , UserName , IsAnonymous ,
 LastActivityDate FROM dbo . aspnet_Users
 GO

INSERT






INSERT INTO dbo . UsersInRoles SELEZIONA * FROM dbo . aspnet_UsersInRoles
 GO

Ma ancora una volta, ricordo, nessuno sarà in grado di accedere fino a quando non esegue un reset della password.

Un non-nativo alternativa

Nel post precedente ho dato una menzione resoconto di biblioteca Zetetic, che si integra con il provider di appartenenze e supporta bcrypt e PBKDF2 . Mi è piaciuta la facilità di tirare da NuGet ma lamenta il fatto che ha richiesto l'installazione e la modifica GAC machine.config, che ha escluso di correre sulle moderne implementazioni stile PaaS come sto utilizzando in AppHarbor o che troverete in Azure.

Per fortuna la gente oltre a Zetetic sono riusciti a riunire tutto ciò che a livello di computer dipendenza su in una soluzione piuttosto veloce, infatti è ora possibile utilizzare la propria libreria per implementare l'hashing delle password sicure per ASP.NET in una sola riga . Quella riga aggiunge semplicemente l'applicazione di mapping Zetetic algoritmo della app in caso Application_Start dei Global.asax.cs:

CryptoConfig . AddAlgorithm (   typeof (Zetetic.Security. Pbkdf2Hash ), "pbkdf2_local" );

Un modo che l'attuazione Zetetic differisce da quella del supporto web da Microsoft è che invece di 1000 iterazioni di un hash, stiamo guardando a 5.000. Dal punto di vista della forza bruta che stiamo letteralmente guardando cinque volte il carico di lavoro. Mentre vi è forse un sovraccarico di usabilità e le infrastrutture implicazione a questo, migliora certamente la sicurezza.

In realtà, ho specificamente testare la durata del metodo HashPassword nelle helper web e costantemente ottenuto risultati di circa 17ms. Ho anche testato specificamente tempi per una scala hash SHA1 e ho visto i risultati che variano da 1/1.000 a 1/3000th di ciò HashPassword sta facendo, in cui è all'interno della gamma di quello che ti aspetteresti (ricordiamo che classe Stopwatch affidabilità cosa, in particolare per tempi molto piccoli).Per l'hashing delle password, Sarei felice di fare un aumento di cinque volte su ciò che sta facendo HashPassword in, un posto più vicino a 100ms sarebbe preferibile per la maggior parte dei casi in applicazioni web e anche se GPU sfornerà attraverso di loro molto più veloce che mette solo le screpolature che fuori molto più in là della portata senza imporre quello che avevo considero una latenza inaccettabile per l'accesso.

Conclusioni

In entrambi i provider di appartenenze e la biblioteca universale Zetetic, sicuramente il mondo perfetto sarebbe quello di sfruttare la possibilità di personalizzare il carico di lavoro di hash? Come ho discusso nel post precedente, tutti hanno bisogno per trovare il loro posto proprio dolce tra impatto positivo la sicurezza e negativo impatto sulle prestazioni. Zetetic cita forse incapsulare questo all'interno di un'altra libreria e siamo ancora sentito niente da Microsoft sulla loro attuazione.

Ma a prescindere messa a punto del carico di lavoro, resta il fatto che dal punto di vista della sicurezza il nuovo provider partecipazione universale ci dà una mille volte miglioramento rispetto al vecchio. Nel libro di nessuno, questa è una cosa davvero molto buono.

Il lato negativo, però, in realtà si sta solo andando a utilizzare questo in nuove applicazioni e tutto ciò che hai già costruito con il fornitore originale rimane, francamente, poco meglio che se non memorizzazione di dati crittografici esisteva affatto. Poi ci sono quegli otto query SQL, non è buono, ma un problema noto ed essendo fissato dopo di che può essere tirato giù da NuGet con il minimo sforzo a tutti (non dimenticate di guardare per questo se si sta già utilizzando il nuovo fornitori).

Personalmente, mi sto dando un pollice in alto, tanto che sto tirando subito il vecchio modello di ASafaWeb , la migrazione dei conti chiedendo poi la gente a eseguire una reimpostazione della password. Ho il lusso di un piccolo pubblico di private beta tester che usano le caratteristiche di account esistenti e posso permettermi di metterli attraverso un po 'di disagio. In questo modo ora prima di raccogliere un maggior numero di account utente in app (cosa che scriverò molto presto), secondo la mia opinione è un investimento intelligente.

Quindi, in conclusione, è una buona cosa. Vai a prendere il fornitore universale e se è troppo difficile passare dal modello di appartenenza esistente, prego però ascolteranno che i vostri hash non vengono divulgati perché c'è molto poco di loro tutela se lo fanno!

Corso Visual Studio - Corsi Visual Studio
Corso .Net- Corso Dot.Net - Corso Vb.net
Corso C# - Corso PHP - Corso Joomla