Warning: substr() expects parameter 1 to be string, array given in /home/gemi20/securitymusings.com/wp-includes/functions.php on line 1674

Innovation in Two-Factor Authentication

authyWhen I first read the article Authy Makes Using Two-Factor Authentication Easier I thought to myself, “why have I never heard of this Authy thing?” After all, we have been covering two-factor for a while. I went ahead and installed it, and started digging into the application and the company. I even fired off some questions about how they treat the information in the application and I’m impressed. This application is advancing the state of the art for two-factor authentication by making it not just simpler to use, but more secure as well. This article is covering how Authy is simplifying the use of two-factor authentication. Next week I’ll publish another article about how they are also advancing the state of the art when it comes to securing two-factor authentication.


Before I installed Authy, the standard two-factor authentication process for me was this:

  • Get prompted for an authentication code
  • Take my phone out of my pocket, unlock the phone’s screen
  • Launch Google’s authenticator app
  • Scroll through to find the right account
  • Type in the code on the website and hit submit
  • Put my phone away

authy-connect Every time I needed a code, I’d have to go through those steps. The techcrunch article above mentions it, but Authy just rolled out a feature that allows you to communicate the one-time codes over Bluetooth to your computer (currently Mac only, but Windows is coming.)

Authy has greatly simplified this process for me. Now, when I sit down at my desk, I launch Authy on the phone, and connect the desktop app to my phone before putting my phone away. Once I’ve done that, my standard two-factor authentication process now is:

  • authy-hotkeys3Get prompted for an authentication code
  • Hit the appropriate shortcut key on my mac corresponding to the code I need
  • Paste the code on the website and hit submit

For someone that has as many two-factor authentications to perform on a regular basis as I do, I welcome this simplification. (All these services are now offering two factor authentication: Gmail, Facebook, Twitter, Outlook.com, Lastpass, Dropbox, WordPress, App.net, Amazon Web Services, Linode, Dreamhost, Guildwars2, Evernote, Digital Ocean, World of Warcraft. If you use any of these and don’t use the second factor, well, get on it!)

Cloud-Based Backup

Another important innovation provided by Authy is cloud-based backup and recovery of your secret keys. Google’s Authenticator product gives you no way to save your secret keys. (Even Google’s built-in capability to back up Android phones skips the database of secret keys.) So if you lose your phone, or even upgrade, you have quite a bit of work ahead of you. You have to go disable two-factor authentication on all your sites, and then re-enable it, scanning in new QR Codes as you go.

Authy performs a cloud-based backup of your secret keys. Turning on the backup prompts you to select a password which will be used to encrypt the backups. According to Authy:

[The password is] passed through 1000 Rounds of PBKDF2 with SHA-2. The result is then use as a key encrypt the account key using a random salt and [the encrypted key and the salt are] then uploaded to our servers. The key is never uploaded so only you can decrypt them as long as you remember the password.

This is important to remember, that Authy never gets your key – so if you forget this password, you’re out of luck. (Just imagine you were using Google Authenticator.) If you remember it, though, all you need to recover your account to a new phone is your phone number (which lets you download the encrypted information to your new phone), and the password (which is used to decrypt the backup).

Authy has made at least two significant innovations in a two-factor authentication client which I think will help to improve the long-term adoption and viability of two-factor authentication solutions. It is always good to see some innovation in the world of information security.

Posted August 2 2013

Updating VMware vCenter and ESXi Certificates

By default, the installation of VMware’s vCenter and ESXi use self-signed certificates with hardcoded passwords to protect the private keys of their SSL web services. While it gets you services that work out of the box, it is really bad form and a poor security practice.

You may need to install a trusted SSL certificate on your server to prevent this warning from appearing.If you install (or update to) version 5.1 of the VMware infrastructure components, you will be left with a bunch of warning windows like the ones on the left. If you’re lucky enough to have access to your own public key infrastructure, you can issue your own certificates to replace those provided by VMware so you don’t see constant warnings. However, if you undertake this effort be forewarned: VMWare’s guidance (Replacing Default vCenter 5.1 and ESXi Certificates) is incomplete, inconsistent, and at times incorrect. This article describes the problems with VMware’s document, and the final section will hopefully help save you a little of the difficulty I suffered in updating these certificates.


