Funzioni di hash spiegate: SHA-256, checksum e hashing delle password

Aggiornato: 14 ottobre 2026

Una funzione di hash trasforma qualsiasi input — una parola, una password, un file da 4 GB — in un’impronta breve e di lunghezza fissa. Lo stesso input dà sempre la stessa impronta, e la minima modifica ne dà una completamente diversa. Per questo gli hash sono il metodo standard per verificare che un file sia arrivato integro, per conservare le password senza conservare le password stesse e per firmare i messaggi. Questa guida spiega cosa rende sicuro un hash, quali algoritmi sono ancora affidabili, come verificare un download e perché l’hash veloce che va bene per un file è quello sbagliato per una password.

Cosa fa una funzione di hash

Una funzione di hash legge dati di qualsiasi lunghezza e restituisce un digest di lunghezza fissa. SHA-256, oggi la più diffusa, restituisce sempre 256 bit, scritti come 64 caratteri esadecimali, che l’input sia una sola lettera o l’immagine di un intero disco.

• c3c211099e2db0d1bb97343886c2b7e23981b636107a296a9fe642b99ca4cc1bSHA-256 di nTools.
• 420849368aee5e9b6838f98b4dde3f493de84c420baa785ea58a08acc2c0cfafSHA-256 di ntools: una sola lettera passata in minuscolo, e il digest non ha più nulla a che vedere con il precedente.

Ogni funzione di hash è deterministica — lo stesso input dà lo stesso digest su qualsiasi computer — ed è rapida da calcolare. Un hash crittografico aggiunge le garanzie descritte nella prossima sezione, ed è grazie a queste che si può usare per la sicurezza.

Un digest non è una copia compressa: 64 caratteri non possono contenere un file da 4 GB. In teoria a ogni digest corrispondono molti input; un hash sicuro fa solo in modo che, in pratica, sia impossibile trovarli.

Apri il generatore di hash

Cosa rende sicuro un hash

Lo standard statunitense che definisce SHA-256, FIPS 180-4, descrive gli algoritmi come sicuri perché certe ricerche sono computazionalmente impraticabili. In pratica le proprietà sono tre:

• Resistenza alla preimmagine: dato un digest, nessuno riesce a trovare un input che lo produca. È questo che significa «a senso unico».
• Resistenza alla seconda preimmagine: dato un file, nessuno riesce a creare un file diverso con lo stesso digest.
• Resistenza alle collisioni: nessuno riesce a trovare due input diversi qualsiasi con lo stesso digest, nemmeno scegliendoli entrambi liberamente.

La resistenza alle collisioni è la prima a cedere, perché l’attaccante controlla entrambi gli input. È ciò che è successo a MD5 e SHA-1. La cosa conta perché le firme digitali e i certificati si calcolano su un hash del documento: due documenti con lo stesso hash condividono la stessa firma.

MD5, SHA-1, SHA-2 e SHA-3

La collisione di SHA-1, chiamata SHAttered, è stata annunciata da Google e dal CWI di Amsterdam il 23 febbraio 2017: due file PDF diversi con lo stesso digest SHA-1, trovati con circa 9,2 miliardi di miliardi di calcoli SHA-1. Da allora MD5 e SHA-1, usati come semplici hash, sopravvivono solo come controlli rapidi contro i danni accidentali. Lo dice anche la documentazione di Microsoft sul comando di Windows per l’hash dei file: vanno usati solo per una semplice verifica delle modifiche, mai per file che devono essere protetti da manomissioni.

Il generatore di hash di nTools offre SHA-256, SHA-384 e SHA-512. Usa la Web Crypto API integrata nel browser, che supporta anche SHA-1 — con l’avvertenza di non usarlo in crittografia — e non offre affatto MD5.

Verificare un download

Chi pubblica software indica spesso un checksum accanto al file, di solito SHA-256. Dopo il download calcoli il digest della tua copia e lo confronti.

