Several technical mistakes in this piece (which I assume was not primarily for a technical audience, but mistakes they are nonetheless):
1. This article repeats the misunderstanding that Rainbow Tables are the same thing as a Dictionary:
> Given the processing power available, hackers have and continue to generate enormous tables that contain anything from every possible combination of values for shorter passwords to lists including variants of common and known passwords. These are called rainbow tables, and if the password used is included in one of these tables, then the cleartext password is known to the hacker.
The Rainbow Table is actually an interesting improvement on a pre-existing idea (by Hellman, yes as in Diffie-Hellman) for a Time-space trade off attack.
So let's describe the most basic idea: We have a list of potential passwords (a "Dictionary"). It doesn't matter whether it's an actual written list, or a procedure to pick possible passwords, but it must be strictly finite. Just trying them all is a Dictionary attack. For an online service this is one thing "rate limiting" is defending against.
Now, if you have the hashes, you could do your dictionary attack except instead of trying to log in you just calculate each hash and compare it. There are automated tools that can do this for you e.g. John The Ripper.
Next cleverest idea is: Let's calculate hashes from our dictionary, store and index them (or we could e.g. store them in order) with the original word so we can just look up a hash and get back the password if we know one.
Hellman's idea was: Don't store all these hashes. Storage is expensive. Imagine a function that converts a hash back into a password from the dictionary, call it F() and the hash function H() now instead of calculating and storing H(password) -> password we recurse through H(F(H(F(.... some number of times, effectively chaining together many solutions in each entry stored, then we do more work to calculate each intermediate when doing a lookup of a hash later. We're trading off less space for more time.
Hellman's idea is clever, but it's a bit wasteful, because sometimes there will be (at random) collisions in either H() or F() and this means you're wasting space/ losing recall in your system.
So, Rainbow Tables are Philippe Oechslin's improvement, Oechslin deliberately perturbs F() differently for each iteration so that if a collision does occur it will go away again unless it was in the same iteration of the chains.
This produces a "rainbow" picture in Oechslin's slides which named the resulting technique.
Rainbow Tables are useless against a properly salted hash, because all this up-front work must be done again for each different salt, or, the size of the tables are inflated by the size of the salt. So e.g. a 32-bit salt (many today are far larger) makes your Rainbow Table cost four billion times more to calculate and need four billion times as much space.
They got famous because some key Microsoft password technologies from the turn of the century do not use salt, and so you can attack those with Rainbow Tables. In particular the LM Hash can 100% reliably be reversed by a suitable Rainbow Table that would be affordable to store in that era.
2. It gets salt wrong:
> As long as the salt value remains secret, this is a very effective method against rainbow attacks and other current methods of attack.
Nope. The salt doesn't need to be secret it should be random for each record. Our goal isn't that an attacker doesn't know each salt, which in most of these cases will have been stored with the hashed passwords, but to prevent them amortizing work over a large number of hashes, see the discussion of Rainbow Tables earlier.
Overall I think for lawyers or managers looking for legal advice, which I assume is the target of this article, the focus ought to be on getting away from passwords. They were already a bad idea, a last resort, last century and we've doubled down rather than seeking every other alternative.
If your system is authenticated with WebAuthn you do not store any secrets you do not store anything that would "permit access" to the system, because it's all driven by Public Key Cryptography. You store things can be used to verify that the client is the same as before, but they can't be used to pretend to be that client, or even to unmask the client's identity. You could (but probably shouldn't) paint the contents of a WebAuthn authentication database on the side of your building and that'd be fine.
By having the salt secret they are using it as an encryption key that they hope will prevent any sort of brute force attack. Thus the hash is no longer covered by privacy legislation. A separate salt per record is still brute forceable, even if it takes a lot longer for a lot of records.
1. This article repeats the misunderstanding that Rainbow Tables are the same thing as a Dictionary:
> Given the processing power available, hackers have and continue to generate enormous tables that contain anything from every possible combination of values for shorter passwords to lists including variants of common and known passwords. These are called rainbow tables, and if the password used is included in one of these tables, then the cleartext password is known to the hacker.
The Rainbow Table is actually an interesting improvement on a pre-existing idea (by Hellman, yes as in Diffie-Hellman) for a Time-space trade off attack.
So let's describe the most basic idea: We have a list of potential passwords (a "Dictionary"). It doesn't matter whether it's an actual written list, or a procedure to pick possible passwords, but it must be strictly finite. Just trying them all is a Dictionary attack. For an online service this is one thing "rate limiting" is defending against.
Now, if you have the hashes, you could do your dictionary attack except instead of trying to log in you just calculate each hash and compare it. There are automated tools that can do this for you e.g. John The Ripper.
Next cleverest idea is: Let's calculate hashes from our dictionary, store and index them (or we could e.g. store them in order) with the original word so we can just look up a hash and get back the password if we know one.
Hellman's idea was: Don't store all these hashes. Storage is expensive. Imagine a function that converts a hash back into a password from the dictionary, call it F() and the hash function H() now instead of calculating and storing H(password) -> password we recurse through H(F(H(F(.... some number of times, effectively chaining together many solutions in each entry stored, then we do more work to calculate each intermediate when doing a lookup of a hash later. We're trading off less space for more time.
Hellman's idea is clever, but it's a bit wasteful, because sometimes there will be (at random) collisions in either H() or F() and this means you're wasting space/ losing recall in your system.
So, Rainbow Tables are Philippe Oechslin's improvement, Oechslin deliberately perturbs F() differently for each iteration so that if a collision does occur it will go away again unless it was in the same iteration of the chains.
This produces a "rainbow" picture in Oechslin's slides which named the resulting technique.
Rainbow Tables are useless against a properly salted hash, because all this up-front work must be done again for each different salt, or, the size of the tables are inflated by the size of the salt. So e.g. a 32-bit salt (many today are far larger) makes your Rainbow Table cost four billion times more to calculate and need four billion times as much space.
They got famous because some key Microsoft password technologies from the turn of the century do not use salt, and so you can attack those with Rainbow Tables. In particular the LM Hash can 100% reliably be reversed by a suitable Rainbow Table that would be affordable to store in that era.
2. It gets salt wrong:
> As long as the salt value remains secret, this is a very effective method against rainbow attacks and other current methods of attack.
Nope. The salt doesn't need to be secret it should be random for each record. Our goal isn't that an attacker doesn't know each salt, which in most of these cases will have been stored with the hashed passwords, but to prevent them amortizing work over a large number of hashes, see the discussion of Rainbow Tables earlier.
Overall I think for lawyers or managers looking for legal advice, which I assume is the target of this article, the focus ought to be on getting away from passwords. They were already a bad idea, a last resort, last century and we've doubled down rather than seeking every other alternative.
If your system is authenticated with WebAuthn you do not store any secrets you do not store anything that would "permit access" to the system, because it's all driven by Public Key Cryptography. You store things can be used to verify that the client is the same as before, but they can't be used to pretend to be that client, or even to unmask the client's identity. You could (but probably shouldn't) paint the contents of a WebAuthn authentication database on the side of your building and that'd be fine.