Noting Paper 258 - Independent Information Security Review

[Technical-DSB]

Update 16/12/2022:

Decision Record

The Data Standards Chair approved this decision on 16th December 2022. The decision record is attached: Decision 258 - Response to Independent Security Health Check - final.pdf

---

Update 01/12/2022: This noting paper has been closed with a decision by the Chair in response to the community feedback and the report's recommendations to be published in the near future.

07/07/2022:
The DSB, as an arm of Treasury, has engaged an external specialist assurer to provide an independent assessment of how the Information Security Profile (Profile) of the Data Standards for the Consumer Data Right (CDR) is tracking against relevant security benchmarks. Similar assessments have been completed in the past (the last one is here) and more will be undertaken in the future to help ensure the CDS remain fit for purpose. As some time has passed since the last assessment the current work has been approached in a staged manner and the attached report should be read as a first pass intended, in part, to identify areas that will require further and more detailed attention.

The DSB considers it timely to undertake this assessment now as we look ahead to an expanded CDR in line with the Government Response to the Final Report of the Inquiry into Future Directions for the Consumer Data Right, particularly with regard to action and payment initiation. Given the already substantial installed base of CDR implementations we are interested in finding ways to stage necessary changes to avoid the risks inherent in attempting wholesale change all at once.

The attached report is as provided by the external specialist assurer and should not be read as representing the views of the DSB or the Data Standards Chair. We will consider appropriate responses to the recommendations contained in the report over coming weeks. In the meantime we invite and welcome feedback on this report from the wider CDR community, ideally publicly on this thread but also privately via contact@consumerdatastandards.gov.au.

The report is attached below:
Independent Health Check Final Report.pdf

[RobHale-Truelayer]

It is great that this document has been created and shared for public comment. As called out in Section 9.1, this open process continues to add value. Consideration should be given to mirroring this approach by other agencies. While it is a technical document, the comments in Section 8 are insightful. They would be readily understood by a broader audience and should probably be shared more widely.

High level thoughts and comments

1. Overall, CDR is incredibly complex. Wherever possible, an umbrella principle such as “keep things simple, easy to communicate and easy to understand” might be worth considering. This could also apply to regime security. For example, while further OTP/2FA optionality may well offer flexibility and enhanced security for some, we find ourselves in trade-off territory with an elevated burden of comprehension for rule makers, enforcement teams, participants and consumers.
2. The thinking behind getting consumers to check URLs, imposing lengthy OTPs and providing a Data Holder “kill switch” is understood, yet it feels like we are patching rather than addressing a fundamental flaw. Consumers already face significant cognitive load in unfamiliar territory with CDR, so the intended value of offering additional or extended security features may not be realised. We saw an example of this with the well-intentioned original joint account consent flows. They were just impractical. The consumers of CDR are people who are primarily motivated by an outcome - a product or service - not the process through which it is delivered. By the same token it seems CDR will be safer and better for everyone if we are able to productise security, baking it in and not relying on consumers to be aware of risks and to take action to protect themselves.
3. In order to become dominant and to unseat screen scraping as the de facto method of data sharing, CDR needs to be superior from the consumer’s perspective. There is no competitive benefit in a slower, more cumbersome process. Despite us all recognising the security benefits, we’ve seen this play out in the market. Pure play CDR providers are currently few and far between. A streamlined consent process would be a powerful step in the right direction. The report identifies that the current redirect-with-OTP arrangement is lacking in security. Given that this is also a high point of friction for consumers, it would appear to have little going for it. Rather than spending effort reinforcing and shoring up the current model, would it be better to expedite a more contemporary (and more secure) replacement that also supports higher data sharing conversion? The UK flows outlined in 4.3 could be a good starting point here.
4. The report rightly notes significant variability in data holder authentication implementations. This situation is unhelpful if we value a consistent UX as a contributor to overall regime trust. Perhaps some form of DH rating could be displayed for consumers to see. Similar to browser trust symbols used to highlight insecure websites, this might incentivise DHs (and ADRs) to comply with more secure data sharing practices.
5. Finally, a thought on the network of participants and the collective contribution this network could make to an enhanced overall security posture. As a means with which to combat larger-scale fraud and attacks, could CDR include inbuilt notification features? Could other participants be made aware of repeated failed authentication attempts at a DH, high numbers of sessions from a single source, enumeration attacks, or other behaviours considered outside of ‘normal’ bounds?

