Password Resets and User Authenticity

With any application that requires authentication you will inevitably run into a password expiration and/or lockout issues that requires a user to reset their password.  I have seen organizations address this with a wide range of solutions from home grown programs all the way to multi-million dollar identity management frameworks.  While both solutions will help a user change their password it baffles me how many people forget to address this very basic paradigm:

how do I verify the user’s authenticity?

Most organizations I work with store their employee identity in either Microsoft Active Directory or in a 3rd party LDAP directory.  These directories typically limit authentication methods to either Kerberos or LDAP binding.  The advantage to using Kerberos is you can authenticate the user with an expired password to verify authenticity before changing their password.  This is how F5 Access Policy Manager changes expired Active Directory passwords when the feature is enabled.    With LDAP the binding process only works with valid username/password combinations and therefor leaves the authenticity challenge to the identity management program/framework.  So how can you verify the user’s authenticity before changing their password?

Email

Most users are familiar with the concept of using email to verify a password reset.  This process was very common with social media and e-commerce sites up until recently with the increased data loss issues we’ve seen in the news due to poor security or social engineering.  In this model the user is sent an email with a link that contains a unique token allowing the identity management framework to verify the user’s authenticity.  While this model is elegant in design it fails to address the issue that the password being reset it typically also the password used to access corporate email.  So for most organizations this solution is not viable.

One-time Passwords

One-time passwords, typically referred to as OTP, are a form of multi-factor authentication that use a randomly generated token to verify the user’s identity.  These tokens are only valid for a short amount of time and are delivered via email or SMS to a mobile device.  One-time passwords are my preferred method to addressing this issue with F5’s Access Policy Manager.  In the event that a password needs to be reset F5’s APM can handle verifying the user’s authenticity using OTP before allowing access to the identity management program/framework.

Knowledge Based Authentication

Knowledge based authentication is a process where the user is presented with common questions they know the answer to.  These questions, and the corresponding answers, are typically chosen by the user during a registration process but can also be based on employee/customer data.  This form of verifying user authenticity has become very popular with social media and e-commerce sites over the last few years as it puts the burden of protecting one’s identity on the user by choosing a secure combination of questions and answers others would not easily guess.

Ultimately, which solution you choose will depend primarily on what your identity management program/framework supports.  If your product does not have these capabilities then now is a good time to add them or find a identity management solution.

302 vs 307: All about the POST

Recently I was helping a customer address a multi-factor authentication bug where the 3rd party MFA solution would post the username and temporary token back to APM via the wrong URL.  While we worked with the partner to address this bug the customer needed a work around in the meantime… perfect time for an iRule!

For those not intimately familiar with APM when a client accesses the / URL APM create a session and responds with a 302 status code that:

  • sets the MRHSession cookie variable with the session id
  • redirects the browser to /my.policy to start the authentication process

If you issue another HTTP request to anything other than /my.policy APM will kill the previous session and create a new session; even if you include the MRHSession cookie in the HTTP header.

In our case we needed the MFA to post the username and token back to the /my.policy URL instead of the / URL.  My first thought was “this is easy enough”:

when HTTP_REQUEST {
  if {[ACCESS::policy result] eq "not_started" && [string tolower [HTTP::url]] eq "/" 
    && [string tolower [HTTP::header "Referer"]] contains "mfa.company.com"} {
    HTTP::redirect "/my.policy"
  }
}

However, we quickly figured out that while the browser honors the 302 and directs the user to /my.policy the browser does not POST the username and temporary token to the /my.policy URL after the redirect… this quickly put a damper on the iRule magic.  A quick Google search mentioned using a 307 status code to redirect an HTTP POST method.  I had never seen/used a 307 HTTP status code so this was new to me.  So we updated the iRule accordingly:

when HTTP_REQUEST {
  if {[ACCESS::policy result] eq "not_started" && [string tolower [HTTP::url]] eq "/" 
    && [string tolower [HTTP::header "Referer"]] contains "mfa.company.com"} {
    HTTP::response 307 Location "/my.policy"
  }
}

Sure enough that did the trick and forced the browser to post the username and temporary token to the /my.policy URL which allowed us to avoid creating a new APM session every time the user finished their MFA process.