Meraki Multi-factor Authentication

 In a recent post, I was voicing my concerns around the existing default security method employed by cloud-wireless solutions to 'protect' administrative access to their service. In summary, I proposed that some type of multi-factor authentication should be the default method of access for administrators (both customer and vendor) of cloud wireless services. The current default of a "username and password" is too weak when considering the damage that can be inflicted on an organization by unauthorized access to any cloud-managed network.

I heard from one of the guys at Meraki, letting me know that they already have multi-factor authentication. 

I already knew that they have an SMS OTP method, but I didn't really think that it was a particularly good solution. For instance, what about if you're out of cell-phone range or suffer one of those annoying delays in receipt of an SMS message? However, after taking another look, they also now show support for authentication amongst the authentication options, using the Google Authenticator app. Here is a screen-shot from the dashboard: 



This sounded very promising, so I thought I do a little more digging around the capabilities of their two factor authentication, particularly the Google Authenticator option.

Google Authenticator - Trust Google...Really?


My first thought when I saw the Google Authenticator app mentioned was: "How many organizations are going to trust or rely on Google to perform their authentications, or are going to want to sign up for a Google account just to authenticate against their cloud service?" It turns out it's not like that at all - you don't need to trust Google or involve them at all in the authentication process. 

The Google Authenticator app is an implementation of the time-based One Time Password Algorithm specified in the IETF standard  RFC 6238. Yes, that's right, an open, standards-based OTP process! That also means that you don't really need to use Google's OTP app at all - other apps which implement the same RFC should also work just as well (so you don't need to rely on the Google app). As far as I can tell, there is no communication or involvement with the Google network at all - the app is standalone (unless you were using it to log in to a Google service)

The algorithm relies on the "prover" (i.e. the app/soft token) and the "verifier" (i.e. authentication server) being able to accurately derive the current (correct) Unix time. During the registration process of the app/soft token and authentication server, the two entities are synced so that at any point in the future, they will be both be able to derive the same time-based OTP. One time passwords are generated every 30 seconds and are 6 digits long.

As long as the prover and verifier use the same RFC OTP standard, it doesn't matter who is providing the services. This fact is being taken advantage of by a growing number of organizations, including: Amazon Web Services, Google Mail, Dropbox, Lastpass and Microsoft (to name a few). They all use two factor authentication using the RFC 6238 standard. Users of multiple services are therefore able to use the same app (e.g. Google Authenticator) for authentication - they can have multiple accounts authenticated by the same instance of the authenticator app (even though they are all authentication systems run by different organizations) 

Jumping on this standardized OTP bandwagon looks like a very smart move by Meraki. Their customers can download an authenticator app (which is free in the case of Google Authenticator)  to their smartphone (Android or IOS) and use it to generate one time passwords that they can use to access their Meraki dashboard. Why invent a new OTP system when their is already a widely accepted, standardized method in place?

Setting Up The Meraki Dashboard for Two Factor Authentication


My next step was to have a go at setting up two factor authentication myself, to see just what is involved. Unless the process is relatively easy to execute, it may end up being more trouble than it's worth to configure.

As I'd already read about the requirement for Google Authenticator, I went along to the Google Play store and downloaded the app to my Android smartphone.

Next, I logged in to my Meraki dashboard and tried to set up two factor authentication for my organization. It initially refused, as I had to enable the two factor authentication for my own account first (which makes sense as I am the admin for the organisation). I went in to my profile and enabled two factor authentication. I was presented with the following screen:



As I already had the Google Authenticator app installed on my (Android) phone, I simply used the app to capture the second QR code shown on the screen-shot above (which has been replaced by a fake one in addition to being blurred out).

Once the QR code had been scanned, the Google Authenticator app showed me a 6 digit code which I typed in to the verification code field on the screen-shot shown above. It was accepted first time and that was it! Here is the Google Authenticator screen-shot taken from my (Android) phone:
 


The only drawback to using a two-factor system like this is the inconvenience if you are unfortunate enough to lose your token generator (i.e. your phone with Google Authenticator on). You obviously cannot generate your one time passwords to login! So, I checked out the Apple App Store and downloaded the same app for my iPad (well, it's an iPhone app, but worked fine on the iPad). So, if I should lose my phone, I can use my iPad to generate my OTP as an alternative. 

I registered it using the same QR scanning technique via the Meraki dashboard and had my iPad registered in just a few moments. Here is a screen-dump of the iPhone app:


It's actually pretty cool to have both of the devices next to each other and see them generating the same OTP every 30 seconds. As they are time sync'ed and have been registered with the same authenticator source, they will always generate the same OTP.

Next time I logged in to my Meraki dashboard, I used my regular username and password, but in addition, I was prompted to enter the 6 digit OTP shown on my phone app:



I entered the code and was allowed access to my regular dashboard. The two factor authentication worked perfectly.

Just to prove the whole standards-based theory, I also installed another (non-Google) OTP app called "HDE OTP" (which is again free) on my iPad. Once I had done the whole QR code sync process again with that app, I could also use it to log in to the Meraki dashboard!

Summary


Meraki look they have done a really nice job of implementing two factor authentication for administrative access to their cloud management service. By using a standardized approach, they provide a very flexible, but secure approach.

My only preference to improve this would be for their dashboard to use two factor authentication as the default authentication method. Perhaps after an initial 5 logins using just a username/password login, users could be nagged by the interface to set up an OTP access method. If they definitely do not wish to use it, perhaps they could explicitly opt-out of the OTP approach by setting a check-box to disable OTP and have to check an acceptance check-box to state that they understand the significant security risks of not doing so.

All in all though, I have to say: "Nice job!".

References:

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment