The Role Of Mobile During Authentication

Nearly all the big player social networks now provide a multi-factor authentication option – either an SMS sent code or perhaps key derived one-time password, accessible via a mobile app.  Examples include Google’s Authenticator, Facebook’s options for MFA (including their Code Generator, built into their mobile app) or LinkedIn’s two-step verification.  There are lots more examples, but the main component is using the user’s mobile phone as an out of band authenticator channel.

Phone as a Secondary Device - “Phone-as-a-Token”

The common term for this is “phone-as-a-token”.  Depending on the statistics, basic mobile phones are now so ubiquitous that the ability to leverage at least SMS delivered one one-time-passwords (OTP) for users who do not have either data plans or smart phones is common.  This is an initial step in moving away from the traditional user name and password based login.  However, since the National Institute of Standards and Technology (NIST) released their view that SMS based OTP delivery is deemed insecure, there has been constant innovations around how best to integrate phone-based out of band authentication.  Push notifications are one and local or native biometry is another, often coupled with FIDO (Fast Identity Online) for secure application integration.

EMM and Device Authentication

But using a phone as an out of band authentication device, often overlooks the credibility and assurance of the device itself.  If push based notification apps are used, whilst the security and integrity of those apps can be guaranteed to a certain degree, the device the app is installed upon can not necessarily be attested to the same levels.  What about environments where BYOD (Bring Your Own Device) is used?  What about the potential for either jail broken operating systems or low assurance or worse still malware based apps running parallel to the push authentication app?  Does that impact credibility and assurance?  Could that result in the app being compromised in some way? 

In the internal identity space, Enterprise Mobility Management (EMM) software often comes to the rescue here – perhaps issuing and distributing certs of key pairs to devices in order to perform device validation, before accepting the out band verification step.  This can often be coupled with app assurance checks and OS baseline versioning.  However this is often time-consuming and complex and isn’t always possible in the consumer or digital identity space.

Multi-band to Single-band Login

Whilst you can achieve both a user authentication, device authentication and out of band authentication nirvana, let’s spin forward and simulate a world where the majority of interactions are solely via a mobile device.  So we no longer have an “out of band” authentication vehicle.  The main application login occurs on the mobile.  So what does that really mean?  Well we lose the secondary binding.  But if the initial application authentication leverages the mechanics of the original out of band (aka local biometry, crypto/FIDO integration) is there anything to worry about?  Well the initial device to user binding is still an avenue that requires further investigation.  I guess by removing an out of band process, we are reducing the number of signals or factors.  Also, unless a biometric local authentication process is used, the risk of credential theft increases substantially. 

Leave your phone on the train, with a basic local PIN based authentication that allows access to refresh_tokens or private keys and we’re back to the “keys to the castle” scenario.


User, Device & Contextual Analysis

So we’re back to a situation where we need to augment what is in fact a single factor login journey.

The physical identity is bound to a digital device. How can we have a continuous level of assurance for the user to app interaction?  We need to add additional signals – commonly known as context. 

This “context” could well include environmental data such as geo-location, time, network addressing or more behavioural such as movement or gait analysis or app usage patterns.  The main driver being a movement away from the big bang login event, where assurance is very high, with a long slow tail drop off as time goes by.  This correlates to the adage of short lived sessions or access_tokens – mainly as assurance can not be guaranteed as time from authentication event increases.

This “context” is then used to attempt lots of smaller micro-authentication events – perhaps checking at every use of an access_token or when a session is presented to an access control event.

So once a mobile user has “logged in” to the app, in the background there is a lot more activity looking for changes regarding to context (either environmental or behavioural).   No more out of band, just a lot of micro-steps.

As authentication becomes more transparent or passive, the real effort then moves to physical to digital binding or user proofing...

The Role Of Mobile During Authentication

Nearly all the big player social networks now provide a multi-factor authentication option – either an SMS sent code or perhaps key derived one-time password, accessible via a mobile app.  Examples include Google’s Authenticator, Facebook’s options for MFA (including their Code Generator, built into their mobile app) or LinkedIn’s two-step verification.  There are lots more examples, but the main component is using the user’s mobile phone as an out of band authenticator channel.

Phone as a Secondary Device - “Phone-as-a-Token”

