Typically, this kind of method is used to achieve 'What you see is what you sign', a principle that is often adopted by banks in Europe to thwart men-in-the-browser attacks.
The technique itself shows its advantages when using it for online money transactions. An example makes this clearer.
Imagine the attacker has full control over the browser, and the bank has adopted two-factor authorization, both for authenticating logins and for authenticating transactions. The victim wishes to transfer €500 to bank account 556611, and is ready to authenticate the transaction with his/her OTP generator. However, the attacker has full control of the browser, and has modified the transaction to be €50000 that will be wired to bank account 447700. The victim does not see this, as the attacker has modified the browser in such a way that it still shows the original transaction. Now, the victim enters the OTP (and possibly other credentials, that does not matter for this attack). The transaction is authorized, and the victim has no way of knowing whether he/she authorized the original transaction, or a modified one. The user did not sign what he/she was seeing.
At first sight, it might be just as well be a solution to include the transaction information in the generation of the OTP. However, as the attacker may send the wrong transaction information to the server, we still cannot trust the OTP that is legitimally calculated on the server.
The ONLY way to solve the above problem is to make sure that the victim has some way of verifying the amount and bank account number to which the transfer is being made. This verification needs to happen out of band, as we assume that the victim's PC is fully compromised (including the browser). This is where we get to 'What you see is what you sign': in the above example, the victim did not sign what he/she saw. This is a huge problem for money transactions.
Therefore, we need some clever way through which banking customers can confirm the payment details, without impacting user friendliness too much. The simple approach would be this:
- Let the customer enter payment details (amount, account, ...)
- Calculate an OTP based on the amount/account details (and also based on a challenge, which is the standard OTP-generation method for some banks in Europe)
- The customer activates an OTP generator using a PIN-code (in your case: using his/her fingerprint)
- Make the customer type all the above information in the OTP generator (this is: a challenge, amount, account details, and possibly other information)
- The generator displays a response, and the transaction is authorized
As you see, the above method is very cumbersome for users: they have to enter a lot of information in the OTP generator (which typically is an offline device, or may be a smartphone nowadays). To make this process much more user-friendly, this information may be included in an image, such as:
- A QR code
- A 'changing' barcode, such as displayed in the image at the end of this post
- A Cronto image
The process is simple. The user reads one of the above codes using the reader they received from the bank (or their smartphone). Instead of typing in the required information (challenge/amount/account), the reader reads this information from the image, and just presents it to the user, who then has to confirm this. The reader will for example ask 'Do you want to transfer €500?'. The response that is generated on the reader will then be based on this €500. Please note that the attacker has perfectly the possibility to alter the €500 to €50000, however the customer will (hopefully) NEVER press 'OK' when the reader asks whether or not the customer wishes to authorize this transaction. This is WYSIWYS at its best.
Answer
In your example, the reader must be activated first with a fingerprint. This is a newer method compared to activating the reader with a PIN, but has no impact on the rest of the WYSIWYS method.
Now, to actually answer your question. I do not know the specifics of the Bloomberg system, where the 'image' may just as well only contain the challenge to speed up the challenge-response login (the user does not have to type in a challenge on the reader). However, in most implementations, this kind of flow will be used to achieve WYSIWYS. For a login form, this typically does NOT add any security compared to two-factor authentication (as there is no other information that can be altered apart from the username/challenge). However, it is easier for users to have the same authentication flow for their login as well as transaction signing.
Appendix:
The optical barcode which I talked about in this answer (please not that this barcode continuously changes, as a static barcode would not be able to hold all required information). To read this barcode, a special reader is required, which needs a couple of seconds to read the changing barcode.
