Qual è il modo migliore per mantenere in sicurezza password sicure?

Ora che la domanda è stata rivista, capisco cosa stai cercando di fare molto meglio.

La risposta breve è: Basta memorizzare la password del database in chiaro, nell'oggetto di sessione (lato server) . Non puoi fare di meglio.

Se lo desideri, puoi crittografare la password del database e memorizzare la password crittografata nell'oggetto di sessione, ma non ha davvero senso, perché dove hai intenzione di memorizzare la chiave? Non esiste un posto in cui è possibile memorizzare la chiave che è molto più sicura rispetto all'oggetto di sessione. È possibile archiviare la chiave in un file di configurazione o in una variabile globale, ma in realtà, non sono sicuro che ciò aggiunga sicurezza a qualsiasi minaccia realistica. È difficile capire perché preoccuparsi: mi sembra un teatro di sicurezza.

Quindi, basta che l'utente inserisca la password del database all'inizio della sessione, memorizzi la password del database nello stato della sessione e si faccia con esso. Non c'è niente di meglio che puoi fare.

E per l'amor del cielo, usa una buona pratica di programmazione di applicazioni web. Controlla le risorse OWASP. Assicurati di avere familiarità con le vulnerabilità web comuni viste nel mondo web. Scrivi il tuo codice attentamente, usando buone pratiche di sicurezza. E chiedi a qualcun altro che sa qualcosa sulla sicurezza di fare una revisione della sicurezza del tuo codice. Se c'è una vulnerabilità di sicurezza nel tuo codice, accadranno cose brutte.

Non è necessario mantenere le credenziali in un formato recuperabile, anche se sono crittografate. Se la tua applicazione di back-end può decodificare qualcosa, allora potrebbe farlo chiunque possa hackerare la tua applicazione di back-end. In realtà, devi presumere che prima o poi la tua applicazione back-end sarà compromessa e progettata pensando a questo.

Il metodo più sicuro sarebbe probabilmente quello di memorizzare le password come salate e hash con un algoritmo come bcrypt o PBKDF2 . In questi giorni, l'hashing / salting regolare con qualcosa come MD5 o SHA1 non è abbastanza sicuro. Programmi come hashcat possono sfogliare velocemente i file delle password di cracking. Questo articolo su hashcat è un'ottima lettura .

È bello che tu sia preoccupato per qualcuno che ha accesso al negozio di biscotti. I cookie sono fondamentalmente equivalenti per le password, quindi se li stai archiviando, probabilmente dovrebbero essere anche degli hash salati.

E davvero, sembra molto facile, ma ci sono molti casi d'angolo. Se il tuo framwork dell'applicazione ha già un modo per fare la gestione delle sessioni, dovresti probabilmente usarlo invece di farlo da solo.

Dai un'occhiata al pacchetto Cheat Sheet di OWASP per vedere alcuni buoni consigli.

Primo: sei sicuro? Innanzitutto, assicurati che veramente sia necessario archiviare le password in chiaro o in forma recuperabile. La tua domanda non ha spiegato perché è necessario. Se si verifica una violazione della sicurezza, tutti saranno in grado di indovinare la propria decisione e, se dovesse risultare che le password sono state memorizzate in formato recuperabile, la propria organizzazione potrebbe subire una perdita di reputazione. Quindi, assicurati che sia davvero necessario.

Successivo: definisci il problema. Quindi, cosa stai cercando di fare esattamente? La domanda non è stata molto chiara, quindi farò qualche ipotesi. Se queste ipotesi non sono accurate, modifica la domanda dopo aver dato un po 'più di riflessione.

Presupposto: gli utenti accedono alla tua applicazione web, chiamiamola CyrilApp, utilizzando un nome utente e una password per la tua applicazione. Volete che il vostro codice sia in grado di accedere ad un altro account di loro - ad esempio, la loro e-mail tramite IMAP - quindi chiedete loro di inserire il nome utente e la password e-mail, affinché il vostro codice server possa essere utilizzato in seguito. Ora vuoi sapere come conservare la password e-mail nel modo più sicuro possibile. Riguarda l'idea?

