Reduce Password Proliferation.. OAuth 2.0 is your friend.. - Part 1

Disclaimer : The opinions expressed in this article are my own & doesn’t reflect that of organisations current or past I have been involved with. Open Banking / PSD2 - What is that?? Open Banking came to effect on the 13th Jan 2018. It was mandated by the UK's Competition and Markets Authority (CMA) in 2016 to the 9 biggest banks in the UK (HSBC, Barclays, RBS, Santander, Bank of Ireland, Allied Irish Bank, Danske, Lloyds and Nationwide) to have the capability to expose the information they hold about their customer in their bank accounts and to provide provision to instruct payments through APIs in a secure and standardised way for other entities like Challenger banks or Fintechs (referred to in the standards as Third Party Providers - TPPs ). APIs or Application Programming Interface is a mechanism by which one or more IT systems make use of the service offered by another in a pre-defined and standard way. For example, it is the way Uber makes use of Google Maps in its App. This was aimed at levelling the playing field and promoting innovative products and services for the consumers. For example, the transaction history stored in a customer's bank account is a treasure trove of information like what are their earnings, how much they spend on utilities / Grocery / Insurance / Mortgage etc. This information can be utilised by TPPs to provide meaningful analysis or the TPPs can act as service providers to pay for goods and services. As an example, if you are a multi-bank customer, the TPP could provide a consolidated view of your finances across your different bank accounts. Though Open Banking superficially looks more like its directed against the big banks, nothing stops the traditional banks from turning the tide by utilising the same capabilities to launch innovative offerings themselves or by partnering with / acquiring other FinTechs. If that got you concerned about the security and privacy impact, there are 2 aspects to consider. Firstly the TPPs providing these services need to undergo rigorous security and compliance process to be licensed and are regulated by the FCA (Financial Conduct Authority).Apart from this they also need to make sure that they have the proper process and procedures to handle one or more of the likes of GDPR, PCI-DSS etc to name a few. Secondly, access to customer's data would need informed and explicit consent from the account holder (which can also be revoked at a later point in time) with stronger authentication to prove the higher level of assurance. The consent aspect also has a tie-in with EU GDPR Directive. Hence privacy and security are key underlying requirements as part of this directive. Opening up the account data and to provide the ability to perform payments also forms part of the EU's 2nd Payment Service Directive (PSD2) which is the latest European legislation on payment standards. One of the key aims for Open Banking was to be compliant with the PSD2 regulation. Interestingly, though the initial scope for Open Banking was only to cover the Personal and Business Current Accounts, the latest change in scope (as of Nov 2017) aligns it closer to the PSD2 scope. i.e cover all payments accounts covered by PSD2 including savings accounts, credit cards, loans, mortgage and even multi-currency accounts. All these additional elements added to the existing scope would start to be implemented in a phased manner running until Aug 2019. As mentioned earlier, apart from the possibility of account aggregation, PSD2 / Open Banking brings in the possibility for another capability that can be exploited by TPPs - instructing payments on your behalf. So, payments can be made through likes of Facebook messenger / Whatsapp. A more creative application to this might be AI based financial services that can automatically sense that your current account is approaching the minimal threshold balance you had set and automatically move money out of another account of yours held in a different bank into this account... provided you have consented the TPP for this. The PSD2 directive identifies two types of TPPs - Account Information Service Providers (AISP) and Payment Initiation Service Providers (PISP) . AISPs are providers of service that can access customer's bank account on behalf of them and retrieve information for which they have been consented by the customer. Alternatively, PISPs are TPPs that can initiate payment transactions on the customer's bank account for which they have been provided consent. Please note that both AISP and PISP are distinctly defined roles. i.e one cannot do what the other can. Though the same TPP can be registered and licensed to act as both AISP and PISP. So, What is in it for the Retailers In the current world, when a purchase is made on the Retailer's website using credit/debit card, the retailer's transaction has to go through a series of intermediaries ranging from the acquirer to the card scheme provider etc. A charge is added to the transaction directly or indirectly at every stage. The overall additional charge added is usually in the region of up to 2 - 2.5% of the transaction value in total. With most retailers not able to pass this surcharge to the customer, guess who picks the bill??