[jogu]

In section 7.2 ([Refresh] 'Token Rotation'), the report says:

This view is reflected in the draft OAuth 2.0 security recommendations, which makes explicit the requirement to sender constrain both access and refresh tokens [8, 4.13.2].

However the only relevant clause I can see in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.13.2 only applies to public clients, so is not applicable to CDR (where only confidential clients are permitted):

3. In order to become dominant and to unseat screen scraping as the de facto method of data sharing, CDR needs to be superior from the consumer’s perspective. There is no competitive benefit in a slower, more cumbersome process. Despite us all recognising the security benefits, we’ve seen this play out in the market. Pure play CDR providers are currently few and far between. A streamlined consent process would be a powerful step in the right direction. The report identifies that the current redirect-with-OTP arrangement is lacking in security. Given that this is also a high point of friction for consumers, it would appear to have little going for it. Rather than spending effort reinforcing and shoring up the current model, would it be better to expedite a more contemporary (and more secure) replacement that also supports higher data sharing conversion? The UK flows outlined in 4.3 could be a good starting point here.

I think this is a great point. I know a lot of effort was put towards this model in 2019 with a big push by some stakeholders away from utilising existing authentication of DHs. I think it is good to challenge the model again now with the benefit of real-world experience. Let's not fall victim to the sunk-cost fallacy cognitive bias, and make sure we look at it objectively.

4. The report rightly notes significant variability in data holder authentication implementations. This situation is unhelpful if we value a consistent UX as a contributor to overall regime trust. Perhaps some form of DH rating could be displayed for consumers to see. Similar to browser trust symbols used to highlight insecure websites, this might incentivise DHs (and ADRs) to comply with more secure data sharing practices.

I like the concept of a trust rating per DH. And per ADR. This would provide a win-win for consumers and the ecosystem.

[DSB-RT]

They would be readily understood by a broader audience and should probably be shared more widely.

Thanks @RobHale-Truelayer.

Would you care to elaborate on which audiences, and what channels?

Best,
RT

[RobHale-Truelayer]

Hi @DSB-Rob - I was really just flagging a general observation...

I love the fact that the DSB is transparent and open using GitHub to engage on CDR issues and standards - this noting paper is a great example of that 👏

Yet, in my view, GitHub can be intimidating to many CDR participants due to the largely technical content that appears here and the highly specialised nature of related dialogue. I suspect that many non-technical people would find the content in section 8 and 9 useful, however they may never stumble across it because it appears here, buried deeply within an intimidatingly titled report. We may therefore miss out on receiving their input and understanding their views.

I'm clearly generalising in my simplistic categorisation of tech / non-tech people but I did mentioned this same matter on a FDATA call today and others seemed to subscribe to the same view so I don't think I'm completely bonkers 🤪

The solution? Tricky in this instance but potentially just adding it as an agenda item on the Thursday Implementation Call might suffice. Point people to pages 39+ and suggest a read. I'm happy to say something if JJ wants to throw to me for comment!

[chrisculnane]

In section 7.2 ([Refresh] 'Token Rotation'), the report says:

This view is reflected in the draft OAuth 2.0 security recommendations, which makes explicit the requirement to sender constrain both access and refresh tokens [8, 4.13.2].

However the only relevant clause I can see in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.13.2 only applies to public clients, so is not applicable to CDR (where only confidential clients are permitted):

@jogu just to clarify that reference is in 7.1 Sender Constrained Tokens and is provided as an example of how other standards handle sender constraints consistently between access and refresh tokens. The issue at hand is that FAPI Security Profile 1.0 - Part 2: Advanced changed to remove the explicit sender constraint requirement on refresh tokens. The argument appears to be that since OAuth requires client authentication for confidential clients, as well as a check that a refresh token was issued to that client, that it is equivalent.

However, that is not strictly equivalent to sender constraining via MTLS. As a result, the security of the access token reduces to that of the refresh token client check, since the refresh token can be used to generate a new access token. It is more desirable to have consistency between access and refresh token constraints.

[jogu]

just to clarify that reference is in 7.1 Sender Constrained Tokens and is provided as an example of how other standards handle sender constraints consistently between access and refresh tokens.