The first thing that is problematic about VMware’s guidance is that it is incomplete. It leaves out an important detail: you have to use their hardcoded password. It says so right in this knowledgebase article.

Changing the keystorePass parameter from the default testpassword is not permitted. Also, the password used to generate the rui.pfx file must be testpassword.

While it is possible to change the passwords for many of the certificates for many of the services, you are wandering into unsupported territory. A grep search reveals at least 7 .xml and .properties files that need to get updated, and again you’re working against the advice of the knowledgebase article above. Only one time, for one certificate, does their whitepaper let you know that you must use their default password of testpassword.


There are six services that are used as part of vCenter/ESXi v5.1, and each one needs its own certificate. The generation process for each is very similar, and really could be simplified if VMware were to create a script to automate the generation of certificate requests. Without a script to help automate the process of generating the certificate requests, the chances of an inconsistency causing errors being made increase greatly.

There are many other ways in which the document is inconsistent with itself:

  • At times, the document assumes that all the services are running on separate machines. At other times, the document assumes that some of the services are running on the same machine.
  • Sometimes, the document includes links to the prerequisite steps for each part of the process. Sometimes it does not.
  • Sometimes, the document includes the paths to where the files exist on Windows 2003 server and on Windows 2008 server. Sometimes, it only includes one or another.


One of my favorite quotes from the document is here: After the initial restart of the services, wait for five minutes. If the VMware vSphere Profile Driven Storage service stops during this time, restart it. If you have done everything correctly except you have changed one of the default passwords without updating the appropriate .properties and/or .xml files, you can start this service, and it will stop within 30 seconds. So you read this instruction, and restart it again. And carry on with the rest of the document. Unfortunately, you will never get this service, or any of the other services which rely upon it, to start and run correctly.  The certificate password problem causes the service to fail to start, and while you can continue on through the rest of the document, the services will not work.

And if you’ve got a setup where most of your vCenter installation is on one machine (as I do), and you follow their instructions, you end up generating and overwriting most of your certificates, as the document expects them all to be in the same folder with the same name.

Final Suggestions

With that, here is my advice for a successful update to all the vCenter and ESXi certificates.

  1. Password: As much as it pains me, stick with their default password of testpassword. In all cases, their instructions require you to also place the raw, unencrypted private key in the same location as the file protected with the hardcoded password. So, it is no worse than having the private key in its unencrypted form. Make sure you do set appropriate operating system controls on the files to limit who can have access to those files.
  2. Organization: Create a folder called c:\certs (or something) and have 6 subfolders: InventoryService, LogBrowser, SSO, UpdateManager, vCenter, WebClient. Place all your .cfg files in these folders, and generate/place your .key, .csr, .crt, and .pfx files in these folders as well. This will help you stay consistent and make sure you don’t accidentally overwrite files.
  3. Make backups: Make sure you never overwrite any of the files when you are putting new certificates in place. Always copy or rename the original files so that you can get things working again if one of the inconsistencies of the document causes you a problem.
  4. Check Services: Anytime you’ve finished updating certificate files for one of the services, make sure the service will start, and run properly. If you start a service successfully, check on it again a minute later. If it has stopped, don’t continue blindly – check the log files for errors. Unfortunately the Windows Event Viewer will typically only tell you about service-specific error 1 (0x1) or 2 (0x2). You’ll need to check your logs in folders such as %ALLUSERSPROFILE%\Application Data\VMware\…\logs.

I hope these tidbits can help save someone else some time. If you would be interested in a script that could help automate much of this process, let us know in the comments!

Posted January 23 2013

What to do when you see a phishing email

The tl;dr summary for those with short attention spans – Don’t open the attachment, be quick to delete anything you’re not sure about, and if you want to help in the fight against phishing, report it using the guidelines I’ve outlined below.

I received a pretty awesome phishing email today. It included a significant attachment that I’m looking forward to analyzing at a later date.

Since it will take me a while before I’ve got the time to run the analysis, I decided I wanted to forward it around to the appropriate organizations to ensure that they take some time and analyze it and make sure other individuals can be protected from it.

