Can you help me understand what a cryptographic “salt” is?
In the context of password creation, a "salt" is data (random or otherwise) added to a hash function in order to make the hashed output of a password harder to crack.
When might I need to use it?
Why should or should I not use it?
You should always use a salt value with your hash functions, for reasons explained below.
It is generally true people choose weak passwords, and it is certainly true there are gigabytes of publicly available rainbow tables chock-full of hashed values representing them. So when somebody creates an account on your service and selects a password to secure their identity, you can typically bet the password they choose will be 1) common, 2) unsecure and 3) available for cross-reference in lookup tables.
For example, the password Nowayin1 when hashed via MD5 is 6f367d65bc74b88e21fb9959487ffa3a and is obviously not a good choice. Even if it may look okay (and it doesn't), the fact the password's MD5 hash appears in open databases makes it worthless.
But that's just 128-bit MD5. What about something stronger, like SHA1 (160-bit) or even Whirlpool (512-bit)?
For example, P@$$word with SHA1 is 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 and 1qazXSW@ hashed with Whirlpool is 0bf7545b784665d23b9c174ca03688a405f05b048e9d6c49bfc2721a1fa872bbd6576273d002e56d7c2a9c378efe607af36eea9d708a776e6f60ecb26e081cdf.
The root issue with all of these passwords, and billions more like them, is the fact their commonly-used hashes have become common knowledge.
A password salt changes that.
If a random value (the salt) were added to the user's selected password, then the SHA1 hash 1e69e0a615e8cb813812ca797d75d4f08bdc2f56 would no longer reveal P@$$word as the user's password, because the hash value in the rainbow table would no longer match it.
And it wouldn't take much. A small 16-bit random value, for example, would yield 65,536 variants of each hashed value in the lookup tables. So a database of 15 billion entries would now need over 983 billion hashes in it to account for the salt.
So, that's the point of salting your hashes, to thwart lookup and rainbow tables. But don't hang your hat on a salted hash, because hackers won't waste much time using rainbow tables to figure out your passwords.
They'll use a five-server 25-GPU cluster system running Hashcat that can burn through 350 billion guesses per second cracking hashes for every conceivable eight-character password containing upper- and lower-case letters, numbers and special characters, in just under six hours. (And that was back in 2012.)
Techniques such as key-stretching that make hashes run slower can be used to offset the speed of such hardware, making dictionary and brute-force attacks too slow to be worthwhile, but hardware just keeps getting faster and faster.
Current best practices include securely hashing your passwords with Argon2i (preferred over scrypt), a memory-hard function which is very resilient to FPGAs, multiplecore GPUs and dedicated ASIC modules used to easily crack non-stretched passphrases. In the PHP7 implementation of Argon2, the salt is handled internally for you.