Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Hashing explained for IT and security teams: how hash functions work, hashing vs encryption, checking file hashes with Get-FileHash, certutil and sha256sum, salted password hashing, digital signatures, and why MD5 and SHA-1 are retired.
Updated: October 2026
The string of characters next to an ISO download is the only proof that the file you got is the file the vendor built. The same trick keeps passwords out of plain text, signs every Windows driver and names every Git commit. This guide explains hashing in plain words: what a hash function does, how to check a file and where IT and security teams use it daily.
Hashing runs data through a hash function, a piece of public math that turns input of any size into output of one fixed size. The output is called a hash, a hash value or a digest. NIST's glossary puts it in one line: a hash function "maps a bit string of arbitrary length to a fixed-length bit string."
Think of it as a fingerprint for data. The same file always gives the same fingerprint, and a different file gives a different one. You can't rebuild a person from a fingerprint, and you can't rebuild data from its hash.
Here's SHA-256, the hash you'll meet most often, run on the word "hello":
codehello -> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
That's 64 hexadecimal characters, or 256 bits. Hash a 6 GB Windows ISO and you get 64 characters too. Length tells you the algorithm, never the size of the input: MD5 gives 32 characters, SHA-1 gives 40 and SHA-256 gives 64.
A hash only looks at content. Rename a file and its hash stays the same. Change one character inside it and the hash changes, as Microsoft's Get-FileHash documentation spells out. So a hash can prove two files are identical even when their names and dates disagree.
Not every hash is a security tool. PowerShell's @{} hashtable uses a fast hash to find keys quickly. CRC32 in Ethernet frames and ZIP files catches accidental bit flips. Those are built for speed: they catch noise, but anyone can forge a match on purpose. This guide sticks to cryptographic hash functions, the kind built to resist someone trying to cheat.
Practical Networking's explainer covers the same ground visually, from MD5 and SHA-1 to SHA-2 and SHA-3:
A hash function works like a blender with a strict, published recipe. SHA-256 pads the input, cuts it into 512-bit blocks and stirs each block into a running internal state through 64 rounds of shifts, additions and mixing. After the last block, that state is the hash. There's no key, and the steps are fixed in the FIPS 180-4 standard, so every computer gets the same answer from the same input.
SHA-3 gets there differently. It absorbs the input into a large internal state and then squeezes the output out, a design called a sponge. Different machinery, same promise.
The promise has three parts:
Collisions have to exist, because there are endless possible inputs and a fixed number of outputs. The point is that nobody can find one. Once researchers learn to manufacture collisions cheaply, the hash is finished for security work. That's what happened to MD5 and SHA-1.
The fourth property is the one you can see. Change the input by a single bit and the output changes beyond recognition. This is the avalanche effect. "hello" and "Hello" differ by exactly one bit, because a capital H sits one bit away from a lowercase h:
codehello -> 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 Hello -> 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
We counted: 125 of the 256 output bits flipped. There's no pattern to follow from one to the other, so a hash can't hint at what changed or by how much. It only tells you that something did.
These three get mixed up in tickets, scripts and security questionnaires. The difference comes down to one question: can you get the original back, and who can?
| Hashing | Encryption | Encoding | |
|---|---|---|---|
| Can you get the original back? | No | Yes, with the key | Yes, anyone can |
| Uses a key? | No | Yes | No |
| Output size | Fixed, whatever the input | Grows with the input | Grows with the input |
| What it's for | Proving data hasn't changed, storing passwords | Keeping data secret | Moving data safely between systems |
| Examples | SHA-256, SHA-3, Argon2id | AES, RSA | Base64, hex, URL encoding |
Encoding gives no protection at all. A Base64 string in a script is a password anyone can read with one command. Encryption protects secrets you need to read again. Hashing throws information away on purpose, so there's nothing to get back.
An r/cybersecurity thread on this exact question gets to the same place: hashing is one-way, encryption is two-way.
That's why a ticket asking IT to "decrypt the password hash" has one resolution: reset the password. When attackers crack a hash, they don't reverse it either. They guess passwords, hash each guess and compare. So the password section below is about making every guess expensive.
Checking a hash takes one command. Where the expected hash comes from matters more than the command.
If the hash sits on the same mirror as the download, an attacker who swapped the file can swap the hash too. Take the reference value from the vendor's own HTTPS page, or better, from a signed checksum file. Ubuntu publishes a SHA256SUMS file with a SHA256SUMS.gpg signature, and its verification tutorial checks the signature first and the ISO second.
On Windows, Get-FileHash uses SHA-256 unless you ask for something else. From CMD, certutil does the same job and supports MD2, MD4, MD5, SHA1, SHA256, SHA384 and SHA512, so always name the algorithm:
powershellGet-FileHash .\installer.iso # True or False against the vendor's value (PowerShell's -eq ignores case) (Get-FileHash .\installer.iso).Hash -eq 'PASTE_THE_VENDOR_HASH_HERE' certutil -hashfile installer.iso SHA256
On Linux, sha256sum prints a hash or checks a whole list at once. On macOS, shasum does it:
bashsha256sum installer.iso sha256sum -c SHA256SUMS --ignore-missing # checks every listed file you have shasum -a 256 installer.iso # macOS
A mismatch means the bytes differ. Download once more from the vendor's own source. A one-off mismatch usually points at a broken transfer, while a repeat means the file doesn't get run. Our guide to checksum errors covers how to tell those apart.
A matching hash proves you have the file the vendor published, not that the file is safe. r/sysadmin made that point when a flagged installer came up:
At fleet scale, the same command answers a different question: is this binary the same on every machine? OpenFrame can run a Get-FileHash script across a client's devices and collect the output in one place. The odd one out shows up in a single list.
Hashes sit under a lot of security tooling, usually without a label.
File integrity monitoring hashes important files once, keeps the results as a baseline and hashes them again on a schedule. A new hash on a system binary, a web root or a config file raises an alert.
On Windows, Microsoft's Sysmon tool records the hash of every process image it logs. SHA1 is the default, with MD5, SHA256 and IMPHASH available, several at once. Add SHA256 so your lookups don't depend on the weaker hashes.
A hash is the safest way to ask whether anyone has seen a file before. You send 64 characters, not the file. VirusTotal's file report API accepts a SHA-256, SHA-1 or MD5 hash and returns what it knows about that file.
The catch: hash indicators are brittle. Recompile the malware, or flip one bit in an unused resource, and the avalanche effect hands you a brand-new hash. That makes hashes the easiest indicator for an attacker to change, a point our guide to indicators of compromise covers with the Pyramid of Pain.
Fuzzy hashing fills part of that gap. The ssdeep project scores how similar two files are, so a lightly modified file still lands close to the original.
Every commit you've pushed is named by a hash. Git "uses the SHA-1 hash function to name content," per its hash transition plan. A commit's hash covers its files, its parent commits and its message, so changing anything in the past changes every later commit ID. Since SHAttered, Git 2.13.0 and later use a hardened SHA-1 that isn't vulnerable to that attack. New repositories can use SHA-256 with git init --object-format=sha256, but SHA-1 and SHA-256 repositories can't interoperate yet.
Public-key math can't sign a 6 GB file in one go, so signature schemes sign its hash instead. The signer hashes the file and signs that hash with a private key. Anyone can re-hash the file and check the result against the signature with the public key. Authenticode on Windows drivers and installers works this way. So do TLS certificates, where a certificate authority signs the hash of the certificate's contents.
That makes the hash the weak link. If an attacker can make two files with the same hash, a signature on the harmless one fits the malicious one too.
Flame did exactly this in 2012. The malware carried a code-signing certificate that appeared to come from Microsoft. CWI cryptanalyst Marc Stevens traced it to a new variant of a chosen-prefix MD5 collision. The target was a Microsoft Terminal Server Licensing Service certificate authority, and the result let Flame pose as Windows Update.
Microsoft published Security Advisory 2718704 on June 3, 2012 and pulled trust from the affected intermediate certificates across supported Windows releases.
You can check a signature yourself with Get-AuthenticodeSignature .\setup.exe. A status of HashMismatch is the hash doing its job. Microsoft's SignatureStatus reference defines it as a file whose hash "does not match the hash stored along with the signature."
A login system shouldn't know your password. It stores a hash, hashes whatever you type at sign-in and compares the two. If the database leaks, the attacker gets hashes, not passwords.
That only helps if the hashes are hard to guess. Attackers with a stolen hash list hash candidate passwords, starting with the most common passwords, and look for matches. Fast hashes hand them the advantage.
OWASP's password guidance says it plainly: "Fast hashing algorithms such as SHA-256 are not suitable for password storage." Good password hashing schemes add two defenses.
A salt is a random value generated for each password and stored next to its hash. Two users with the same password get different hashes, so cracking one doesn't crack the other, and precomputed hash tables stop working. A slow hash makes every guess cost time and, in newer schemes, memory, which blunts the GPUs crackers rely on.
Here's one weak password for two users, first as a Windows NT hash, then as Argon2id with OWASP's settings:
codeNT hash (MD4, no salt) alice 41aed72cec76816423703d8e545eea31 bob 41aed72cec76816423703d8e545eea31 Argon2id (19 MiB, 2 passes, per-user salt) alice $argon2id$v=19$m=19456,t=2,p=1$O2kwhKN5IU8EECTNyZKsZA$gDv/fbbzUKBXE2itHqjLtLUScHPaK9G+kTbIAN3D87A bob $argon2id$v=19$m=19456,t=2,p=1$sE44nUcc+12xYwyRlZeEjQ$iXi+F7uxOeDdvCY36vk3fmMMIdhFad1pV4r7NayeVO4
The Argon2id record carries everything a verifier needs: the algorithm, its cost settings, the salt and the hash. The NT hash carries none of that. Microsoft's passwords technical overview confirms the NT hash is plain MD4 and that "neither the NT hash nor the LM hash is salted." So a stolen NT hash cracks fast, and pass-the-hash attacks use it as a credential by itself.
NIST SP 800-63B-4, final since July 2025, requires passwords to be "salted and hashed using a suitable password hashing scheme." The salt must be at least 32 bits, and the cost factor should be "as high as practical." NIST also recommends an extra keyed hash with a secret stored apart from the password database.
OWASP's minimums, as checked in October 2026:
| Algorithm | OWASP minimum settings | When to use it |
|---|---|---|
| Argon2id | 19 MiB of memory, 2 iterations, parallelism 1 | First choice for new systems |
| scrypt | Cost 2^17, block size 8, parallelism 1 | When Argon2id isn't available |
| bcrypt | Work factor 10 or more; input capped at 72 bytes | Legacy systems |
| PBKDF2-HMAC-SHA256 | 600,000 iterations | When you need FIPS-140 validated crypto |
Hashing also lets you check a password against breach data without sharing it. Have I Been Pwned's Pwned Passwords API takes only the first five characters of a password's SHA-1 hash. It returns every matching suffix, so the full hash never leaves your machine.
MD5 dates from 1992 and SHA-1 from 1995. For years both were the standard way to fingerprint files and sign certificates. Both now fail the "no twins" test.
MD5 fell first. In August 2004, Xiaoyun Wang, Dengguo Feng, Xuejia Lai and Hongbo Yu published MD5 collisions. In 2011, RFC 6151 stated that "MD5 is no longer acceptable where collision resistance is required such as digital signatures."
By then the attacks had left the lab. In December 2008, researchers used an MD5 collision to create a rogue CA certificate trusted by all common web browsers. Flame's forged Microsoft certificate followed in 2012.
SHA-1 held out longer. On February 23, 2017, CWI Amsterdam and Google announced the SHAttered attack, the first practical SHA-1 collision: two different PDFs with the same hash. It took roughly nine quintillion SHA-1 computations, about 6,500 CPU-years and 110 GPU-years.
Then the price dropped. In January 2020, the SHA-1 is a Shambles team produced a chosen-prefix collision and used it to impersonate a PGP key. That's the kind where the attacker picks both starting documents. They put the cost at about 45,000 US dollars in rented GPUs.
On December 15, 2022, NIST announced that SHA-1 should be phased out by December 31, 2030. Its advice to anyone relying on SHA-1 for security: "migrate to SHA-2 or SHA-3 as soon as possible."
None of this makes MD5 useless. It still catches accidental corruption, and Microsoft's Get-FileHash documentation limits MD5 and SHA1 to "simple change validation." What they can't do is stand up to someone who controls the input. For anything an attacker might touch, use SHA-256.
Match the algorithm to the job:
| Job | Use | Avoid | Reference |
|---|---|---|---|
| Verifying downloads, ISOs and backups | SHA-256 (SHA-384 and SHA-512 also fine) | MD5, SHA-1 | FIPS 180-4 |
| A second, independent design | SHA3-256 | - | FIPS 202 |
| Storing passwords | Argon2id, or PBKDF2 where FIPS-140 applies | Plain SHA-256, MD5, anything unsalted | OWASP, NIST SP 800-63B-4 |
| Signing code, documents and certificates | SHA-256 or stronger | SHA-1, MD5 | NIST SHA-1 retirement |
| Proving a message came from someone holding a shared key | HMAC-SHA256 | A plain hash of secret plus message | RFC 2104 |
| Hash tables, deduplication, accidental-error checks | CRC32, xxHash | Using these for security | - |
SHA-3 earns its row as a hedge. The FIPS 202 standard builds it on the Keccak algorithm, a different design from SHA-2. A future break in one wouldn't automatically carry over to the other. SHA-256 stays the default because it's approved, fast and supported everywhere.
Hashing gives any piece of data a fixed-length fingerprint that can't be reversed and changes completely when one bit changes. Technicians use it to verify downloads, watch files, look up malware and trust signatures. Every login system should use it for passwords. Pick SHA-256 or SHA-3 for files and signatures, Argon2id for passwords, and keep MD5 and SHA-1 for accidental-error checks only.
A hash can't tell you what's inside a file. It can tell you whether a single bit changed. For the other half of the picture, our guide to decryption covers how encrypted data comes back with the right key.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.
