Thank you for the comments! My point wasn't to show how wasteful or bad rainbow tables are. My point was that brute forcing is actually significantly easier t

Thank you for the comments! My point wasn't to show how wasteful or bad rainbow tables are. My point was that brute forcing is actually significantly easier than people realize (to the point of being almost as efficient as rainbow tables depending on the circumstances). And since any standard measure that prevents brute forcing will also help prevent rainbow tables, the point that I was trying to convey is that you should not try to protect against rainbow tables exclusively, but you should try to protect against brute forcing and get the rainbow table protection that comes naturally from that step... With respect to the 4 character password limitation, that was mainly to show how powerful brute forcing can be, not how bad rainbow tables are. Sure, you can make a dictionary rainbow table based off a normal english dictionary with perturbations (caps/symbol replacements) and have it be more efficient than a brute force for any size. But I was looking at it form a guaranteed match aspect, not a "probable match". So for a guaranteed match against an 8 character password, the rainbow table would have to be gigantic, but brute forcing would likely not take as much time. Perhaps I should have presented it a bit differently. But I purposely wanted to take the worst case approach to demonstrate just how efficient brute forcing can be. If that painted a slightly tainted picture, then fine. But I think it got the point across (although how it got it across has been questioned)...