Ok, for those who didn't RTFA, or don't know anything about security, you have a list of users and encrypted passwords in a DB. They log on and their password is checked against the DB. The problem is how do you know if someone has stolen your DB so they can crack it offline? (Offline brute force attacks are much more effective since they are thousands of times faster)
So the author proposes that you give each user several possible passwords in the DB, only one of which is the correct one. If other passwords are used to logon, a danger alarm goes off, and you know someone has stolen your DB.
There are several problems with this idea. To make it work, you have to have a second DB listing all the passwords, and some sort of marker indicating which ones are real and which are fakes. You can't put this in the main DB, because then the hackers would have stolen this info too, and can tell which passwords are real. So you have a second, more secure system for this. Aside from the problems in maintaining a separate parallel system, one might ask the question, "why isn't your primary DB as secure as the secondary DB?". If attackers can breach your main defenses how do you know they cannot breach your backup network? What happens if your secondary system goes down?
More insidious, there is the recursive security problem. The point of doing this is for the assurance that your password DB is secure. How will you know if an attacker has gained access to your secondary password DB? Well, that would require a third password DB.......