CIBA: Binding Messages

[Dave Tonge]

I'd welcome input from the working group on the use of binding messages for payments.

The relevant wording in the FAPI CIBA draft profile is:

NOTE: The binding message is required to protect the user by binding the session on the consumption device with the session on the authentication device. An example use case is when a user is paying at POS terminal. The user will enter their user identifier to start the CIBA flow, the terminal will then display a code, the user will receive a notification on their phone (the authentication device) to ask them to authenticate and authorise the transaction, as part of the authorisation process the user will be shown a code and will be asked to check that it is the same as the one shown on the terminal.

and

7.3 Reliance on user to confirm binding messages

In a payments scenario it is possible for a fraudster to start a CIBA flow at the same time as a genuine flow, but using the genuine user’s identifier. If the amount and the client are the same then the only way to ensure that a user is authorising the correct transaction is for the user to compare the binding messages. If this risk is deemed unacceptable then implementers should consider alternative mechanisms to verify binding messages.

[Axel Nennker]

The user now receives two requests on their authentication device, right? Which hopefully have different binding_messages.

CIBA tries to stay away from defining binding_message content.

[Dave Tonge]

Yes - the scenario with the fraudster should result in the user receiving two requests on their authentication device - which must be different

[Dave Tonge]

we discussed adding in text to suggest that the user could enter the binding message as an extra precaution.

we also discussed adding a security consideration that calls out the fact that the bank misses out on a lot of information that it can currently collect in redirect methods

[Axel Nennker]

presenting the binding_message to the user enables the user to detect whether the current authentication is the one they triggered. So, the user should then not enter their credentials but just cancel the authentication request. Entering back the binding_message gives assurance to the AZ that the authentication was the expected one, right? I think this concept is not extensively discussed yet and it changes the semantic of the flow. So yes entering the binding_message probably is good for security but I would like to have input from (OAuth2) security experts on this.

[Dave Tonge]

I think you are right, I plan to draw up some diagrams of the flow to better illustrate it to those less familiar with the spec.

[Nat Sakimura]

I have not evaluated it in detail, but there seems to be some similarity with OAuth Device Flow so it may be a good idea to look into it. In addition, I have done some work on the ATM use cases. In the use case, a binding message will be transmitted to the authentication device aka smartphone through 1) QR Code OR 2) NFC. In the case of QR code, the app MUST scan the QR code and signs the QR code + device GPS data with the instance-specific key and send it to the back-end. The GPS data will be compared to the location of the ATM. So, unless the attacker is able to display his QR code on the ATM, which is not possible by assumption, OR trick the user to scan the QR code for him while faking the user's smartphone's geo-location, the attack would fail.

[Dave Tonge]

So we have a separate issue about passing device location data: https://bitbucket.org/openid/fapi/issues/146/ciba-fraud-indicator-standards-and-signed

I think the intent of the text here is fine, but I suggest we change 7.3 to read as follows:

Depending on the hint used to identify the user and 
the Client's user authentication processes, it may be 
possible for a fraudster to start a malicious CIBA flow at the same 
time as a genuine flow, with both flows using the genuine user’s 
identifier. If the scope of access requested is similar 
then the only way to ensure that a user is authorizing the 
correct transaction is for the user to compare the binding 
messages on the Authenticatio and Consumption devices. 

If this risk is deemed unacceptable then implementers should 
either consider alternative mechanisms of verifying the binding 
message (e.g. conveying it to the Authentication device via a 
QR code), or use ephmeral user identifiers generated on the 
Authentication device.

[Joseph Heenan]

The seemed to be consensus on yesterdays call about Dave’s suggested wording - I’ll open a pull request to do this.

[Joseph Heenan]

Pull request has been opened here that uses Dave’s suggested wording: https://bitbucket.org/openid/fapi/pull-requests/121/ciba-expand-binding-message-security/diff

[Joseph Heenan]

CIBA: Expand binding message security considerations

Text as suggested by Dave Tonge.

closes #121

→ <<cset 200a7c560750>>