Well, mySQL translates bool as a byte field anyway, so you're adding a byte to each record - but who cares? Even with a million users, that's only one MB additional, and disk space is cheap. I know it bothers some people's delicate sensibilities, but I feel this is a bad argument for putting authentication in a whole separate table.

Am I correct that the MD5 hashes are only crackable if you can get your hands on a sample of the database contents, and can figure out what items are going into the hash? If so, it doesn't really matter much that MD5 is crackable, since if your database is open to intruders, your site is probably already doomed. All the intruder has to do is rewrite your login page to save user names and passwords to a file, or send fake authentication emails to people, or a wide variety of other methods.

Yes, long URLs can be a problem, and I suppose you could save the timestamp in the database and send only a user ID and hex hash key. I don't think injection is a major likelihood though if you only access the record based on user ID, and untaint that before passing it to the database. The only variable you're sending the database is an integer, which is easily verified.