This is a continuation from the Part 1 of my post in the same topic. I would suggest reading the previous part before embarking on this post. I had a good read of your previous post.. Now, take me through how different is the OAuth 2 route as against the 'Password Anti-Pattern' Route.. Alright...Taking the example of the Mail Aggregation website (KoolAgg) we discussed earlier, The Resource Owner (the end-user) delegates the authority to the Client (eg: KoolAgg) to make API calls to the Resource server (GMail Mail Server). KoolAgg (assuming its registered with Google as mentioned in the pre-requisites), sends an authentication request passing its ClientID , Scope required and a RedirectURL . The user is presented with a page from the Google Server requesting grant of access (User Consent) and in the event of a Grant from the user, redirects request back to the browser with the “Authorisation Code”. The client again sends a fresh request with the “Authorisation Code” along with its ClientID and RedirectURL to the Google Auth server to exchange it for an “Access Token”. The Google Auth Server on successful validation sends back a response to the RedirectURL with an “Access Token” and optionally a “Refresh Token”. The client then calls the Google mail API in the resource server armed with the “Access Token” to retrieve the emails from Google which it can aggregate after performing a similar operation on the Yahoo Server too. Great.. I am now getting a hang.. That’s a lot of Token types going around isn’t it? A bit more detail on these and the other terminologies might be of help. The “ Access Token ” is used by clients to make authenticated requests on behalf of the Resource Owner to the Resource Server. The Access Token can grant access to multiple APIs (which boils into features). The set of features that is permitted to be granted access is controlled by a parameter called “ Scope ”. The value and meaning the scope parameter is defined by the Authorisation Server. This parameter needs to be sent with one or more values as part of the Access Token request sent to the Authorisation Server. Access Tokens are valid only for the set of operations and resources as set in the scope of the token request. This is enforced by the Resource Server. This is the reason the Access Token is often equated to a “Valet Key” which only allows you to perform a limited set of functions (scope) and is time bound (access duration) unlike a full key. Access tokens have a definitive lifetime that is often shortlived, which means that if the Access Token expires, the user would need to perform all the procedures that he did earlier for the access token to be provided. This can affect the user experiance. At the same time it is not safe to have a long lifetime for Access Token since in the event of a compromise, it can lead to a higher exposure. To arrive at a balance between the security and usability aspects, Refresh Tokens were introduced. Hence if access to the API is needed for more than the lifetime of a single access token, a Refresh Token can be used. Refresh tokens are tokens used by client to obtain new Access Token without having to involve the Resource Owner. In most implementations Access Tokens cannot be revoked (hence the short life) but the Refresh Tokens can be revoked. Refresh Tokens tend to have a longer lifetime than Access Token. Similar to the Access Token, the user would need to perform the authentication process again when the Refresh Token expires. Hence it is a good practice from a Security perspective to set an appropriate expiry time for the Refresh Token. When an Access token expires, the application can provide the Refresh Token to the application server and recieve another set of fresh Access token and Refresh Token to use the next time. This provides the option to implement any changes in the Access Token policy (eg: Altering its lifetime or Scope) transparent to the application. Brilliant.. How about the same usage on mobile devices etc ?? In the case that our aggregation service is an app on your mobile phone, then a browser window would pop-up for the Resource Owner to provide the Grant (User Consent). The OAuth token would be stored in the mobile phone to prevent the need for the user to perform the granting every time the app is opened. Also, it can eliminate the need for storing passwords on the mobile phone. In the event that the mobile phone is stolen, user could simply revoke permission for that app on the mobile without affecting other means of access. I think i’ve touched upon most of the important aspects of OAuth 2.0 and covered the "Authorisation Code" access pattern (which is by far the most common and also the most secure) in detail. OAuth 2.0 also supports other types of access patterns which are also called "Grant Types" (eg: Implicit Grant, Resource owner credential, Client credential etc.) which have not been covered in this post for the sake of brevity. That is for a different day. Further details on OAuth 2.0 specification can be found here . #KillPassword

