Sta utilizzando il nome utente crittografato con la password come chiave per una buona memorizzazione delle password?

Quello che fai really è l'hashing: hai costruito una funzione di hashing con un codice a blocchi. Per inciso, "la crittografia di un valore conosciuto con la password come chiave" è come il tradizionale schema di crittografia basato su DES per Unix è stato progettato.

Sul lato positivo, la tua costruzione include il nome utente, che fornisce parzialmente l'effetto di un salt: il cracking parallelo è scoraggiato perché due utenti che utilizzano la stessa password finiranno con due output hash distinti. "Parzialmente", poiché al momento della modifica della password, l'utente mantiene il suo nome utente, quindi una qualche forma di parallelismo è ancora possibile qui; e, forse ancora più importante, lo stesso nome utente può essere utilizzato in diverse app Web (ad esempio "admin"), il che rende le tabelle precalcolate utili (e il punto del sale è prevenire il parallelismo, in particolare l'uso efficiente delle tabelle precalcolate).

Dal lato negativo:

• Questa è una costruzione fatta in casa . 50 anni di ricerca sulla crittografia ci hanno insegnato che la crittografia fatta in casa è molto rara. In effetti, possiamo "sapere" che un dato algoritmo è corretto solo attraverso anni di revisione da parte di altri ricercatori esperti, e gli schemi fatti in casa, per definizione, non hanno mai avuto molto di una recensione.

• Questo è limitato. Rijndael è un codice a blocchi che può accettare chiavi fino a 256 bit; quindi, se si utilizza la password come chiave, allora deve rientrare in 256 bit. Questo impedisce di usare le cosiddette "passphrase" che possono essere forti ma facili da memorizzare le password usando un sacco di spazio per la sua entropia (il cervello umano non ama l'entropia concentrata, ma è felice con l'entropia diluita).

• È troppo veloce e questo è il più grande problema immediato nel tuo schema. Con un PC di base, un utente malintenzionato può provare molte password al secondo, in particolare dal momento che i PC moderni hanno codici opzionali dedicati per AES . Con un PC quad-core, si dovrebbe essere in grado di provare fino a circa mezzo miliardo di password al secondo . Non molte password scelte dall'utente possono sopravvivere a così tanto tempo.

Se sei interessato a come funziona l'hashing della password, leggi questo . La risposta breve, tuttavia, è sempre la stessa: non usare uno schema fatto in casa; usa bcrypt .

Le altre risposte già dicono No, "roll your own" is rarely a good password storage scheme and yours is no exception.

Vorrei aggiungere: non è un buon schema per archiviare / comunicare il nome utente.
Stai praticamente facendo l'hashing. Niente di male in questo, tranne:

• Stai utilizzando una funzione non progettata come funzione di hash sicura. Essendo un cifrario è sicuramente sulla "scala sicura" della scala, ma l'hashing implica anche evitare le collisioni di hash. Una cifra non è in genere ottimizzata per non avere collisioni. È noto che gli One-Time Pad sono indistruttibili, poiché hanno il numero massimo di collisioni. Quindi un codice strong fa un hash povero in termini di collisioni.
• Se memorizzi nome utente e nome utente -codificato-con-password ci sono più vulnerabilità:
  • In questo caso, se il tuo database viene violato l'autore dell'attacco non solo ottiene the username encrypted with an unknown password . Ottiene anche il testo chiaro aka. nome utente. Quindi è una chiara analisi del testo, che per alcuni algoritmi è molto più semplice della forza bruta.
  • Collisioni hash: l'autore dell'attacco non ha bisogno di sapere la password ma qualsiasi che produce la stessa crittografia per un testo chiaro breve e specificato. Questo potrebbe essere ancora più semplice dell'analisi del testo in chiaro.
• Se non memorizzi il nome utente ma fai affidamento su un singolo valore trasmesso combinato, ci sono ancora degli svantaggi:
  • In questo caso, probabilmente non hai considerato le collisioni di hash. Che dire di due utenti, che hanno lo stesso nome utente? Che ne dici di due idioti, che hanno lo stesso nome utente e la stessa password? Che dire delle collisioni di hash di diversi nomi utente e password per puro caso (ricordate: le cifre non sono ottimizzate per evitare collisioni!)?
• In ogni caso c'è l'attacco "Passa l'hash": un utente malintenzionato che annusa le comunicazioni di rete può semplicemente emulare l'applicazione per trasmettere gli stessi dati dell'utente. Hai fatto qualcosa a riguardo? In caso contrario, è per questo che non dovresti "eseguire il rollover".

Spesso il protocollo di trasmissione è tanto importante quanto la sicurezza quanto una strong funzione crittografica, indipendente dall'hashing e dalla crittografia. Un cattivo protocollo può esporre la tua funzione ad attacchi non adatti, in particolare "attacchi di canali laterali" come "passare l'hash" o "uomo nel mezzo" che aggirano l'effettiva criptoanalisi sul lato dell'attaccante.

Lo schema di archiviazione della password potrebbe essere soggetto a tali attacchi, perché non è stato specificato, se il nome utente è anche memorizzato in testo non crittografato. Così facendo esponi il tuo schema agli attacchi descritti sopra. Non memorizzarlo in testo chiaro potrebbe richiedere un protocollo di trasmissione soggetto ad attacchi come descritto sopra.

Ecco alcune considerazioni aggiuntive sui protocolli di trasmissione nel tuo caso, leggermente generalizzate:

Se non hai fatto nulla per l'attacco "passa l'hash", allora il tuo schema è peggiore di un sacco di altri. Un utente malintenzionato non ha bisogno di hackerare la tua base di dati né crackare il tuo codice. Ottiene ciò di cui ha bisogno gratuitamente sniffando il traffico di rete.

L'HTTPS può essere sufficiente, sebbene possa essere aggirato da "man in the middle": gli utenti non controllano i certificati di autenticazione, vero? Un utente malintenzionato apre semplicemente una connessione non autenticata ma crittografata al tuo utente e qualsiasi altra connessione sia prevista per te.

Un ulteriore schema Challenge-Response può aggiungere sicurezza. Prima di accedere, il client riceve una stringa casuale (una sfida) una tantum che deve compilare nell'hash (risposta). Un utente malintenzionato non può riutilizzare un hash annusato, perché la richiesta non viene riutilizzata.
Ma ancora una volta, non è necessario "eseguire il rollover".

TL; DR: usa scrypt. Perché tirare il tuo quando c'è un ottimo standard?

(Considero scrypt superior to bcrypt, ma bcrypt è ancora miglia migliore di grow-your-own.)

Una cosa che ti manca finora è lo stretching. Immagina di essere hackerato e il tuo database viene scaricato su pastebin - può capitare a il meglio di noi .

Le persone che usano 123456 o una delle altre 20 password migliori verranno scoperte in qualunque modo tu faccia, e non meritano di meglio. Per le persone che hanno scelto password moderatamente valide, fa la differenza se il tempo che l'utente malintenzionato deve spendere per voce è dell'ordine di microsecondi o secondi.

Inoltre non stai salendo - immagina che due delle tue applicazioni web vengano violate e che una persona abbia account con lo stesso nome utente con la stessa password per entrambi. Mi sembra che l'attaccante ottenga identici numeri cifrati in entrambe le discariche, dicendo loro che c'è un'offerta crack-one-get-one-free.