How do passwords work?
What a password isn't, or at least really shouldn't be, is some kind of secret word or phrase that is simply compared against a table of usernames in a login database. Such plaintext systems are about as secure as a chocolate padlock on a furnace door. Even a login system whereby those passwords are encrypted isn't much better, although many people assume they are safe as houses. Breaches across the years have proven how insecure any system which relies purely on reversible algorithm encryption really is. The user logs in and enters a password, this triggers the system to decrypt the password in the login database that is associated with the username and if they match then authorisation is granted. The weakness here should be obvious, and simply put if someone manages to get access to the encrypted password database itself then it can be copied and cracked offline at their leisure as has happened time and time again.
Which leads us to the next step up the password protection ladder, and that's usage of hashing. Think of a hash as being a one-way mathematical function, an algorithm to morph the password itself into a really long number and destroys the password data in so doing. It's the hash value that is stored in the login database, and when a user enters their password the hash is decrypted to provide the 'long number' value of that password and if they match authorisation is made. This makes it much harder to crack if someone gains access to the database itself, or at least it should in theory. Unfortunately, in practise, any two identical passwords (sharing the same character string) will have the same hash value. So it then becomes a matter of the hacker looking for matching hash values within the copied login database and assuming that these are most likely going to be dictionary words, or at the very least passwords that appear in any of the readily available dictionary attack databases of popular password combinations. And there's the weakness you may think, with hacker running a dictionary attack against those identified user logins with matching hashes and, more often than not, getting lucky with a good number of them. But it's actually worse than that for the system admin and much easier for the hacker courtesy of rainbow tables.
Rainbow tables are pre-computed lists of the cryptographic hashes relating to any possible password of specific lengths from specific character sets. The smaller the length of password taken from the simplest of character sets, the quicker a rainbow table attack will disclose it. This is why you hear about making passwords 'long and complex' which really means using lots of characters from a mix of character sets such as upper and lower case alphabet, numerical, special characters and so on. Given enough computing power (and if we are talking nation states or a criminal syndicate, although many would say the two amount to much the same, that's no problem) a terabyte rainbow table can crack simple password hashes really very quickly indeed. Unless those hashes have also been salted.
To overcome the problem of password hashes for the same original password (built from identical characters) sharing the same value and therefore introducing weakness into the system, salting the hash is recommended. A salt is simply a random value that is introduced into the password before encryption takes place so that when it is hashed that random value, or salt, is added and the resulting hash value is unique even for multiple identical originating passwords. Salted rainbow hash tables could be constructed, but to be of any use to an attacker these would have to be improbably large to be of any impact if the original password salting is suitably large to begin with. As such, although you cannot say that a salted hash is 100 percent secure (nothing is) in the real world these will reduce the risk of rainbow tables being effective by a considerable factor.