4 ms·

Yeah, that's pretty fair. It's little more than protection against automated scripts which scrape the net looking for easy ways in (as is my comment spam protec

Yeah, that's pretty fair. It's little more than protection against automated scripts which scrape the net looking for easy ways in (as is my comment spam protection). There's not a huge amount to be gained by building a super sophisticated anti-spam or anti-brute-force system until it's likely that someone will actually write an attack specifically for this software, and seeing as I built it mostly for my own use, anyone who did that is probably just trying to do damage to me (for whatever reason).

cheald 14y ago
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!)

cheald 14y ago

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!)