IBM Security Global Forum

Scenario Overview

A lot has been said and written in the identity and access management security field about the problems with passwords. Most of these issues are related to human factors – we write passwords down, we use the same password on multiple sites, we use simple pattern-based passwords so we have a chance of remembering them even when forced to change them regularly, etc. All these issues are real, and result in an authentication landscape which is easy pickings for skilled hackers.

As businesses continue on their relentless march toward digital transformation, identity fraud looms large as a problem that must be tackled. The primary tool for tackling identity fraud (reducing risk) in access management systems is to increase confidence in the authentication process – are we really dealing with the person we think we are dealing with? This typically results in a move toward 2-factor authentication methods such as hardware security tokens, one-time passwords, mobile push authentication, FIDO 2.0, biometric authentication and others. All of these approaches have value and are either complimentary, or in some cases alternatives, to the topic of this article – password-less login.

The issue I see with a lot of two-factor authentication systems is that the first factor is usually still a username and password, and this username and password is still part of every authentication and session establishment sequence the user has with your site. What I’m going to propose in this article is an alternative form of authentication for users that is arguably much more convenient than a password, provides better security than a password, and may be used as either a standalone authentication method or as a first-factor authentication in a risk-based 2FA architecture (such as the one I described in my previous article: https://www.ibm.com/blogs/sweeden/using-federated-sso-access-policies-conditional-two-factor-authentication/).

This is the password-less user experience we are going after:

1. A user visits your site with a browser (for simplicity, let’s consider this a desktop browser though that is not strictly a requirement). On the login page, they have a choice for password-less login, which they select:

2. A QR code is displayed:

3. The user opens up a previously-registered mobile application and scans the QR code:

4. With no further interaction on the desktop, the browser is logged in as the user:

Let’s see how this scenario can be implemented using ISAM and IBM Verify.

Recommended pre-requisites for implementing the scenario in this article

A minimum of ISAM 9.0.4.0, and updated IBM Verify mobile application (1.0.7 for iOS, 1.0.9 for Android) is required.

This article is deeply technical and focused on how to actually implement the above scenario with ISAM and the IBM Verify mobile application. It is assumed that you are familiar with both these technologies and have some practical hands-on experience configuring the technology.

There is a very detailed cookbook for ISAM and IBM Verify, available here:

http://ibm.biz/verifycookbook

The steps outlined in this article may be applied as an extension to the setup of an ISAM appliance as demonstrated in the Verify Cookbook. We will use the completed cookbook configuration as a starting point for the steps shown here.

Readers who are also familiar with the OAuth Device Flow draft specification (https://tools.ietf.org/html/draft-ietf-oauth-device-flow) will find many parallels to the approach shown here, although the actors are a little different. In the approach here the “device” is the user’s browser, the “end user verification code” (also called user_code) is part of the QR Code shown to the user on the browser, and the act of the end user presenting the user_code to the authorisation server is achieved by scanning the QR Code with a registered instance of IBM Verify.

Note: If you have an ISAM deployment that is using OAuth with your own developed mobile application, you can definitely modify that application to do the same things that IBM Verify is doing here. I am going to use IBM Verify in the article (because it’s a publicly available application), however your own application is a perfect candidate to realise the same scenario.

Understanding the flow

The following web sequence diagram demonstrates precisely what is going on during the password-less login sequence:

The key endpoints on ISAM for implementing QR Login are implemented as InfoMap authentication mechanisms and policies. If you have completed the Verify Cookbook, you would be aware that these are programmable authentication mechanisms in the Advanced Access Control authentication service. I have previously written articles that discuss how Infomap mechanisms work:

• An Introduction to the InfoMap Authentication Mechanism
• Some more InfoMap examples

In the next phase of this article I will simply provide the instructions necessary to configure and test the scenario.

Detailed Configuration Steps

The assest required to configure this scenario can be found on my public github repository here: https://github.com/sbweeden/blog_assets/tree/master/qrlogin

I suggest you clone or download the repository to extract these resources.

Updating then loading template pages

Under the qrlogin/template_pages directory, you will find a whole range of prepared template files. The following table gives a brief description of the purpose of each file

You first need to update the metadata.json file to update the "qrlogin_endpoint" value to indicate the hostname or IP address of your ISAM server, as seen by the IBM Verify mobile application. The port number is the port of the mobile WebSEAL instance. This will typically be the same as the endpoints defined for all of your other MMFA Endpoints. You can check under Secure Access Control -> MMFA Configuration:

Update metadata.json to match. In my case it is:

{
"service_name":"MMFACookbook",
"qrlogin_endpoint":"https://9.235.65.254:444/mga/sps/apiauthsvc?PolicyId=urn:ibm:security:authentication:asf:qrlogin_response"
}


This endpoint will become part of the metdata that IBM Verify discovers when scanning the QR Code for password-less login.

Other page template file updates are of course also permitted, but not necessary to make the scenario work. I strongly suggest using them as-is until you have the scenario functional.

After metadata.json is updated, load all of these files into ISAM using Secure Access Control -> Template Files in the administration console. You can do this by first creating a zip, and then importing the zip.


cd qrlogin/template_pages
zip -r myfiles.zip C


The myfiles.zip should have all the C/** files in it. This can be imported into ISAM.

Deploy pending changes after importing the zip file.

Uploading mapping rules

There are two mapping rules to import into ISAM. These are:

Upload these mapping rules to ISAM using the administration console, as shown:

Deploy pending changes after uploading the mapping rules.

Creating authentication mechanisms and policies

Create an InfoMap Authentication mechanism based on each of the imported mapping rules. This is done with in the administration console with Secure Access Control -> Authentication -> Mechanisms.

The configuration properties for each mechanism are shown below:

Deploy changes after the authentication mechanisms have been created.

Create two new authentication policies, each containing just one InfoMap mechanism corresponding directly to the two newly created mechanisms above. This is done with in the administration console with Secure Access Control -> Authentication -> Policies. Be sure they are “enabled”. The configuration for each is shown below:

Deploy change after the authentication policies have been created.

Updating WebSEAL ACL policy

Configuration of the Verify Cookbook includes the establishment of an access control list (ACL) and protected object policy (POP) that we want to re-use here to allow unauthenticated access to the QR code generation servlet. This is required so that the QR code can be generated while the user is not yet logged in. The following pdadmin commands can be used to attach the ACL and POP to the correct location:

pdadmin sec_master> acl attach /WebSEAL/isam.mmfa.ibm.com-default/mga/sps/mmfa/user/mgmt/qr_code isam_mobile_rest_unauth
pdadmin sec_master> pop attach /WebSEAL/isam.mmfa.ibm.com-default/mga/sps/mmfa/user/mgmt/qr_code level0pop

This can of course also be achieved with the administration console, however the command-line tool is generally easier to use for this exercise.

This completes configuration of all elements required for the password-less QR Login scenario.

Testing the end-to-end flow

You should already (from the Verify Cookbook), have a registered and working instance of the IBM Verify mobile application. If not, or if you wish to re-register, this can be done from the device management page:

https://www.mmfa.ibm.com/mga/sps/mga/user/mgmt/html/device/device_selection.html

You should be able to login with testuser/Passw0rd to access this page.

Now, starting from a browser in an unauthenticated state, access the following URL to initiate password-less QR Code login:

https://www.mmfa.ibm.com/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:qrlogin_initiate&Target=https://www.mmfa.ibm.com/app/mobile-demo/diag

The Target parameter can be any protected application on the WebSEAL server. We use the mobile demo application diagnostics page as it was previously set up and used in the Verify Cookbook.

This kick-off URL can be easily tied into the existing WebSEAL login.html or other ways of initiating authentication in your ISAM environment.

You should see a QR Code displayed, such as the one below (it is an interesting exercise to open browser developer tools and watch XHR requests while the browser is polling the API authsvc to check on the state of the session):

Using your IBM Verify mobile application, scan this QR Code just as you would to register a new account.

Without touching the browser you should see login complete and be transitioned to the target URL, as shown:

If you got this far, congratulations, you have successfully implemented password-less QR Code login using ISAM and IBM Verify!

Simulating IBM Verify with another browser

In case you don’t have a registered copy of IBM Verify, you can simulate the backchannel flow with another browser (other than the one you’re trying to do QR Login from). First update the QRLoginResponse mapping rule to set the flag:

var enableBrowserLSIEntryForTesting = true;

Now use your “backchannel” browser, and first login to ISAM via any protected page. You have to pre-authenticate in this manner as we do not require authentication to get to the API authsvc (since this endpoint is also used by the other webseal to poll during the authentication process). Visit the backchannel URL with your browser where you will be able to enter the login session index (LSI) to authenticate. The LSI is shown on the QR Code login page in clear text just for this reason:

https://www.mmfa.ibm.com/mga/sps/authsvc?PolicyId=urn:ibm:security:authentication:asf:qrlogin_response

Entering the LSI and pressing login on the backchannel browser will automatically login the user on the QR-Code “frontchannel” browser. This shows an almost identical approach to that described in the OAuth Device Flow specification except that instead of provisioning an access token and refresh token to a device, we are provisioning an authenticated browser session to a browser.

Security Considerations

There are a lot of things to think about when looking at potential attack vectors for any authentication method and system. The same is true for the approach of scanning a QR code with a mobile application to achieve password-less login. Let’s take a look at some of the primary considerations.

Security Considerations from the OAuth Device Flow

As this approach is quite similar in nature to the OAuth device flow, I would highly recommend taking a look at the security considerations documented in that flow and applying them to the deployment of password-less QR Login. See section 5 of: https://tools.ietf.org/html/draft-ietf-oauth-device-flow

Many of the other considerations outlined below are variations of considerations in the OAuth device flow applied specifically to the context of password-less login in the browser.

Registration of IBM Verify

The initial registration of IBM Verify (or your own mobile application) against the user’s account must be done under a strongly authenticated context. Said another way, your system should be really confident the user is who they say they are before you allow them to register the mobile application. Given that the possession of the registered mobile application (and more importantly it’s access token and refresh token which are essentially secondary passwords for the account) is all that is needed to perform password-less login, then it is essential that an attacker can’t use a weak form of authentication to register the mobile application in the first place. Strongly authenticating the user may be inconvenient (for the user this may mean higher friction), however that should be a one-time operation.

Mobile Application Development Considerations

The refresh token established during mobile application registration (and any associated access token) must be managed as a secret by the mobile application. Tokens should be securely stored (based on device capabilities) and not shared with any other untrusted applications or endpoints other than their intended destination. For refresh tokens this must be only the token endpoint of the issuing authorization server, and for access tokens this should only be a trusted resource server endpoint. Just like for any other OAuth 2.0 solution, properly applied transport-level security is essential.

Session Phishing

If an attacker is able to trick a victim into scanning the attacker’s QR Code, then the attacker is able to login as the victim. This is quite similar to password phishing (tricking a victim into providing their username and password to an attackers login form) except that the attacker doesn’t directly gain access to the victims long-lived secret. Depending on the website or application capabilities though, the attacker may then be able to do other things as the user (such as register another device, change the password, etc) to gain complete control of the victims account. The same types of mitigations as used to prevent password phishing apply. This includes both technical considerations and an ongoing education campaign for users about risks and best practices.

Entropy and Lifetime of Session Indexes

The flow described in this article utilises a couple of short-lived indexes considered confidential beyond the refresh token and access token used by the mobile app. These are the login session index and the device session index. These are analogous to the user_code and device_code from the OAuth device flow. In the case of password-less QR Login it is not really required that the login session index be human readable and manually transferred from the device (browser) to the authorisation server because it will be scanned in, therefore it can be of much higher entropy than that typically seen in other device flow deployments. In actual fact there is really no need to have a separate login session index and device session index – they could be the same value as both are sent to the browser and are therefore exposed to the user (resource owner). The device session index is really not a secret known only to the device. For the sake of keeping the flow as analogous to the OAuth device flow as practical, I did split them out into their own values in this article. In this manner it’s possible to design a user experience where the login session index is of lower entropy and typed into the mobile application (or other authenticated client) rather than scanned in via QR code. This was demonstrated in the testing section. Why you would want to do this is questionable – possible scenarios include a helpdesk application or to afford a limited use single session to a trusted family member. My advice – make both indexes of high entropy and short-lived. Lifetime should be just long enough for the user to comfortably get out their phone and scan the code, maybe 2 minutes.

Conclusion and next steps

I hope that this article has shown you how password-less login can be integrated into ISAM. The approach is very practical for systems where a registered mobile application is already in use by end-users. The password-less approach can augment (does not have to replace) existing traditional username/password authentication, and can also be used as part of a more elaborate risk-based authentication scenario that might include other 2-factor mechanisms.

If you have any questions about this scenario, or trouble deploying it, please feel free to reach out and I’ll do my best to help.