Yes, apologies, I did quote the incorrect session number / heading.

I would still say it's somewhat misleading to quote text that talks about requirements for public clients, and to say It reflects the view that confidential clients should use sender constrained access tokens using a mechanism other than client authentication.

The issue at hand is that FAPI Security Profile 1.0 - Part 2: Advanced changed to remove the explicit sender constraint requirement on refresh tokens.

This is not really true, albeit the situation is complicated - as per https://bitbucket.org/openid/fapi/issues/202/authorization-code-and-refresh-token-must :

<...> I suggest we remove the requirement that the refresh token and authorization code are holder of key bound.

The requirement that the client has to use asymmetric crypto to authenticate at the token endpoint has the same effect - and in practice is what I believe that people have interpreted the spec to mean.

Most people consider that requiring OAuth client authentication, with the additional constraint as per FAPI of private_key_jwt or MTLS client authentication, requires that the client proves possession of the key at the token endpoint when using a refresh token - meeting the requirements of sender constraining. It is, for example, as strong as the default mode defined in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop for sender constraining access tokens. So removing the text saying that refresh tokens had to be sender constrained had no practical effect, no implementations nor conformance tests were changed as a result of that change. The conformance tests continue to check that refresh tokens are bound to the client as required by RFC6749.

For confidential clients, there's not actually a standards defined method for sender constraining a refresh token for a confidential client, other than (as FAPI1 part 2 does) using OAuth client authentication. The 'simple' approach of binding it as is done for public clients, using the method in https://datatracker.ietf.org/doc/html/rfc8705#section-7.2 results in the client losing all consents if it rotates it's keys, as it is no longer able to use the refresh tokens that were bound to the old key. (So for confidential clients, FAPI1 has never defined any interoperable way to practically sender constrain refresh tokens, other than OAuth client authentication.)

[DSB-RT]

Hi @DSB-Rob - I was really just flagging a general observation...

I love the fact that the DSB is transparent and open using GitHub to engage on CDR issues and standards - this noting paper is a great example of that 👏

Yet, in my view, GitHub can be intimidating to many CDR participants due to the largely technical content that appears here and the highly specialised nature of related dialogue. I suspect that many non-technical people would find the content in section 8 and 9 useful, however they may never stumble across it because it appears here, buried deeply within an intimidatingly titled report. We may therefore miss out on receiving their input and understanding their views.

I'm clearly generalising in my simplistic categorisation of tech / non-tech people but I did mentioned this same matter on a FDATA call today and others seemed to subscribe to the same view so I don't think I'm completely bonkers 🤪

The solution? Tricky in this instance but potentially just adding it as an agenda item on the Thursday Implementation Call might suffice. Point people to pages 39+ and suggest a read. I'm happy to say something if JJ wants to throw to me for comment!

Thank you Rob.

There were security items on the agenda for last week's imp call, but I was unable to attend. Did this meeting address your needs? Or would you like to suggest we post this report to our website as well?

Best,
RT

[DSB-RT]

just to clarify that reference is in 7.1 Sender Constrained Tokens and is provided as an example of how other standards handle sender constraints consistently between access and refresh tokens.

Yes, apologies, I did quote the incorrect session number / heading.

I would still say it's somewhat misleading to quote text that talks about requirements for public clients, and to say It reflects the view that confidential clients should use sender constrained access tokens using a mechanism other than client authentication.

The issue at hand is that FAPI Security Profile 1.0 - Part 2: Advanced changed to remove the explicit sender constraint requirement on refresh tokens.

This is not really true, albeit the situation is complicated - as per https://bitbucket.org/openid/fapi/issues/202/authorization-code-and-refresh-token-must :

<...> I suggest we remove the requirement that the refresh token and authorization code are holder of key bound.
The requirement that the client has to use asymmetric crypto to authenticate at the token endpoint has the same effect - and in practice is what I believe that people have interpreted the spec to mean.

Most people consider that requiring OAuth client authentication, with the additional constraint as per FAPI of private_key_jwt or MTLS client authentication, requires that the client proves possession of the key at the token endpoint when using a refresh token - meeting the requirements of sender constraining. It is, for example, as strong as the default mode defined in https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop for sender constraining access tokens. So removing the text saying that refresh tokens had to be sender constrained had no practical effect, no implementations nor conformance tests were changed as a result of that change. The conformance tests continue to check that refresh tokens are bound to the client as required by RFC6749.

