To give me ideas of what to test, I look at what can break and how it can break:
- Determining what can break helps me to build stronger, better applications. Sharing that information may even prompt business and requirements analysts to help me to lobby for stronger requirements or advocate repairing defects.
- Learning how to crack passwords helps me to learn how to build stronger, safer products. And the more I learn about password cracking, the smarter consumer I become—after all, just like other people, I use websites to pay bills and manage accounts. These days, I’ve become more password-savvy, and stopped looking at the password field as a hassle.
Cracking passwords is too large a topic for one article, but I can highlight at least a couple of methods. The most basic and obvious is just plain guessing—which isn’t as mundane as it sounds. If you run some searches, you can find compiled lists of default passwords from many different products and manufacturers. (See the "References" section at the end of this article for a link to some default password tables.) I scan through the default password tables to make sure that the passwords I choose are at least not the easiest passwords to crack.
A more sophisticated method of cracking passwords involves the use of rainbow tables, which contain possible plain-text passwords. The table is used to programmatically iterate through and keep track of possible guesses. I haven’t worked with rainbow tables personally (yet). For more info, see the "References" section for websites that detail how rainbow tables work.