Se questo è il problema, devi considerare diversi problemi: come conservare le password di posta elettronica? quando si recuperano le password e-mail, come utilizzarle in modo sicuro? come limitare l'accesso alla password e-mail?

Archiviazione. Un'opzione consiste nel memorizzare le password in un modulo di sicurezza hardware (HSM) o crittografate in una chiave gestita da un HSM. Tuttavia, gli HSM sono molto costosi, quindi potrebbe non essere fattibile.

Una soluzione più pragmatica è quella di creare un servizio separato, chiamiamolo EmailPasswordStore, che esegue una funzione semplice e stretta, è accuratamente codificato ed è considerato sicuro per archiviare le password e-mail in modo sicuro. Potrebbe offrire un'API che consente al codice CyrilApp di memorizzare la password di un utente (quando viene inserita) e un'API che consente al codice CyrilApp di richiedere l'uso della password (ad esempio, EmailPasswordStore potrebbe aprire una connessione IMAP a il server IMAP, invia il nome utente e la password e-mail dell'utente e quindi inoltra i byte avanti e indietro tra CyrilApp e il server IMAP.

In questa architettura, le password delle e-mail non lascerebbero mai lo spazio di deposito di EmailPassword, e il lavoro di EmailPasswordStore è quello di assicurarsi che questo rimanga il caso - anche se CyrilApp è compromessa o il resto dei tuoi server sono pwned da un utente malintenzionato, lo strumento EmailPasswordStore deve impedire all'utente malintenzionato di ottenere le password di posta elettronica. È possibile eseguire EmailPasswordStore su una macchina separata (o possibilmente in una VM separata), con una VPN tra CyrilApp e EmailPasswordStore, ed eseguire un'accurata revisione della sicurezza del codice di EmailPasswordStore.

Utilizza. Non è sufficiente archiviare le password di posta elettronica in modo sicuro, perché a un certo punto vorrai usarle. Se si archiviano le password e-mail in qualche forma crittografata e quindi le si decodifica quando si desidera utilizzarle, non si ottengono molti vantaggi in termini di sicurezza: un utente malintenzionato che compromette la propria applicazione Web potrebbe sedersi tranquillamente e rubare ogni password utilizzata , o forse anche decifrare tutte le password stesse. Quindi, hai bisogno di alcuni controlli di utilizzo.

L'architettura EmailPasswordStore proposta sopra fornisce questi controlli. Utilizza la stessa password email e non rivela mai la password dell'applicazione Web CyrilApp. Prova a vedere se riesci a fare qualcosa del genere nelle tue impostazioni.

Limitazione dell'accesso. Infine, potresti voler limitare chi può richiedere a EmailPasswordStore di utilizzare la password. Un buon punto di partenza è per l'EmailPasswordStore per autenticare il servizio che si sta connettendo ad esso; ad esempio, potresti impostare una VPN tra CyrilApp e EmailPasswordStore e assicurarti che EmailPasswordStore rifiuta tutti gli altri tentativi di connessione.

Un'architettura più sofisticata potrebbe verificare l'identità dell'utente attualmente connesso e limitare l'accesso solo alla password di posta elettronica. Ad esempio, EmailPasswordStore potrebbe memorizzare un elenco delle password hash utilizzate dagli utenti per accedere a CyrilApp e richiedere a CyrilApp di inviare la password di accesso dell'utente a EmailPasswordStore per la verifica prima di sbloccare la password e-mail dell'utente. Tuttavia, questo potrebbe non essere necessario in alcune impostazioni.

Ulteriori letture. Vedi anche Dove posso archiviare in modo sicuro la chiave per un sistema in cui la fonte è visibile? e dove memorizzare una chiave per la crittografia .

