Schema di memorizzazione delle password decisamente più sicuro?

È possibile delegare l'autenticazione a un server diverso all'interno della rete, a cui il server principale comunica tramite un servizio web o qualsiasi protocollo desiderato. In questo modo un hacker può accedere al tuo server e ai tuoi file primari e non ottenere ancora nulla.

Il server di autenticazione può essere bloccato molto più stretto, riducendo al minimo l'area di superficie per l'attacco - per non parlare del fatto che l'attacco dovrebbe avvenire via il tuo server primario.

Non crittografare le password - (unidirezionali) su di esse.

Non dovresti aver bisogno o vuoi decrittografare le password. Se lo fai, non sei così preoccupato per la sicurezza.

La sicurezza è sempre un compromesso con le prestazioni.

Gli algoritmi di hash standard (md5, sha1) sono sicuri a meno che il sale non sia noto all'attaccante.

L'uso di un algoritmo di hashing lento rende le password sicure anche se un utente malintenzionato ha accesso al codice e all'hash memorizzato.

La funzione crypt è probabilmente quello che vuoi in php. L'utilizzo di un numero elevato di cicli di crittografia renderà più lento il calcolo dell'hash di un determinato input; ciò lo renderà impossibile alla forza bruta ma renderà anche lento per te / la tua applicazione verificare che la password immessa dall'utente sia la stessa dell'hash che hai archiviato - questo è il compromesso.

Raddoppiare le tecniche non farà nulla per aumentare la sicurezza - il parametro di crittografia round in the sale significa che sta alimentando l'output di hashing della stringa di input nell'algoritmo di hashing che molte volte - Stai proponendo un bespoke + 1, basta aggiungerne uno al numero di round che si desidera eseguire. Inoltre, per l'esempio dato sha1(crypt[blowfish.salt],salt) questo ti impedirebbe di essere in grado di confrontare correttamente l'hash con l'input dell'utente - da Il primo esempio :

You should pass the entire results of crypt() as the salt for comparing a password

Senza l'output di crypt, non puoi confrontare l'input dell'utente con l'hash già generato.

Schema di archiviazione delle password più sicuro? Un strong hash lento (come bcrypt) con diversi byte random salt che impedisce di attaccare le password in parallelo con una tabella arcobaleno. La crittografia delle password deve essere utilizzata solo se assolutamente necessario: ad esempio, sei registrando una password per un sistema esterno che non controllare che sia troppo stupido per utilizzare un protocollo sano di concessione dell'accesso di terze parti (come openauth), quindi è necessario registrare la password degli utenti su quel sistema.

And lastly, I know this is ridiculous but I'm uncomfortable with the possibility of 2 passwords having the same hash result. I know, the possibilities of somebody guessing the other value that has the same hash is veeeeeery low, but HEY, we're in 2012!, weren't we supposed to have flying cars and computers that could render Avatar movie in an hour already? :P There should be something better already...

Sì, il tuo disagio è ridicolo. Se si usa dire SHA256 (256 bit) o bcrypt (184 bit), la possibilità di ottenere due password casuali sullo stesso hash è straordinariamente improbabile (circa 10 ⁶⁶ volte meno probabile di vincere il jackpot powerball ). Per SHA256 tutte le password dovrebbero essere uniche fino a quando non si hanno circa 2 password ^256/2 ~ 10 ³⁸ memorizzate nella tabella e quindi circa la metà delle volte che saranno un set di password duplicate. Per far sì che una determinata password abbia probabilmente una seconda stringa che esegue il mapping allo stesso hash, è necessario circa 2 ²⁵⁶ ~ 10 ⁷⁷ . (Tutti questi presuppongono che le funzioni di hash abbiano una buona uniformità).

Mettiamo questi grandi numeri in prospettiva. La massa della Terra è di circa 6x10 ^ 24 kg. Pertanto, se si utilizzano in media 50 byte per memorizzare ciascuna password in una tabella arcobaleno, prima che sia probabile un duplicato con SHA256 occorrono circa 10 ^ 30 gigabyte di dati. Se lo metti in termini di tutti i dischi rigidi da 3 TB ognuno dei quali pesa circa mezzo kg, i tuoi dischi rigidi peserebbero circa 1000 volte di più della Terra. O come confronto per avere la probabilità che la maggior parte degli hash abbia più stringhe, confrontare il 10 ⁷⁷ numero di hash SHA256 necessario ad essere un miliardo di volte inferiore al numero di atomi nella Via Lattea (circa 10 < sup> 68 ).

Giusto - prima di tutto, ci sono un sacco di domande qui, quindi mentre avrò un rapido andare, probabilmente dovresti prima leggere le domande collegate a lato e quelle con password e password-gestione tag. Molte delle tue domande hanno ricevuto risposta. In realtà, sono tutti tranne la tua domanda specifica su dove memorizzare la chiave di crittografia.

Un breve riepilogo:

