4 ms·
Some comments: 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,
by JoachimSchipper 16y ago
Some comments:
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.
- Stormbringer 16y ago(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: http://cvk.posterous.com/sql-injection-with-raw-md5-hashes http://cvk.posterous.com/sql-injection-with-raw-md5-hashes
- JoachimSchipper 16y agoNot 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.
- arethuza 16y agoBut 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.