Salendo un hash pubblico

Question

Salendo un hash pubblico

#1 da (8 voti)
#2 da (5 voti)

4

Ha senso inserire un hash che potrebbe essere disponibile pubblicamente?

Per me non ha senso, ma qualcuno lo fa davvero?

UPDATE: alcune ulteriori informazioni:

Un mio conoscente ha una comune funzione di hash salata che usa nel suo codice. Quindi mi stavo chiedendo se avesse assolutamente senso, per farlo.

Ecco la funzione che ha usato:

hashlib.sha256(string+SALT).hexdigest()

Update2:

Scusa se non è stato chiaro. Per pubblico pubblicamente intendevo, che è reso nell'HTML del progetto (per il collegamento, ecc.) & può quindi essere facilmente letto da una terza parte.

Il progetto è un'app web basata su Python che coinvolge pagine create dall'utente che vengono tracciate usando i loro hash come myproject.com/hash , quindi rivelando pubblicamente l'hash. Quindi la mia domanda è, se in qualsiasi circostanza un qualsiasi programmatore sano salisse un simile hash?

Domanda: Usando hashlib.sha256(string+SALT).hexdigest() vs hashlib.sha256(string).hexdigest() , quando l'hash non è un segreto.

hash

posta Sathvik 19.11.2011 - 20:29

fonte

2 risposte

5

L'idea di un salt per un hash è che lo stesso messaggio non risulti nello stesso hash per ogni hash, ma che dipenda anche dal sale.

(La stessa idea si applica a un vettore di inizializzazione per le funzioni di crittografia.)

Se ho capito bene la domanda, stai tagliando i contenuti di una pagina creata dagli utenti per creare un URL per essa. Salire quindi potrebbe avere l'obiettivo che due utenti, caricando lo stesso contenuto, otterranno comunque URL diversi per le loro pagine.

La segretezza dell'hash o del sale non è veramente rilevante qui.

D'altra parte, è necessario memorizzare il sale da qualche parte, quindi non vedo come questa sia una buona idea per una funzione di hash - si potrebbe semplicemente prendere un numero casuale da solo come identificatore .

risposta data 19.11.2011 - 23:25

fonte

Leggi altre domande sui tag hash

Vantaggio dell'utilizzo di due interfacce di rete per il sistema di rilevamento delle intrusioni FDE Android - Perché la chiave è memorizzata nella RAM?

score 8 · Accepted Answer

Sì. Normalmente è dato per scontato che il sale sia disponibile per un attaccante. Il sale non deve essere tenuto segreto per essere utile.

La salatura di un hash viene effettuata principalmente per proteggere da un attacco di dizionario. Un attacco di dizionario funziona con hashing parole comuni (ad esempio, tutto in un dizionario, quindi il nome) e quindi confrontando i valori hash con quelli del dizionario. Se trovi una corrispondenza (e per cose come le password con hash, lo farai di solito), sai quale parola ha prodotto il risultato dell'hash.

Il sale rende semplicemente questo tipo di attacco consumare molto più tempo e (soprattutto) spazio di archiviazione. Solo per lo stesso argomento, diciamo che un dizionario relativamente completo (compresi molti nomi e simili) con risultati hash ha impiegato 3 giorni per calcolare e occupato un gigabyte di spazio di archiviazione.

Se aggiungiamo, diciamo, un sale a 16 bit, il calcolo impiegherebbe approssimativamente 65536x3 = 196,608 giorni = ~ 538 anni. La memorizzazione del risultato richiederebbe circa 64 terabyte invece di un gigabyte. In tutta onestà, la maggior parte delle persone non avrà 65536 utenti (ad esempio), quindi l'attaccante dovrebbe probabilmente raccogliere i sali e gli hash e fare solo un attacco di dizionario sui sali effettivamente utilizzati. Ciò significa ancora un attacco di dizionario per utente (o qualsiasi altra cosa) piuttosto che uno per tutti.

Per la maggior parte degli scopi, ciò fa la differenza tra qualcosa che quasi chiunque potrebbe fare solo perché ne ha voglia, e qualcosa che solo un attaccante abbastanza determinato (e probabilmente ben finanziato) potrebbe persino contemplare.