The common term for this is “phone-as-a-token”.  Depending on the statistics, basic mobile phones are now so ubiquitous that the ability to leverage at least SMS delivered one one-time-passwords (OTP) for users who do not have either data plans or smart phones is common.  This is an initial step in moving away from the traditional user name and password based login.  However, since the National Institute of Standards and Technology (NIST) released their view that SMS based OTP delivery is deemed insecure, there has been constant innovations around how best to integrate phone-based out of band authentication.  Push notifications are one and local or native biometry is another, often coupled with FIDO (Fast Identity Online) for secure application integration.

EMM and Device Authentication

But using a phone as an out of band authentication device, often overlooks the credibility and assurance of the device itself.  If push based notification apps are used, whilst the security and integrity of those apps can be guaranteed to a certain degree, the device the app is installed upon can not necessarily be attested to the same levels.  What about environments where BYOD (Bring Your Own Device) is used?  What about the potential for either jail broken operating systems or low assurance or worse still malware based apps running parallel to the push authentication app?  Does that impact credibility and assurance?  Could that result in the app being compromised in some way? 

In the internal identity space, Enterprise Mobility Management (EMM) software often comes to the rescue here – perhaps issuing and distributing certs of key pairs to devices in order to perform device validation, before accepting the out band verification step.  This can often be coupled with app assurance checks and OS baseline versioning.  However this is often time-consuming and complex and isn’t always possible in the consumer or digital identity space.

Multi-band to Single-band Login

Whilst you can achieve both a user authentication, device authentication and out of band authentication nirvana, let’s spin forward and simulate a world where the majority of interactions are solely via a mobile device.  So we no longer have an “out of band” authentication vehicle.  The main application login occurs on the mobile.  So what does that really mean?  Well we lose the secondary binding.  But if the initial application authentication leverages the mechanics of the original out of band (aka local biometry, crypto/FIDO integration) is there anything to worry about?  Well the initial device to user binding is still an avenue that requires further investigation.  I guess by removing an out of band process, we are reducing the number of signals or factors.  Also, unless a biometric local authentication process is used, the risk of credential theft increases substantially. 

Leave your phone on the train, with a basic local PIN based authentication that allows access to refresh_tokens or private keys and we’re back to the “keys to the castle” scenario.


User, Device & Contextual Analysis

So we’re back to a situation where we need to augment what is in fact a single factor login journey.

The physical identity is bound to a digital device. How can we have a continuous level of assurance for the user to app interaction?  We need to add additional signals – commonly known as context. 

This “context” could well include environmental data such as geo-location, time, network addressing or more behavioural such as movement or gait analysis or app usage patterns.  The main driver being a movement away from the big bang login event, where assurance is very high, with a long slow tail drop off as time goes by.  This correlates to the adage of short lived sessions or access_tokens – mainly as assurance can not be guaranteed as time from authentication event increases.

This “context” is then used to attempt lots of smaller micro-authentication events – perhaps checking at every use of an access_token or when a session is presented to an access control event.

So once a mobile user has “logged in” to the app, in the background there is a lot more activity looking for changes regarding to context (either environmental or behavioural).   No more out of band, just a lot of micro-steps.

As authentication becomes more transparent or passive, the real effort then moves to physical to digital binding or user proofing...

Multi Factor Authentication using Duo Security

Introduction

Duo Security provides an array of security products including Duo Mobile which is a stronger method of authentication using a registered device per user. More details can be found here Duo Mobile.

OpenAM is able to invoke the Duo Security API with the “push” factor that uses a push notification to the Duo Mobile app installed on your device for one-tap authentication. Please note that the demo presented here is purely for instructional purposes.

Setup

The user and device are first registered with the Duo Security application platform. This is done by the designated administrator. Multiple integrations can be created per organization allowing categorization of user communities by device, geo location or other factors.

Configuration in Duo

 

You can setup certain users with special privileges such as “bypass”, etc.

The user-id in Duo Security must match the user-id in OpenAM’s user repository for the authentication to succeed.

Configuration in OpenAM

Chain the DataStore module with the custom Duo module.

Demo

The user simply has to enter username and password to OpenAM. After verification of username and password, OpenAM starts the Duo custom authentication module.

After hitting submit, the following placeholder screen is shown. This is automatically refreshed until the user accepts or rejects the logon attempt from their device.

The custom authentication module invokes the Duo REST API with factor=push, and username. The request is signed with the integration key and secret key. A transaction id is returned that is saved for polling the request in the next step. The user gets a push notification on their Duo Mobile app.

