… it is strongly recommended for the PHP developers to add more secure random number functions to the PHP core and it is strongly recommended for PHP application developers to keep their fingers away from srand() or mt_srand() and to never ever use rand() or mt_rand() for cryptographic secrets.

It sounds like the PRNGs in PHP, mt_rand() and rand(), shouldn’t be used for anything security-related, and perhaps /dev/random or /dev/srandom or some such should be used instead (though this is much more system-dependent).

• what was the one and only login cookie in 2.5 is now limited to /wp-admin
• there’s a copy of that one that’s just limited to /wp-content/plugins, for backward compatibility with plugins
• there’s a new cookie that is at COOKIEPATH (which can be defined in your config file), that is checked by calling

  is_user_logged_in()

  (but perhaps this isn’t intended for secure authorization?)

So, it appears the way to go may be to change

auth_redirect()

to

Maybe more to follow on this when I’ve more thoroughly explored it.

The good news is that there’s an action hook, ‘set_auth_cookie’, that gets called whenever the cookies are set, so if the stuff for which you want to authenticate is on the same server but at a different path, you can create a plugin (or maybe use functions.php in your theme?) with something like the following:

The bad news is that if your WordPress install is at example.com/something and you want to use it to authenticate at portal.example.com, you can’t set a cookie for portal.example.com from a script on example.com, so your only choice would be to set a cookie with path / on .example.com (note the leading period), which completely breaks the security added by the separate cookies.

Hopefully, there’ll be a “part 3″ to this wherein I solve this last problem somehow, since that’s the setup I’m dealing with.

As a security measure in WP2.6, login cookies are now split into what seem to be at least three different cookies—two with paths like /wp-admin and /wp-content/plugins that are the full cookie that auth_redirect() checks against and one that’s different, with path / [paths relative to the blog root].  Near as I can tell, this immediately breaks any attempt to use auth_redirect() for authentication (e.g. this and this) outside the /wp-admin and /wp-content/plugins directories.  It is also not immediately clear to me how to authenticate against the whole-site cookie, if there’s any way to do that at all.

A temporary, but very bad fix would be to completely defeat the security by defining ADMIN_COOKIE_PATH to be the site root, rather than the path to /wp-admin.  I’m thinking that, from a quick skim of pluggable.php, there might be plugin action hooks to allow setting other cookies that would allow authentication on other paths…

To make cookies secure against attacks where someone has managed to get into your database through an SQL injection exploit or other means, WordPress 2.5 introduced a user-definable constant called SECRET_KEY. If you look at the sample wp-config.php shipped with 2.5, you’ll see these lines.

// Change SECRET_KEY to a unique phrase. You won’t have to remember it later,
// so make it long and complicated. You can visit https://www.grc.com/passwords
.htm
// to get a phrase generated for you, or just make something up.
define(’SECRET_KEY’, ‘put your unique phrase here’); // Change this to a unique phrase

If you upgraded from a previous version of WordPress you probably won’t have these lines in your wp-config.php.

That last bit is, of course, the critical thing for me and had me going back and inserting SECRET_KEYs into all my older/upgraded WordPress installs.  Just remember that if you’re integrating with bbPress, you have to match the SECRET_KEYs in wp-config.php and bb-config.php.

… there is a wave of attacks going around targeting old WordPress blogs, particularly those on the 2.1 or 2.2 branch. They’re exploiting problems that have been fixed for a year or more. This typically manifests itself through hidden spam being put on your site, either in the post or in a directory, and people notice when they get dropped from Google.