1. PHP - generalmente considerato piuttosto insicuro. Può essere fissato a vari livelli, ma la struttura e il rigonfiamento funzionale che spesso ne deriva implica che se la sicurezza è il tuo obiettivo principale, i rischi dovrebbero essere apprezzati molto attentamente.
2. Non memorizzare le chiavi di crittografia con dati pubblici. In un ambiente completamente ospitato questo può essere difficile da gestire, ma è un grosso rischio.
3. Sì, le tabelle arcobaleno ti consentono di recuperare le password dagli hash in pochi secondi se non usi salting - gli hash dovrebbero usare i sali e un algoritmo lento . Questo può essere fatto in modo molto sicuro (ad esempio, la forzatura bruta impiega un tempo incredibilmente lungo - più lungo della vita dell'universo, per esempio)

Dovresti eseguire l'hashing delle tue password (con HMAC + bcrypt), non crittografarle. Ecco alcune regole generali che seguo:

1. Utilizza un algoritmo che offre limiti di tempo sufficienti (ad es., bcrypt). Questo perché, bcrypt ti permette di personalizzare il lavoro richiesto per calcolare ogni hash che aiuta a ridurre il numero di tentativi di forza bruta che un attaccante può preformare in un dato intervallo di tempo.

2. Utilizza per i sali utente. Usando i sali per utente, puoi essere certo che nessun utente con la stessa password avrà lo stesso hash. Riduce anche il rischio associato ai tavoli arcobaleno.

3. Utilizza un sistema salt saltato, che non è archiviato nel database. Questo fornisce un ulteriore livello di sicurezza in caso di compromissione completa del DB in cui sia l'hash delle password che i sali sono compromessi . Usando un altro sale che viene memorizzato solo nella memoria, un utente malintenzionato non sarebbe in grado di forzare facilmente la password di ogni utente.

Sì, ci sono "centinaia" di domande su questo problema. Questo mi ha costretto scrivere un articolo su di esso che spero risponda una volta per tutte:

link

Essenzialmente, l'archiviazione sicura delle password implica:

• L'algoritmo giusto - usa bcrypt o PBKDF2 , entrambi algoritmi lenti che hash password con il loro "sale". La crittografia non è l'ideale perché l'esatto la password può essere recuperata se la chiave è nota, il che non è necessariamente il caso dell'hashing. MD5, SHA-1, ecc. Da soli non sono l'ideale, perché non sono abbastanza "lenti".

• La giusta politica per le password - come forzare gli utenti a usare password lunghe, e incoraggiando password complesse.

Aggiungi commenti per aiutarmi a migliorare l'articolo.

Prima di tutto, devi sempre seguire il principio dei privilegi minimi . Anche se non direttamente applicabile in questo caso, dovrebbe significare che, a meno che sicuramente non abbia bisogno della password originale (ad esempio autenticazione remota), non utilizzare uno schema che permetta di recuperare la password originale.

Quindi la crittografia viene presa in considerazione solo se sicuramente è necessario ottenere la password originale. Altrimenti, memorizza solo un hash della password.

Come per lo schema di hashing, dovresti usare uno che è stato specificamente progettato per l'hashing / memorizzazione di password (per esempio crypt ). Oltre alle funzioni di hash crittografiche generiche come quelle delle famiglie MD o SHA, molte di esse aggiungono un fattore di costo temporale aggiuntivo e regolabile che rende gli attacchi a forza bruta meno efficienti / più difficili.

Parlando di attacchi a forza bruta, usa un salt unico per ogni password con hash. Alcuni schemi di password come crypt già applicano la salatura automatica . Usalo e non provare a inventare il tuo sistema.

Dovresti usare le password hash archiviate nel database con un salt. Non proverei a scrivere la mia libreria di hashing delle password. Uno molto popolare che è utilizzato in molti progetti PHP (incluso il mio) è phpass da link - può creare hash salati usando bcrypt , DES o MD5.

Per aiutare gli utenti a creare password più sicure, puoi richiedere loro di creare password di una certa lunghezza o complessità.

Posso darti rapidamente la funzione che uso per le password hash (la chiave è, ovviamente, modificata qui):

$siteLongKey = '5efd8123878793f88bf1362905ae209794a8602f92969a67862b925fd6e50b04dfd31ae74002cb449824fcaa90e2efd096e8653a3f52e2b048e24b289c705129';

    function hashPassword($password, $nonce = '') {
      global $siteLongKey;    
      return hash_hmac('sha512', $password . $nonce, $siteLongKey);
    }

Questo è abbastanza buono, $ siteLongKey è la tua chiave globale e $ nonce è il sale che puoi aggiungere. Potrebbe essere l'indirizzo email o la data di creazione dell'account o qualsiasi informazione statica relativa all'account. In questo caso, ogni utente ha un sale diverso. Questo è l'hashing a senso unico e (in teoria) non esiste il recupero della password ma solo la reimpostazione della password.

Il miglior algoritmo attualmente disponibile è bcrypt. Tuttavia, a novembre è stato inventato un algoritmo migliore e una domanda di brevetto viene lentamente preparata per questo. L'algoritmo può essere disponibile in non meno di 18 mesi (periodo di non divulgazione obbligatoria dell'OMPI). L'utilizzo gratuito sarà disponibile solo con distribuzioni Linux non commerciali.