After opening the Duo Mobile app the user is presented with an accept/deny screen.

Meanwhile, OpenAM polls the Duo REST API using the transaction id to check if the user accepted the push-notification. If so, they are immediately logged into OpenAM.

The user may decline the logon attempt.

The user may indicate whether it was a mistake or seems fraudulent.

 

If declined, authentication to OpenAM is denied immediately.

 

Algorithm

Simplified pseudo-code for a custom authentication module is presented here.

func process[] {

    On LOGIN_START,

            get-transactionId-from-Duo-REST-API[]

            set-next-auth-state[poll-step]

    On STATE_AUTH,

               poll-Duo-REST-API[transactionId];

               if “waiting”, set-next-auth-state[poll-step]

               if “allow”, set-next-auth-state[LOGIN_SUCCEED]

               if “deny”, throw Exception

}

func get-transactionId-from-Duo-REST-API[] {

    invoke-HTTP-POST on /auth/v2/auth

}

func poll-Duo-REST-API[] {

    invoke-HTTP-GET on /auth/v2/auth_status

}

Source Code

OpenAM Duo Security module on Github

OpenAM 2FA using the TeleSign PhoneID Score API

Introduction

TeleSign PhoneID Score combines predictive data from multiple sources, including telecom data, traffic patterns, and reported fraud to assess the risk level of a phone number. The product provides a reputation score, ranging from 0 to 1000, a risk level, and a recommendation based on a user’s phone number. PhoneID Score provides a real-time score, risk assessment, and recommendation. The scoring algorithm is dynamically updated to match ever-changing fraud trends. In fact, whenever a user’s activities change so does the score. More information can be found at TeleSign .

TeleSign Verify SMS API can be used to authenticate a known user, verify a transaction, or block fraudsters from opening thousands of accounts on your site. TeleSign Verify SMS verifies users in real time by sending a one-time verification code via SMS to their mobile phone. TeleSign delivers SMS to more than 200 countries. More info can be found here.

Demo

A custom authentication module receives the user’s telephone number, and uses TeleSign PhoneID Score API to evaluate the risk level of the phone number. If the phone number is of acceptable risk (low or moderate), then the authentication module uses the TeleSign Verify SMS API to send a verification code to the phone number entered.

The API returns a risk level for the phone number. If the risk level is “allow”, the module will send a random verify code via the TeleSign Verify SMS API, and upon user entry, use the TeleSign Verify SMS API to verify the code.

If the risk level from Score API is “deny”, OpenAM will show a denied screen to the user. A deny response looks like this:

{"reference_id":"####","sub_resource":"score","errors":[],"status":{"updated_on":"2015-03-10T22:48:59.139040Z","code":300,"description":"Transaction successfully completed"},"numbering":{"original":{"phone_number":"####","complete_phone_number":"####","country_code":"92"},"cleansing":{"sms":{"phone_number":"####","country_code":"92","min_length":9,"max_length":12,"cleansed_code":105},"call":{"phone_number":"####","country_code":"92","min_length":9,"max_length":12,"cleansed_code":105}}},"risk":{"level":"high","score":959,"recommendation":"block"}}

If the user entered an incorrect code, the TeleSign Verify SMS API will indicate as such, and OpenAM will reject the login attempt.

If the verify code validates correctly, then the user simply has to enter their username to login to AM.

An low risk response from the TeleSign PhoneID Score API looks like this:

{"reference_id":"####","sub_resource":"score","errors":[],"status":{"updated_on":"2015-03-10T22:52:17.603141Z","code":300,"description":"Transaction successfully completed"},"numbering":{"original":{"phone_number":"####","complete_phone_number":"####","country_code":"1"},"cleansing":{"sms":{"phone_number":"####","country_code":"1","min_length":10,"max_length":10,"cleansed_code":100},"call":{"phone_number":"####","country_code":"1","min_length":10,"max_length":10,"cleansed_code":100}}},"risk":{"level":"low","score":1,"recommendation":"allow"}}

Note that TeleSign uses a global phone directory, so if you do not prefix your country code, it will take the first digit(s) from the phone from the left and use that to identify the country.

Source Code

Github

 

This article was first published on the OpenAM Wiki Confluence site: OpenAM and TeleSign Integration

