Introducing Authy Push

From day one, Gemini has required 2FA using the Authy service for all accounts. Starting on March 13, 2018 we will be enabling a new Authy feature for added security while performing sensitive transactions: Authy push notifications.

Sessions vs transactions

Most consumer-grade authentication systems operate at the level of sessions. Users provide their credentials — which may involve multiple factors such as a password in conjunction with a short-lived, one-time passcode. This initial step creates an authenticated “session” lasting for a fixed duration (e.g., one hour). During this time, users are allowed to browse around the site and use various features. After the clock runs out, the session reverts to an unauthenticated state, requiring users to prove their identity once again.

One shortcoming of this model is that after initial authentication, any number of actions are allowed within the authenticated session. Transactional authentication improves on that model by tying the authentication to a unique action. “Unique” being the operative keyword here: asking users to type their password one more time or even enter another 2FA code is not sufficient. Without knowing what will happen after completing those steps, users are effectively approving some action which may not be what they had in mind.

Phishing attacks and malware can exploit that disconnect. For example, in a phishing attack a user will be mistakenly interacting with a fraudulent copy of the service operated by an attacker. This fake website can:

• Collect the password
• Collect a 2FA code

At this point, the attacker can turn around and use those credentials (quickly, before the 2FA code expires) to login to the legitimate website to impersonate the legitimate customer.

Requiring additional 2FA codes to perform sensitive actions such as authorizing a payment is not sufficient to mitigate this. The phishing site can adjust its tactics, feigning an error after collecting the initial 2FA — even though it is valid and used by attacker to login — and trick the user into giving away a second 2FA code to use for authorizing the subsequent action.

While other authentication systems such as U2F are not susceptible to phishing, they have similar limitations against malware. If the device a customer is using to access their favorite website has been compromised by malware, that malicious software can silently alter user actions. For example, it can change the Bitcoin address submitted to a web page in order to funnel payments to a different destination. Not even the proof-of-presence required in U2F by pressing a button helps. While that event cannot be fabricated by malware running on the device — the token itself registers the contact — the user is more than willing to press the button in service of the attacker. After all, they are under the impression that this action will result in some intended, legitimate behavior. In reality it is authorizing some action that can be manipulated under the covers by malware. (Not to mention, malware can wait until authentication is complete to take advantage of the resulting session, complete with all required cookies and even TLS channel binding.)

Adding context

The root cause of these problems is lack of context about the action being approved: the user believes that providing a 2FA code or pressing a button will lead to one outcome while the adversary has carefully altered the setup to trigger something else entirely. What is required is an _out-of-band channel_to verify the intended transaction, independent of the original device where it is initiated.

This is far from a new idea; there are many precedents for such verification in high-value scenarios, typically involving special purpose hardware:

• Some cryptographic hardware tokens feature a trusted display and user-interface with physical buttons to confirm transactions. That display is driven by the token and cannot be manipulated by the machine the token is attached to.
• Several Bitcoin hardware wallets have a display for confirming the destination addresses on transactions. Even if local malware running on the PC sends a different Bitcoin transaction for signing — as malware in the wild was discovered to be doing by manipulating the clipboard — the user has an opportunity to detect this substitution because the display cannot be manipulated.
• A more mainstream example can be found in NFC payments using a smart-phone. While standard credit card payments (even with chip cards) involve blindly trusting the point-of-sale terminal to charge the expected amount, mobile wallets can first display the amount requested and obtain confirmation from the consumer before proceeding with the payment.

Introducing Authy Push Notifications

Luckily esoteric hardware is not required to get the benefits of out-of-band authentication. With the right application installed, the ubiquitous smart-phone can function as the independent verification channel. Authy, used by Gemini, is an example of such an app. When customers attempt to withdraw cryptocurrency from their Gemini account, they will receive an approval request on their mobile Authy app containing transaction details:

Unless the transaction is confirmed by clicking on the “Approve” button, no funds will be sent. Note this exchange is taking place on a completely different channel (via the Authy mobile app) than the browser session used to access Gemini. In fact, it is typically taking place on a different _device_altogether: a customer may login to the exchange on their laptop while receiving the notification on their phone. This out-of-band channel is protected from risks associated with the primary device. For example, even if a customer accidentally provides their password and 2FA code to a phishing site, that site has no way to compel that person to approve the notification requesting approval for funds transfer. More importantly, there is no way to obscure or misrepresent the intent of the transaction. Crucial details including amount and destination address will be included in the UI, giving the legitimate customer an opportunity to recognize it for what it is: an attempted theft. Similarly even malware running on the primary device can not in general cause the push notification prompt to be approved outside of user consent. (It would also require compromise of the mobile device to forge that approval.)

Roll-out plans

At this time, for customers who are already using the Authy mobile app, Gemini will require push notification approval for all crypto-currency withdrawals — no action is required to opt-in to the additional level of security. Gemini strongly recommends all customers to use the Authy mobile app and cautions against relying on SMS for two-factor authentication.

If you have any questions, please reach out to our support team at support@gemini.com.

Onward and Upward,

Gemini Security Team