Hacking WordPress Login and Password Reset Processes For My University Environment

Any university worth the title is likely to have a very mixed identity environment. At Plymouth State University we’ve been pursuing a strategy of unifying identity and offering single sign-on to web services, but an inventory last year still revealed a great number of systems not integrated with either our single sign-on (AuthN) or authorization systems (AuthZ, see difference). And in addition to the many application/system specific stores of identity information (even for those systems integrated into our single sign-on environment), we also use both LDAP and AD (which we try to synchronize at the application level). Worst of all, the entire environment is provisioned solely from our MIS database, which is good if you want to make sure that students and faculty get user accounts, but bad if you want to provision an account for somebody who doesn’t fit into one of those roles.

The one way relationship between our user accounts and the MIS database also makes it difficult to engage with new users online. If you can’t get an account until you become a student, how do you allow potential students to apply online if all your systems are integrated with single sign-on? And if you can’t authenticate the online identity of your users, how do you set initial passwords into your system? Or allow them to reset a forgotten password online?

Internet companies never struggled with this issue, as their customers could only approach them online, but most universities built systems around paper applications and have fond (and relatively recent) memories of offering their students their first internet experience. It’s still not unusual for universities to offer their students their campus computing account with a default password based on supposedly secret data shared between the user and the school. But your SSN, birth date, and mother’s name are no longer secret. A proposed change in FERPA policy (see the the top of page 15586 in the NPRM) would have barred the use of “a common form user name (e.g., last name and first name initial) with date of birth or SSN, or a portion of the SSN, as an initial password to be changed upon first use of the system” in systems that store academic data. The final rule excluded that provision, much to the relief of those schools with more lobbying clout than brains.

Platform Choices

Rather than wait to see how the ruling played out last year, we went to work trying to improve security while easing access to our systems (no, that is not self-contradictory). Our challenges were thus:

• Fix initial password assignment
• Fix password resets
• Allow users with a loose or undefined relationship to the institution to create limited accounts for the purpose of interacting with the institution or its members

We considered a number of paths to a solution, including hacking of our university portal (which hosts the CAS single sign-on in our environment), expansion of a limited home-built solution, and a review of commercial and open source products and frameworks. We simplified the problem by confirming that the FERPA rule did not require us to authenticate the “real life” identity of a person; rather, we had only to validate the online identity of a person (saving us from needing to do things like send confirmation PINs by postal mail to a person’s home address).

In the end, we chose WordPress MU. Significant factors were our experience with the software (all the MIS developers use it personally), the extensibility of it as an application platform, the development focus on user experience (especially in recent versions), and our interest in using it as a framework for other user-facing services (especially BuddyPress).

Our Needs vs. WordPress

• The system must serve as the front end to our single sign-on environment, using our AD and LDAP password stores to authenticate users who have accounts in those systems.
• External email addresses, once verified with some challenge/response, can be used to reset a password.
• Users who are presently affiliated with the school have a school-provided email address, but no external address with which to reset their lost passwords.
• Users who are not presently affiliated with the school have no school-provided email address, and must verify their external email address before their account is activated. They can then set their own password once they verify their email address.
• The ability to send password reset codes via SMS would be nice (especially considering the number of long-time employees of the university who do not have personal email accounts), though that also requires the verification of the user’s cell phone number.

After reviewing what we wanted to do, we surveyed WordPress’ code to develop an implementation plan. And, because a number of aspects of our application process were changing, we decided to focus on allowing current users to self-reset their password and postpone development of account self-creation features for new users. Still, a few issues quickly emerged:

• WordPress requires a username be assigned to each user, rather than relying on email address (this is likely to change in WP 2.9) Creating a new username for our users is unacceptable, but adding a large number of new users to our existing username space will quickly deplete the “good” usernames. And changing a user’s username as their affiliation with the institution is unacceptable.
• The core user authentication function can be replaced with our own function. (And in 2.8 it became filterable)
• WordPress MU will validate email addresses, but the system isn’t built to be extensible.
• WordPress only stores one email address per user, but the user meta system can be used to store a second one. Unfortunately (and in a manner inconsistent with post meta), only one value per meta key per user is allowed, making it difficult to allow users to have an arbitrary number of email addresses associated with their account.
• The function that identifies a user by a given email address can be replaced with a function that also checks the secondary address.
• WordPress user profiles have no phone field, but the user meta system can be used to store one. A function to identify a user by a given phone number must also be created.
• Unlike some settings pages, the fields on the user profile editor cannot be changed simply by modifying the $wp_settings_fields array.
• Upon doing a password reset, the user is sent a temporary password, rather than being allowed to set a new password. This contradicts University policy about how passwords are used and communicated and could train users that sending passwords by mail is acceptable.
• The various functions in <a href="http://core.trac.wordpress.org/browser/tags/2.7/wp-login.php">wp-login.php</a> cannot be replaced, and in WP 2.7 the code had no way to add or replace various login actions (WP 2.8 changed that).
• WPMU-specific functions don’t always follow WP coding standards or models.

(Note that we began our work and deployed the system under WPMU 2.7. WPMU 2.8 included a few changes that made the process easier. I’m proud to say that some of those changes were a result of code we offered back to WP during our development.)

What We Did

• We decided that email addresses (both PSU addresses and external addresses), as well as PSU usernames would be acceptable identifiers for an account, and that a person should be able to log in to our web services using any of those identifiers. So…
• We replaced wp_autenticate() with our own function that accepts either email address or university username, checks to see if the user exists locally, checks to see if they exist in AD or LDAP, confirms their password, provisions their WordPress account (for university users who’ve not logged in via this method yet), establishes a session with our university portal and redirects them there (unless $redirect is set to something more specific that the dashboard).
• We decided to replace WordPress’ usernames with a random string matching a pattern we established. This became the WPID. Doing this required us to hide references to username (easy if you set a preferred display name)
• To store phone numbers and secondary email addresses, and allow users to edit those within their profile, I created the Alternate Contact Info plugin (browse source). This requires more use of output buffering than I’d like, but it gets the job done.
• To confirm email addresses and phone numbers via a challenge/response message (and support other interactions), I created the WordPress Ticket Framework plugin (my introduction, browse source).
• To send messages via SMS, we used my wpSMS plugin (in the plugin directory, browse source).
• Matther Batchelder re-skinned the login screen via a plugin that inserts our custom CSS.
• After determining that our university portal could not be made to authenticate via CAS, I gave up work on my wpCAS Server plugin and developed another method to initiate the portal session (which then establishes a CAS session using the portal’s CAS server).
• We replaced most of the functionality of the wp-login.php page (by hacking core at first, then taking advantage of the action hook in 2.8). In doing so we were able to change the password reset behavior to allow users to immediately change their password after entering their reset code (which was sent to their email address or phone via SMS).

Over time we extended the system to host multiple domains and replace our CMS. Soon we’ll consolidate our  public blogging instance into it, and we’re building an invite system that we can use to invite people to join our community.

What It Looks Like

The re-skinned WordPress login

Entering an email address or username to get a password reset code

SMS text with password reset code

Enter the password reset code from the SMS text message here, or follow the link from the email

Extended contact information in the WordPress profile

And that’s how we replaced our authentication system with WordPress, gained self-service password resets, and built the foundation to invite new users into our system.