What advantage does the Bloomberg authentication system have over traditional 2 factor?

Question

Bloomberg clients have an interesting way to authenticate to the server. This seems involve some of the following:

1. Logging into a secure website, that displays a flashing square
2. Swiping your finger against a portable fingerprint reader
3. Placing the reader against the screen so it can read the flashes
4. The fingerprint reader displays a code
5. The code is then entered into the website.

I have never seen this authentication before and there is probably a lot more to what is present than what I observed.

What are the details of this authentication system, and what advantages does this provide over traditional RSA 2 factor authentication?

Are all these steps needed? It seems to hamper usability, and requires a lot more end user training than other systems I've seen.

Edit - Additional information

Promotional information, and an End user manual

Answer 1

Disclaimer: I've never used these terminals before and the only knowledge I have of the system you're describing is the description itself.

How the authentication works

So here's what you're actually doing --

1. You log in to the website.
2. You provide biometric data to a fingerprint reader
3. The website provides some "challenge" value for the fingerprint reader
4. The fingerprint reader combines the biometric data it received with the challenge data provided by the website, and outputs a result specific to that particular combination of both your fingerprint and the one-time challenge
5. The website then reads that authentication code and verifies that the registered user is the one in front of the terminal

What is being protected

This technology is reasonably effective, but it doesn't offer the protection you might think it does. It's not there to protect you, it's there to protect Bloomberg.

Interestingly, this technology won't protect you from phishing or from fraud or from MITM attacks. But it protects Bloomberg from piracy.

Bloomberg terminals are notoriously expensive, and typically one terminal would be very useful not just for the person paying for it, but usually the whole office could benefit from access. So there's a certain incentive to "share" your subscription with your immediate coworkers. Bloomberg doesn't want this.

The fingerprint reader exists to ensure that nobody can use your login but you. Two-factor tokens can be shared; fingers can't. But fingerprint readers require hardware access, which a website won't have. So the fingerprint reader is designed to output a code you simply type into the website. You (Bloomberg) don't want to output the same code every time; so you need to mix it up with something.

You could use some independently-varying data like the current time (same as TOTP systems like Google Authenticator do, for example), but you (Bloomberg) want to ensure that the key isn't being generated by someone down the hall. You want to make sure that the paying user is sitting right there in that seat looking at that screen. So you send the fingerprint reader a unique challenge code for it to respond to.

Note that only the user is being authenticated; not the server, and not the connection. So in this scheme, a man-in-the-middle attack works just fine. Ideally the server could be authenticated with TLS, but since the TLS-verification artifacts aren't part of the authentication scheme, the authentication does not depend at all on that verification.

So this mechanism isn't nearly as helpful when your protection is important; it's no better than an OTP-based 2-step auth system, such as you'd get with SMS, RSA SecurID, or Google Authenticator -- but it's way more expensive. If it's your protection that is important, then currently you can't do better than the Yubico U2F key created by Google, but usable on any site that accepts it (including now Github!).

Answer 2

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.

Answer 3

To draw a parallel, consider how some sites focus on changes to settings of a profile by asking you to reenter a password. This is to prevent cases where your authentication cookie token has been copied and used to access the account. In the instances where the browser itself has been compromised or in the case that the entire transaction between client and server is in the clear, the action that would minimise the damage would not be a re-establishment of the encrypted channels, but rather to tie in each transaction with an established authenticated endpoint which is why you have to provide a secret of some sort, through use of a password, out of band communication,etc. , that is tied in with that single transaction. Usually this is not done with all actions, since checking your account balance is not as fraught as transferring cash out from an account.

Fingerprint modules only work as long as the reading machine itself is safe from tampering. Barring which, it is as transparent as typing in a password. The only good thing that fingerprint modules on phones do is to hinder prying eyes from accessing your device by mounting cameras behind you to spot your swiping patterns.

I agree with the observation that the terminals have a two way function, weighing heavily in favour of bloomberg, to ensure that only one user exists between it and the terminal.