1. Controlla quale algoritmo ha usato chi pubblica il file e copia il checksum indicato.
2. Calcola il digest del file scaricato con lo stesso algoritmo: nel generatore di hash di nTools per file fino a 200 MB, oppure con un comando come quelli qui sotto per file di qualsiasi dimensione.
3. Confronta tutti i caratteri, non solo i primi e gli ultimi. In esadecimale maiuscole e minuscole non fanno differenza.

• Get-FileHash .\file.isoWindows PowerShell. Usa SHA-256, a meno che non si aggiunga -Algorithm.
• sha256sum file.isoLinux.
• shasum -a 256 file.isomacOS.

Se i digest coincidono, il file è proprio quello di cui è stato calcolato l’hash; ma questo non dice chi l’ha calcolato. Un attaccante in grado di sostituire il file su un sito di solito può sostituire anche il checksum sulla stessa pagina. Per questo progetti come Ubuntu firmano anche il loro elenco di checksum: prima verifichi la firma con GPG, poi il file rispetto all’elenco. Una volta controllata l’impronta della chiave di firma sul sito del progetto stesso, il risultato è valido anche se hai scaricato il file da un mirror non affidabile.

Hashing, cifratura e codifica

Base64 e la codifica URL non proteggono nulla: cambiano il modo in cui i dati sono scritti, non chi può leggerli. Anche le password cifrate sono peggio di quelle conservate come hash, avverte OWASP: la cifratura funziona nei due sensi, quindi chiunque sia in grado di decifrarle ottiene di nuovo le password originali. Ha senso solo nel raro caso in cui l’originale debba essere recuperato.

Perché un hash veloce è sbagliato per le password

Un sito non dovrebbe mai conservare la tua password, ma solo un suo hash: all’accesso calcola l’hash di ciò che digiti e confronta il risultato. Il problema è la velocità. Un hash che verifica un download da 4 GB in pochi secondi permette a chiunque rubi il database di provare miliardi di password al secondo.

Velocità tratte dal benchmark di hashcat 6.2.6 su una sola scheda grafica NVIDIA RTX 4090. Le ultime due righe sono ricavate in proporzione dalle impostazioni del benchmark stesso (999 iterazioni di PBKDF2, bcrypt con costo 5), perché il tempo cresce in proporzione al lavoro. La ricerca copre tutte le 36⁸ password candidate, circa 2.800 miliardi. Gli attacchi reali sono ancora più veloci: usano molte schede insieme e provano prima le password più probabili.

Salt: la stessa password, un hash diverso

Senza salt, tutti quelli che hanno come password 123456 hanno lo stesso hash memorizzato, e gli attaccanti conservano tabelle con gli hash di milioni di password comuni: trovarle diventa una semplice consultazione, non una ricerca.

• 8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92SHA-256 di 123456 senza salt: identico in ogni database che lo memorizza in questo modo.

Un salt è un valore casuale creato per ogni password, memorizzato accanto al suo hash e mescolato nel calcolo. Non è segreto. Il suo compito è rendere unico ogni hash memorizzato, così le tabelle precalcolate diventano inutili e ogni account deve essere attaccato singolarmente.

Le linee guida NIST SP 800-63B-4 impongono che le password siano sottoposte a hash con salt, usando uno schema adatto all’hashing delle password e un salt di almeno 32 bit, e raccomandano un fattore di costo il più alto possibile nella pratica. Raccomandano inoltre un ulteriore passaggio con una chiave segreta conservata separatamente dagli hash, idealmente in un modulo di sicurezza hardware. OWASP chiama quel segreto «pepper».

Cosa usare invece

Le funzioni di hashing per password sono lente di proposito, ricevono il salt come input e hanno un parametro di costo da aumentare man mano che l’hardware diventa più veloce. L’OWASP Password Storage Cheat Sheet indica questi valori minimi:

Sono valori minimi, pensati per far durare un singolo accesso una frazione di secondo sul server rendendo però costoso ogni tentativo. Non puoi sapere quale usa un sito, ed è per questo che i consigli della guida sulle password — password lunghe, casuali e mai riutilizzate — presuppongono il caso peggiore.

HMAC: un hash con chiave