ForgeRock Authenticator (OATH) in ForgeRock OpenAM 13

This blog post was first published @ www.fedji.com, included here with permission.

If you’re in possession of a Smart Phone that runs either the Apple iOS or Android, you may probably be interested to know that the ForgeRock’s newer version of its Access Management solution now has an Authenticator App for you. Once installed and the device registered with ForgeRock OpenAM 13, one could use this Mobile App to generate One Time Password to validate his/her identity and thereby gain access to resources protected by the OpenAM. Needless to add, the ForgeRock Authenticator Mobile App is available on Apple iTunes Store for the iOS users and the Google Playstore for the Android fans.

Once installed, you’ll see on your phone something close to what is in the picture below:

ForgeRockMobileAuthenticator
Here’s what I did with my copy of ForgeRock Authenticator App on my iPhone:

– Configured an Authentication Chain ‘myAuthChain’ in my OpenAM 13 instance
– The said chain consisted of two Authentication Modules namely DataStore & ForgeRock Authenticator (OATH)
– When a subject authenticates against the ‘myAuthChain’ Authentication Chain in OpenAM, he/she is prompted for the DataStore credentials (an embedded OpenDJ instance), which on success is followed by another prompt where the user can register his/her device (using QR Code), generate an OTP that can be used to gain access to the resources protected by OpenAM.

2FAForgeRockAuthenticator

If you are interested to see all of this in action, please spare five minutes to watch the video below.

Enjoy!

Related documents/videos:
ForgeRock Documentation
Smart Security Using Phone App Demo

It’s Not Unhackable, But Twitter Makes a Start

This week Twitter introduced a new two-factor authentication process to verify account logins.  This comes on the back on some pretty big Twitter account hacks in recent months.  Now, whilst you can argue that it is not Twitter (or any other service providers) responsibility for you to keep your account details secure, they potentially do have a duty to some extent to make increased security an option if an end user does want to use it.

A typical end user isn't particularly interested in security.  Yes, they don't want hacking, yes, they don't want to have their bank details stolen, or their Facebook timeline polluted with nasties, but a typical end user won't actively take extra steps to avoid that from happening.





The concept of strong passwords is pretty much standard these days.  At least 8 characters, an uppercase letter, a number and / or a special character too.  End users have a list of passwords in their minds that fit the criteria.  Unfortunately these passwords are probably being recycled across every site that requires a 'complex' password, perhaps incrementing the number at the end every time it expires.

The use of secondary verification, become familiar for typical web users, when Facebook verification was introduced a year or two back.  If you login to Facebook from an unknown device or network location, you are asked to go through an additional set of verification steps.  This could include security question responses (knowledge based authentication), mobile verification or the most interesting in my mind, confirming you know the people in selected photos from your albums.  Again this is a form of KBA, but without the need to set up or remember arcane questions about your first pet or primary school.

To set up Twitter's additional verification isn't particularly complicated.  A couple of minutes setting up a phone to use as the registered verification device and a few test text messages and you're done.  Albeit the mobile anti-virus scanner on my phone flagged the responding text message from Twitter as 'suspicious' made me smile.

But will this extra step prevent hacks?  The simple answer is no, well yes in some cases, but maybe in others!  Basically there is no simple answer.  Of course it makes cold hacking a lot more difficult, due to having to break something someone knows (the password) alongside breaking the physical something someone has (the phone).  However, what happens if you lose your phone?  I for one do most of my tweeting from a smartphone as many others do to.  For a single end user that could pose an issue as both the Twitter client will undoubtedly have a cached password and obviously the physical phone is able to receive the text message for verification.

However, in corporate PR scenarios a large client may require a team of 3,4 or more executives managing the Twitter account.  Twitter is alive 24x7 and no one individual could manage that for a large consumer client.  This therefore results in multiple machines and potentially multiple clients.  Whilst those clients can be authorised, the security risk is spread as you have multiple access vectors for malware, accidental misuse, malicious misuse and so on.  So whilst Twitter has upped its game on the backend, end users still have a duty with regards managing who has access to the account in general and how those users are managed and vetted.

If nothing else, the introduction of an additional authentication factor increases the information security awareness for the typical end user and starts to make security a much more common step when using services and websites.  The important step next, for Twitter and others, is to make sure there is a larger security 'reward' for those who do engage in the extra steps.

By Simon Moffatt