For confidential clients, there's not actually a standards defined method for sender constraining a refresh token for a confidential client, other than (as FAPI1 part 2 does) using OAuth client authentication. The 'simple' approach of binding it as is done for public clients, using the method in https://datatracker.ietf.org/doc/html/rfc8705#section-7.2 results in the client losing all consents if it rotates it's keys, as it is no longer able to use the refresh tokens that were bound to the old key. (So for confidential clients, FAPI1 has never defined any interoperable way to practically sender constrain refresh tokens, other than OAuth client authentication.)

For clarity, Chris Culnane was one of the authors of this independent health check.

Best,
RT

[RobHale-Truelayer]

Hi @DSB-RT

There were security items on the agenda for last week's imp call, but I was unable to attend. Did this meeting address your needs? Or would you like to suggest we post this report to our website as well?

Thanks for checking back. I only managed to attend for part of the call so am not sure if there was any engagement. However I checked the Agenda just now and see it has been flagged in the last 2 calls - so it's out there and hopefully getting some broader readership. I think that should suffice 🙏

[PratibhaOrigin]

Origin welcomes the reviews analysis of the CDR authentication flow using OTP and its shortcomings. Whilst Origin understands that this is a known issue that has been discussed during the Banking implementation, Origin hopes this paper will evoke renewed focus on this issue, with the gravitas it requires. The OTP authentication method is very vulnerable to spear phishing attacks. Scammers can obtain the OTP, under false pretences, from a sizeable number of Energy customers, particularly those that are not tech savvy or digitally enabled. This OTP may be used to go through the CDR authentication flow, resulting in access to the customers information through a legitimate ADR.

Origin Energy believes that Energy (and Utilities) industry is more susceptible to this issue, as consumers are used to switching energy retailers over the phone as compared to switching their financial institutions. Origin hopes that this issue is mitigated, including if any updates/amendments to the CDR Standards are required, to make it more difficult for the scammers to access customer accounts, if not fully deter them. This issue has been discussed with the DSB technical team and several alternatives were discussed however there is no appetite to update the standards before the 15th of November 2022 go-live despite the live risk. As such, based on our discussions, Origin would like to formally lodge it as a CDR risk so that industry can work together in remediating it.

Issue description:
Historically, Origin has observed the following scam pattern:
• Customers receive calls purporting to be from another major retailer promising customers cheaper rates. This occurs during rate increase periods.
• The scammers let the customer know that they needed to verify the customers identity using OTP.
• The scammers initiate a password reset flow, which requires email address and OTP. This sends the OTP to the customer.
• Customer provides the OTP over the phone thinking they were verifying their identity.
• Scammers reset customers password and take over the customer’s account, downloading bills and obtaining other PII.

Whilst Origin has put in place controls to prevent and detect such activity, the CDR authentication flow would be an easier vector for the scammers to use. Instead of attempting the scam through our systems, the scammers will move to an ADR instead, achieving the same objective.

Origin is concerned that, due to the prescribed auth standards, the CDR weakens the DHs controls against this type of attack. Overall, there seem to be incongruency with the controls placed to protect vulnerable consumer (e.g., Domestic/Family Violence) as this scam is a straightforward way for family violence victim’s information to be obtained despite any controls implemented at the data holder. There is a concern that while numbers are low, its criticality is quite high and has a potential to cause damage to CDR brand and result is grave consequences for the DH and more importantly, the customer.
With the current CDR authentication flow, the DH is limited to implementing detective controls such as device fingerprinting. However, in several circumstances, these controls are ‘after the fact’. The damage is already done. Preventative controls, such as the use of magic links (that are not easily shareable), would go a long way in preventing these scams. However, the DHs are bound by the prescribed OTP flow.

If this risk is known, understood and has been accepted for CDR, a few questions would need attention.

1. What is the process to follow should a data holder observe targeted scam campaign against its customers?
2. What are ADRs obligations to mitigate this kind of attack?
3. Is the CDR lowering the security posture of Data Holders that have a more stringent authentication flow than that which is prescribed by identifier + OTP?
4. If this is accepted and understood, what is the threshold of occurrences beyond which the risk warrants a review?