Un hash semplice mostra che i dati non sono cambiati, ma chiunque può calcolarlo: chi altera i dati può semplicemente ricalcolare l’hash. HMAC, definito nell’RFC 2104 nel 1997, mescola nell’hash una chiave segreta, così solo chi possiede la chiave può produrre o verificare il risultato.

È così che le API firmano le richieste, che i webhook dimostrano di provenire dal mittente e che vengono firmati molti JSON Web Token: l’algoritmo JWT HS256 è HMAC con SHA-256.

Domande frequenti

Un hash si può invertire?

No. Il digest non contiene l’input, quindi non c’è niente da decodificare. Quello che fanno gli attaccanti è tirare a indovinare: calcolano l’hash di input candidati finché uno non coincide. Funziona con input brevi o comuni come le password e fallisce con quelli lunghi e casuali.

MD5 va ancora bene per qualcosa?

Per individuare modifiche accidentali, come una copia danneggiata o un file duplicato, sì. Non dove qualcuno potrebbe manomettere i dati di proposito, e mai per password o firme.

Due file possono avere lo stesso digest SHA-256?

In teoria sì: i file possibili sono più dei digest. In pratica non è mai stata trovata alcuna collisione per SHA-256 completo, e una ricerca a forza bruta richiederebbe circa 2¹²⁸ tentativi.

Un digest più lungo è sempre più sicuro?

Solo fino a un certo punto. Con 256 bit una ricerca di collisioni è già del tutto fuori portata; conta di più la solidità dell’algoritmo, come ha dimostrato SHA-1. SHA-384 e SHA-512 si usano dove una norma li richiede o per avere un margine in più.

Il mio file viene caricato quando ne calcolo l’hash su nTools?

No. Il file viene letto e sottoposto a hash nel tuo browser, e viene mostrato solo il digest.

Precedente della serie ← Robustezza delle password spiegata: lunghezza, entropia e passphrase

Riferimenti

1. NIST FIPS 180-4 — Secure Hash Standard (SHS) (August 2015)
2. NIST FIPS 202 — SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions (August 2015)
3. RFC 6151 — Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms (March 2011)
4. NIST — NIST Retires SHA-1 Cryptographic Algorithm (December 2022)
5. EFF — Cryptographers Demonstrate Collision in Popular SHA-1 Algorithm (February 2017)
6. MDN Web Docs — SubtleCrypto: digest() method
7. Microsoft Learn — Get-FileHash
8. Ubuntu — How to verify your Ubuntu download
9. hashcat v6.2.6 benchmark, NVIDIA GeForce RTX 4090
10. NIST SP 800-63B-4 — Authenticators: password verifiers (July 2025)
11. OWASP — Password Storage Cheat Sheet
12. RFC 9106 — Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications (September 2021)
13. RFC 2104 — HMAC: Keyed-Hashing for Message Authentication (February 1997)
14. RFC 7518 — JSON Web Algorithms (JWA) (May 2015)

Guide correlate

• Indirizzi IP spiegati: IPv4, IPv6 e gli intervalli riservati
• Sottoreti e CIDR spiegati: prefissi, maschere e host utilizzabili
• Record DNS spiegati: A, AAAA, CNAME, MX, TXT e NS
• Un sito è down o il problema è solo tuo? Come verificarlo, passo per passo
• Codici di stato HTTP ed errori di Cloudflare: cosa significano 403, 404, 429, 500, 503 e 521
• Timestamp Unix e fusi orari spiegati
• Contare le date: giorni tra due date, anni bisestili e settimane ISO
• Formati immagine spiegati: JPEG, PNG, WebP, AVIF e HEIC
• Robustezza delle password spiegata: lunghezza, entropia e passphrase
• Gli UUID spiegati: v4, v7 e come scegliere la versione giusta
• I codici QR spiegati: capacità, correzione degli errori e dimensioni di stampa
• Percentuali e IVA spiegate: aggiungere, scorporare e cumulare
• Errori comuni nel JSON e come correggerli
• Modificare i PDF nel browser: cosa conservano unione, divisione e conversione