In the first part of this post we saw why using password is not secure in the current climate and how you could add additional factors to make it more secure. In this post we will continue on the the path to getting closer to the " Password Nirvana ".. The quest towards eliminating the use of passwords from our digital life... Can we do anything about eliminating the "password" element in Authentication? A recent survey of users has found that a third of people now admit to having grown angry after struggling to remember log-in details. Users in the survey say " forgetting passwords to an account they need immediate access to is more annoying than misplacing their keys, having a cellphone battery die, or receiving spam email. " Hence it would be ideal if we could implement an authentication system where password is not used as an authenticating factor at all as passwords have one of the least level of assurance.There are current concerns / barriers though in moving to that state; like cost, privacy concerns, maturity of alternate technologies etc. For an authentication factor to de-throne password from its status as the default primary authentication factor, firstly it should at the minimal not be forgettable , social-engineerable or phish-able. The industry has started to respond in addressing these requirements with development of alternate solutions. One of the front runner in this is the Fast Identity Online (FIDO) alliance. The FIDO alliance is a cross-industry consortium and have member companies including some heavy weights like Google, Microsoft, Intel, Samsung, Lenovo, Alibaba Group, PayPal, NTT Docomo, American Express, Bank of America, Visa and MasterCard backing it. It seeks to eliminate the dependency on password as authentication means. FIDO recently announced government membership program and have enrolled two government bodies - Office of Cabinet (UK) & NSTIC/NIST (US). FIDO alliance has proposed two open specifications - 1. Universal Second Factor(U2F) augment a first factor (eg: usually password but is not mandated to be so) with any token that is compliant with U2F standard 2. Unified Authentication Framework(UAF) that aims at replacing passwords completely. This does this by having a de-coupled user verification happening locally on the device using a component called FIDO Authenticator and authentication with the service provider using Public Key cryptography. With the advent of newer Smart phones / Tablets / Laptops (eg: Iphone 6, Samsung Galaxy S6/Note 5, Nexus 5X/6P, Lenovo laptops etc) built-in with features to obtain biometric factors like Fingerprints, Face-recognition or Voice-print etc; biometric factors could be used in lieu of password for authentication. This can significantly reduce the Total Cost of Ownership (TCO) as the mode to provide the authentication is already built in on the user device. For the user, this is more convenient than remembering a password. A win-win situation. Storing my biometrics on a remote server? No way.. There is this lingering question when using biometric authentication regarding the privacy impact of storing biometric information on a centralised remote location. With FIDO's UAF based authentication, even if we were to use biometric based authentication using our smartphone or laptops with fingerprint scanner, the biometric information never leaves the device. The biometric pattern based on the user's biometric information and public / private keys generated specific to the combination of the user+device +service are stored securely within the device. The public key is sent securely to the service provider as part of registration and is used during the authentication process to validate and provide the authentication response to the service provider securely (signed using the private key). As illustrated above, there is a clear separation of user verification and the FIDO Authentication with the service provider. This means that the user can use any authenticator that the device would be able to support as long as it is compliant with the service provider's policy on acceptable authenticators. You can probably call this " BYOAuth ". So, for the same service provider, one user might use the authenticator that does fingerprint based verification while another user might be using another authenticator that does NFC enabled Yubikey (like Yubikey Neo). This also makes easy to future-proof against any new form of verification methods. Hmm..Interesting, has it seen the sun or is it still on papers and prototypes? Not at all.. Its very much live and kicking.. FIDO's UAF based authentication is gaining traction (seem more so on the consumer front) albeit slowly. Paypal ( https://www.paypal-pages.com/samsunggalaxys5/us/index.html ) and AliPay both support using FIDO's UAF based authentication. NTT-Docomo's OpenID (DocomoID) supports UAF based authentication ( http://www.nfcworld.com/2015/05/26/335459/ntt-docomo-rolls-out-fido-biometrics-platform-in-japan/ ). For more information on the FIDO’s specifications, please visit https://fidoalliance.org/specifications/overview/ Apart from the FIDO UAF compliant authentication, there are other biometric authentication solutions that also seeks to eliminate passwords like the Fujitsu's IRIS based authentication ( http://www.fujitsu.com/global/about/resources/news/press-releases/2015/0302-03.html ) and behavioural based authentication like Lockheed Martin's gesture based authentication solution developed for NSA called Mandrake ( http://www.engadget.com/2015/05/26/nsa-tests-finger-swipe-identification/ ). In closing.. Replacing passwords with stronger authentication factors like biometrics is not a silver bullet, but it does provide a higher level of assurance and significantly reduces the possibility of a breach. For High risk / Sensitive transactions FIDO based authentication augmented by contextual authentication (using geolocation, device fingerprint, user profiling etc) could be employed to achieve higher ability to prevent fraud. On the original question of "Can the password be de-Throned?", we are not there yet but are much closer to it and moving towards with a steady pace.. #KillPasswords #FIDO