It turns out that there are more places to forward this than I expected. So here’s what I’ve found. You can forward the email to these addresses:

You can submit phishing websites to:

Most anti-malware providers are part of the APWG, so definitely make sure you submit there to increase the chances of later defense against the same attack.

Now what happens when you forward the email and you get an error?

Well, some (good) email providers scan email upon sending. In that case, you might not be able to actually email the example for further analysis. In this case you can typically send an encrypted zip file.

To do this, find a way to get the raw message source for the email. (Some help here and here.) Then, save the source as a plain text file using a local text editor. Finally, use a method to zip that text file with password-based encryption (use Google to find steps that will work best for you).

When you send the email, attach the encrypted zip file and explain you attached an encrypted zip file of the suspected phishing email, and include the password you used when zipping it. The password is just there to get past the email server, you don’t want the recipient to not be able to view the message!

Now, pat yourself on the back for helping take a bite out of crime.

Posted December 4 2012

Keeping Up-to-date

Yesterday, this story on Wired was making the rounds: How a Google Headhunter’s E-mail Unraveled a Massive Net Security Hole. Sure, the title is probably hyperbole, but it is an interesting story. At a high level, mathematician Zach Harris noticed that emails from Google – and from several other prominent domains including eBay, PayPal, Yahoo, Amazon, etc. – could be spoofed.

Anyone who has ever run telnet to port 25 and sent an email from santaclaus@northpole.net or billgates@microsoft.com knows that email has always been pretty easy to spoof. Given the rise in unsolicited emails also known as spam, something had to be done. In 2006, a working group was founded to try and create a standard that would make email harder to spoof. It is called  DomainKeys Identified Mail or DKIM. The way DKIM works is that the sending email server applies a digital signature to the mail message headers (completely transparent to the user). The public key which can be used to verify the signature appears in the sending email server’s DNS record.

Since it uses some fancy technology like a digital signature and relies on DNS – a core capability of the internet – email with a valid DKIM signature can generally be trusted that it is legitimately from the domain listed in the From field… Well, that is if you’re doing DKIM correctly.

Mr. Harris found that the DKIM signatures for a number of popular domains used such weak cryptography that it was very easily cracked. While the DKIM standard calls for 1024 bit keys, he found popular domains with 768 bit, 512 bit, and even 384 bit keys. As he points out in the article, he was able to crack the 384 bit keys on his laptop, and for $75 he cracked some 512 bit keys by outsourcing the computing power to Amazon Web Services.

The best quote in the entire article, and the reason I bring this story to your attention is the following:

“People who use cryptographic tools need to realize that local configurations need to be maintained just like software updates need to be maintained,” he says. “In 1998 it was an academic breakthrough of great concerted effort to crack a 512 bit key. Today little old me can do it by myself in 72 hours on AWS. The field of cryptography keeps developing and breaking new ground just like everything else, and you can’t just install a private key, or select a hash algorithm, and expect it to be good forever.”

Wise words, indeed. If connected to any network, you must consider your operating system, your software, and your cryptographic algorithms and keys all as perishable items. They need to be examined for mold and rot periodically, and replaced when necessary. You can no longer afford to “set and forget” anything and consider it dependable.

Posted October 25 2012

The Rise of Two Factor Authentication

It’s a little embarrassing to admit, but it seems that the mistakes of one person globally syndicated columnist have led to a rapid increase in the acceptance and use of two-factor authentication technologies for authentication. Within the last week, I have set up both my Dropbox account and this very blog with two-factor authentication.

Mat Honan’s sordid tale did a lot to raise awareness of how passwords are imperfect as an authentication mechanism, as have the many password breaches that have occurred over the years. Most interesting, though, is how Google created and freely released Google Authenticator as an open source application and how quickly organizations have begun to embrace it. While I’ve traditionally been a PKI guy (I know, that’s SO 2003), when the time came for us to secure our VPN with a second factor we went with Google Authenticator rather than a PKI token. Why? Cost. Hard to argue with free.

So now, I have Google Authenticator token set up with: my personal Google account, my corporate Google Apps account, my corporate VPN, my blog, and my Dropbox. What do you think the next systems to add Google Authenticator support will be? Let us know in the comments.

Posted August 29 2012