Yep, most of our supposedly easy-to-remember-hard-to-crack strategies fall pretty quickly when we're informed that there must be a symbol - but not that one, that one, that one, or that one - and there must be a capital letter and there must be a number, oh and sorry your password is now too long. So now we need to remember our standard phrase AND the fact that for THIS website we couldn't use that symbol so we had to put in another and we had to stop after 6, 8 or 10 characters which meant we had to move the number to the front...

Passwords should never be stored as plain-text, but as a big long hash. So 'ThisIsMyPasswordForNatWest' becomes 'a64b8d3190050e4600ed3352cb05e5fb9a54c6dc' under a hashing system called SHA1 for instance, and you can't take that hash and reverse it and get the password. A per-account string of random characters should be added to the user's password too - this alone makes it virtually impossible to crack a password. So long as no website stores your password as plain-text then you're in the clear.

The problem is that you can't trust websites to not store passwords as plain-text, and you have no idea if a website is there just to suck up people's passwords and password strategies. Or even if a company has a website and just one developer decides to make copies of submitted passwords or figure out people's password strategies.

If you're into Computer Science and White-Hat Hacking in particular, read on.

“As applications have become more complex, and their importance has skyrocketed, bolt-on security approaches are no longer cutting it.”

In “Mastering Kali Linux for Web Penetration Testing” by Michael McPhee.

Hah... memories of a rather expensive inter-bank trading system we were offered one time to test. Examining the executable revealed a few plain text strings, one of which (the name of a biscuit in upper case) stood out as dubious, and turned out to be the encryption key for all communications (“super-duper unbreakable encryption" was one of their selling points) ... With that, and a little bit of poking around, we reached the stage where we could send a message to another counterpart offering them a product at a certain price, and then we could send a message that told the server they'd accepted it (forming a legally binding contract - notional values for these goods were of the order of millions and tens of millions of dollars). Being nice guys, we didn't do this for real (the above was done on the QA rig), but rejected the software. When we explained why, the vendors told us what we did would be "a breach of the license terms", and couldn't understand why we fell about laughing... especially after the way they "patched" the holes (obscured the encryption key with, I kid you not, ROT13.)

Names above withheld to protect the incompetent...

If you're into Computer Science and Web PenTesting in particular, read on.