• Quando l'utente accede tramite il frontend, il login e la password vengono inviati in chiaro (raccomanderò l'uso di HTTPS). Il backend proverà a connettersi al database, se avrà successo, crittograferà login e password usando Blowfish e li restituirà al frontend.

Dovresti invece usare un hash salato.

• Per qualsiasi richiesta successiva, il frontend dovrà inviare il login / password crittografato, senza mai conoscere quello chiaro, solo quello crittografato. Se qualcuno accede ai dati di questo utente (ad esempio XSS), sarà in grado di accedere solo alle credenziali crittografate, non a quelle chiare.

Con l'implementazione di blowfish in javascript? Se un utente malintenzionato conosceva la password crittografata, poteva semplicemente disattivare javascript e inviarlo senza conoscere l'originale.

• Se un utente malintenzionato può eseguire un MITM, solo il primo accesso è rischioso, tutte le richieste successive saranno con le credenziali crittografate.

Se qualcuno prova a MITM HTTPS riceverai un avviso di certificato non valido (a meno che non sia riuscito a ottenere la tua chiave privata o lo abbia forgiato in qualche modo, questo è molto improbabile) nel qual caso smetti di provare a caricare la pagina e nessun danno è fatto.

Il tuo server front-end dovrebbe occuparsi dell'autenticazione e dovrebbe memorizzare password crittografate. La password hash verrà confrontata con l'hash su questo server.

Assicurati che la tua password criptata sia salted . In questo modo se i dati vengono rubati, sarà più difficile decifrare e le tabelle arcobaleno saranno meno efficaci.

Il server back-end conterrà le password in chiaro e accetterà solo le connessioni dalla rete interna. Qualsiasi modifica della password verrà aggiornata qui, quindi verrà aggiornata sul server front-end.

Assicurati di scrivere regole rigide del firewall per questo server. Consenti solo aggiornamenti a questo server, rilascia tutti altri pacchetti.

Questo server non dovrebbe poter accedere da Internet e probabilmente dovrebbe essere aggiornato dai server locali.

Come per MITM, non c'è nulla di efficace da impedire.

Ho visto una configurazione in cui le password sono state crittografate con rsa nel backb db insieme alle loro rappresentazioni hash e salt. La chiave di decodifica è stata mantenuta su una macchina separata senza internet. Potrebbe recuperare le password dal backend per decrittografarle e reinserirle crittografate. Il server di backend potrebbe quindi inviare gli hash al server front-end. Il server front-end era l'unico che si affacciava su Internet.

Prima di tutto NO . Di solito c'è un modo migliore.

Ad esempio, la password viene memorizzata come hash e, quando l'utente esegue l'accesso e si autentica correttamente con l'hash, si tiene la password in memoria solo per la sessione, utilizzandola per qualsiasi connessione debba essere effettuata, quindi dimentica la password non appena non ne hai più bisogno. Non viene mai memorizzato.

In secondo luogo, se hai bisogno di memorizzare la password per alcuni requisiti assurdi, un buon modo per renderlo semi-non reversibile è usare la crittografia a chiave pubblica (ad esempio RSA). La crittografia con una chiave pubblica (per la quale non è presente alcuna chiave privata) non è completamente diversa dall'hash. Non è abbastanza buono come l'hashing, ma è molto meglio della crittografia simmetrica (come blowfish, aes, ecc.) Perché la password per decriptarlo non è presente. Il che mi ricorda: la chiave privata NON DEVE essere accessibile dall'ambiente pubblico, non sullo stesso server, non sulla stessa rete, ecc. La chiave privata dovrebbe essere utilizzata solo per le stupide emergenze richieste dal tuo progetto.

Notate che la crittografia a chiave pubblica, come comunemente implementata, è in realtà una crypto simmetrica con un wrapper RSA. Scopri quali protocolli stai effettivamente utilizzando.