I would do, but I really don't like this approach to describing people - we are all rather more than a set of discrete competencies and by focusing on these kinds of measures (largely because they are easy to evaluate) I tend to feel that the really important factors in determining
success in this field are missed.
Level 2^n: uses string concatenation in his SQL, for web forms passes plaintext passwords around in Javascript, has already been rooted and doesn't know it.
Level n^2: uses stored procedures, knows that cross site scripting and sql injection is bad, stores passwords in a form other than plain text, may block certain kinds of 'naughty' inputs (e.g. http://xkcd.com/327/ )
Level n: uses whitelists to validate input, does not use windows or SQL Server for anything, understands that security has a price (eternal vigilance) can explain what salting and hashing are, can protect your password against malicious database admin.
Level log(n): can protect against social engineering, audits OpenBSD for jollies, has transcended the need for users to create accounts and enter passwords, is completely unable to communicate with outside world since all their email has been PGP encrypted since the late 90s.
Level n: as much as I dislike it, Windows' security isn't actually all that bad nowadays. This, of course, assumes that you don't ever start IE, install no Adobe products, configure it properly, etc - but that's common sense for a server. Also, "eternal vigilance"? I think you need one patch to make a five-year old OpenBSD server as secure as pretty much any other system out there.
Level log(n): again, you can be pretty secure without being completely useless. Should include HMAC and PBKDF2/OpenBSD's Blowfish scheme/scrypt. May include full-disk encryption.
(Note: The log(n) stuff was a mildly humorous reaction to the 'pie in the sky' nature of some of the log(n) levels in the article, though the concept of solving the identity problem without getting people to create usernames and passwords blew my mind recently)
I do however stand 100% behind the eternal vigilance comment.
I wasn't expecting an example so quickly, but this serves as a case in point:
But the problems with that script are primarily to do with selecting an option for mapping the binary hash value to a string that is really stupid (i.e. will generate all kinds of characters rather than a nice hex string) and then creating a SQL statement by string concatenation.
Anyone who is half sensible won't be doing either of these so I'm not sure what it proves.
Not stuffing binary data into an SQL query isn't "eternal vigilance", it's just "not stupid". And that particular issue isn't even really a security problem - it would fail (when someone randomly chooses a password containing a ') long before it was hacked.
