Tasto che allunga un hash

Question

Tasto che allunga un hash

#1 da (10 voti)
#2 da (5 voti)
#3 da (-2 voti)

2

Se implemento una funzione che blocca la prima metà della mia password con MD5 e la seconda metà con SHA-2 e MD5, c'è un problema di sicurezza quando ho messo insieme questi due hash per creare una stringa di 64 caratteri?

Example:
Password: "test123"

first_half: md5(test+salt1);
second_half: sha2(md5(123)+salt2);
hash = first_half + second_half

Vorrei usare qualcosa di simile per estendere l'hash, in modo che gli attaccanti non sappiano che tipo di hash ho usato. Quindi i tavoli arcobaleno standard saranno inutili. Inoltre, non ci saranno collisioni MD5 standard, perché ha più caratteri. Ho ragione?

passwords hash

posta Vilican 15.11.2012 - 10:14

fonte

3 risposte

Leggi altre domande sui tag passwords hash

Perché un attacco di replay dovrebbe essere considerato una minaccia all'integrità e non alla riservatezza? Se un hacker dovesse compromettere un database GMail

score 10 · Answer 1

No. Sarebbe banale per loro prendere solo ogni parte e rafforzarla, anche per password sicure. Stai cadendo nello stesso problema che NTLM ha fatto nei primi tempi, in cui una lunga password finisce con l'essere due password davvero brevi che sono facili da bruteforce indipendentemente.

Invece di dover craccare una password di 10 caratteri (supponendo az 0-9 che è uno spazio tasti di 3.656 × 10 ¹³) devono solo craccare due password di 5 caratteri (spazio tasti di 120.932.352 per lo stesso password) rendendo il problema di diversi ordini di grandezza più facile per loro.

Se stai cercando le password hash, usa un algoritmo di derivazione della chiave strong come bcrypt o PBKDF2.

Raccomando di leggere queste due domande su IT Security:

Gli esperti di sicurezza consigliano bcrypt per l'archiviazione delle password ?
Come conservare il sale? (contiene una spiegazione dettagliata del motivo per cui è necessaria la derivazione e la salatura delle chiavi )

score 5 · Answer 2

La divisione della password non è buona.

Anche la progettazione del proprio meccanismo di hashing della password non è buona. Va bene per scopi di apprendimento, ma per la produzione, questo è un no-go, perché non puoi sapere se hai fatto le cose giuste o no . È un difetto generico e onnicomprensivo della crittografia fatta in casa. Di tutta la crittografia, davvero; ma, almeno, con standard pubblici come bcrypt , beneficerai della revisione di molti occhi durante molti anni.

Dici che gli attaccanti "non conoscono il tipo di hash che hai usato". È sbagliato; lo sanno già, probabilmente meglio di te. Prima di tutto, hanno accesso a Internet, quindi possono leggere questa stessa domanda che chiedi su StackExchange. Inoltre, il metodo di hashing esiste come codice sorgente da qualche parte, e qualche script eseguibile o binario sul tuo server, quindi non può essere davvero segreto. In particolare, si desidera hash le password prima di memorizzarle perché si prevede un utente malintenzionato che potrebbe ottenere un accesso di sola lettura illegale ai dati memorizzati dal server (altrimenti non sarà necessario eseguirne l'hash) ; è molto plausibile che un tale aggressore ottenga anche un accesso di sola lettura al server code stesso, e quindi acquisisca conoscenza del metodo di hashing che si usa.

Ultimo ma non meno importante, non puoi sapere quanto il tuo algoritmo di hash è segreto. Gran parte della sicurezza riguarda la quantificazione e la misurazione. Con una password, puoi stimare entropy , a seconda del meccanismo di generazione; lo stesso per ogni chiave segreta: le chiavi vivono in uno spazio di una dimensione che può essere valutato attraverso la matematica. Ma la segretezza di un algoritmo , che esiste in vari punti, incluso il codice sorgente, i file eseguibili, eventualmente fogli stampati, i backup e il cervello di alcuni sviluppatori? Quanto segreto può essere?

Kerckhoff lo ha spiegato abbastanza chiaramente più di un secolo fa: non considererai il tuo sistema come segreto. Chiavi (e le password, che sono solo un tipo di chiave) sono progettate per concentrare la segretezza, mentre il resto dell'algoritmo deve essere considerato pubblico - perché, la maggior parte delle volte, è conoscenza pubblica.

score -2 · Answer 3

In pratica ho visto questo fatto anche per gli utenti di db, ad esempio, per oscurare le informazioni utente dei minori, anche per il loro nome di accesso. Se ricordo bene era qualcosa come [email protected] lo stesso potrebbe essere usato per le password e suppongo che se tu fossi interessato w / mantenendo quelle stringhe nel db potresti fare un xor su di esse un paio di volte (quindi è un po 'più veloce calcolare 100 o 1000x) ed essere' non come 'facilmente reversibile ... per esempio.

(Sha1 xor Sha2 xor md5) * CRC32

Il CRC32 è solo per divertimento, ma potresti usare uno spostamento a sinistra o a destra prima degli operatori di bit se ti piacesse.

Spero che ti aiuti!