I'd at least take the sleep() out. That way, you get rid of the super easy DoS vector. If someone were to deploy this on their shared webhosting, they'd find th

I'd at least take the sleep() out. That way, you get rid of the super easy DoS vector. If someone were to deploy this on their shared webhosting, they'd find themselves with a very upset host. You're using the very fast md5/sha1 (why both?) functions for password hashing. PHP has bcrypt support; why not use it instead? That a) accomplishes the goal of making brute-force untenable, and b) further protects your users' passwords in case you ever accidentally introduce a SQL injection (which, if you continue to work on this project, you probably eventually will; no personal offense - that's a big part of why more comprehensive frameworks that try to abstract away from raw SQL exist. Human make mistakes, especially in 6000-line superfiles ;) Edit: Also, your password updates (and other POST-ish operations, except commenting) don't have any kind of CSRF protection, so I could reset your password if I can get you to interact with a page where I've set up some "proof of concept" of something you might find interesting, with a form to post to yoursite.com/?p=savesettings&password=0wned, at which point I just log in and take admin control of the site. Since you don't ask for a username on login, such an attack would be extremely trivial. (As another commenter mentioned, it's easy to discover that much of the 'bloat' is actually stuff you want!)