LastPass, Duo, Google “Push” for 2FA

Came back from Black Hat / Defcon all fired up about 2FA (“Two-Factor Authentication”).

I was particularly impressed when the Bloodhound developer used his YubiKey to access GitHub in front of all the hackers, er,  security people.

So decided to take a quick look at LastPass, Duo, as well as Google’s new Push 2FA. The result is this 3-part series.

Begin at the beginning

Disclaimer and all that jazz

This is a personal opinion based on a quick “hands-on” look at basic application function. No protocol analysis / Burp-ing, reversing or  “in-depth” whatever was done.

Things were looked at mostly from a SMB’s viewpoint (“small is beautiful”). However some comments (especially in the Duo section) have wider application.

Two-Factor Authentication (“2FA”)

Wikipedia defines 2FA as follows:

2FA is … a method of confirming a user's claimed identity by utilizing a combination of two different components.”

Typically 2FA combines:

• “Something I have”: e.g. my ATM bank card
• “Something I know”: e.g. The PIN to allow the transaction.

For computer applications, 2FA is often as follows:

• “Something I have”: A mobile phone typically running some 2FA application
• “Something I know”: The user logon ID / password to access the application.

2FA: The latest security “hotness”

What exactly is driving the recent interest in Password Managers in general, and “Two-Factor Authentication” in particular?

Advances in hacking technology have caused a major shift in the global threat model.

Consider the following:

• Passwords invented by users (even long ones) are typically easy to crack. Pwd hashes are posted on cracking forums and a bounty is offered. Bitcoin miners using modified “mining rigs” can crack most pwds within a few hours at most. In this way, they can make better profits than with straight mining.
• 
  
• Statistically, some users somewhere will use the same password (or some permutation thereof) on different sites.
• If one of the sites is the user’s main webmail account, then this access can be used to reset passwords and gain access to many of the user’s other accounts.
• 
  
• If one of the sites is the user’s corporate account, then the user’s company can be attacked. (See the following point).

• 
  
• Many corporations use Microsoft Active Directory for basic Authentication (“AuthN”) / Authorization (“AuthZ”). Once MS AD is compromised the attacker literally “owns” the company.  Typically this is relatively easy to do by using traversal combined with “Pass-the-Hash” / mimikatz attacks to  escalate privilege.
• 
  
• Once the attacker controls AD, password hashes can be dumped and the entire process repeated. Rinse. Repeat.

A two-pronged approach to help mitigate the above threats is:

• Encourage users to use a Password Manager to generate robust random passwords and then store them. These passwords are much more difficult to crack.
• Implement Two-Factor AuthN to help lock down access.

Push Technology

Two-factor authentication can be made much easier to use by combining 2FA with mobile “Push” technology.

“Push” technology (i.e. publish / subscribe model) has been around for a long time. For example, Smtp is essentially a Push protocol except for the last leg.

However when Push is combined with 2FA, the result becomes the “shiny new security hotness”.

Instead of typing those infuriating 6-digit codes generated by  Google Authenticator, RSA SecurID tokens and friends, the user simply authenticates by “pushing a button”. Neat. Clean. No mess. No fuss.

Ease of use means higher adoption rates by users. Everyone wins.

The two main “Push” technologies

In the mobile world, the two main Push messaging technologies are Google Cloud Messaging (“GCM”) and Apple Push Notification Service (“APNS”). For an overview, see this article.

• Apple’s APNS has a well-defined security architecture.
• Google’s legacy GCM’s security posture was more flexible (complex?). The resulting security was largely dependent on application implementation.
• However as Google continues to move into the “IAM” (“Identity Management”) field, Google is now emphasizing Firebase. The Firebase technology was acquired by Google in 2014. Firebase has a cloud-based messaging component. There is also a full-blown AuthN function with accompanying SDKs. Email password AuthN, federated OAuth AuthN supporting Google / Facebook / Twitter / GitHub, and RYO custom implementations are available.

Let’s take a look at some interesting applications

Long story short, this series looks at some interesting applications to help implement the mitigation described above:

• Three 2FA apps with mobile Push support: Google 2FA AuthN, LastPass, and Duo.
• LastPass Password Manager.

Use cases

For the typical SMB “small business” operation, there are two obvious use cases:

• Share passwords between a group of users working on a common project
• Make 2FA more “friendly” and easy to use - especially for non-technical users.

Of course, the technology has to be inexpensive. “Free” is best.

OK, enough introduction, let’s get started by looking at Google Push AuthN.

Google Mobile Push Authentication

Easy to implement, easy to use

Google’s new mobile Push AuthN is the greatest thing since sliced bread. It appears to provide robust authentication to Google applications, yet is easy to implement and use.

(At least for Android users - haven’t had a chance to test it on IOS yet.)

For a good introduction, take a look at this ars Technica article. There is a clear explanation including a slideshow to demonstrate configuration / use.

Setup only takes a minute. From then on, click away to authenticate Google account logins. Nice.

But what if the mobile phone is compromised?

Note however that the ease of use has a downside.

To use Google 2FA Push with a given Google Account “XX”, the phone has to be given access to said account “XX”.  (e.g. “Settings / Accounts / Google”).

This means that if the mobile Android phone is compromised, the attacker has essentially obtains access to whatever Google applications / accounts that have been enabled on the phone. Since the attacker controls the phone, (in theory at least) the attacker also controls the phone’s responses to 2FA prompts.

Google suggests implementing a screen saver password to offer some protection.

BTW: Try not to keep passwords on the mobile phone that is being used for 2FA

Pursuing this line of thought results in the following obvious conclusions.

For robust security:

If the mobile phone is being used for 2FA, then the phone should *not* store easily available password credentials.

This is because the “something I know” and the “something I have” would both be dependent on the integrity of the same device.

Specifically:

• If the phone is compromised, the attacker has access to the onboard password credentials and can potentially activate the phone for 2FA prompts.

• The situation is even worse if the mobile phone is rooted. The malware does not even have to compromise the phone; it only has to execute.

Specific recommendations would be:

• Don’t use something like LastPass to sync all password credentials to the phone. On the phone, type passwords manually, then set the applications to conserve access.

• Don’t bother with advanced security such as 2FA or data encryption on a rooted phone. This would be illogical since the phone is totally compromised in any case.

That’s it for Google Push AuthN. The next article looks at LastPass, an online Password Manager that supports 2FA with mobile Push AuthN.