Feb 282015

AuthyI am a big fan of two-factor authentication. Heck, I even have my own site and C# code to prove it. :)

Let’s just quickly recap most common two-factor authentication: Beside user name and password your service provider usually has, you have additional private key shared between you. Based on that key, current time, and some clever crypto (also known as TOTP) you will get new 6-digit code every 30 seconds. Whenever additional security is needed (e.g. login from a new computer) you enter that code and server checks it against its own calculation. Since entered code depends on a key that is never transmitted over the network and it changes all the time, chances of somebody faking your account regardless of snooping traffic and knowing your user name and password are significantly lowered.

While all this is not panacea, for me it is clear: If some service has option of two-factor authentication, you can pretty much be sure I’m going to use it. Except for CloudFlare. Why? Because CloudFlare decided to go with Authy.

Major beef I have is that, while I trust CloudFlare, that trust does not extend to all their partners. With Authy not only I am giving my phone number but I actually have to trust my (partial) login details to them. By design they have my login e-mail, phone number and token. Only password is missing from the list. While pretty much all other services will allow me to retrieve shared key and use application of my choice with me deciding who I want to trust, with Authy that choice is out of your hands.

If you want to use it with another application you will stumble upon a wall of intentional incompatibility. Where virtually everybody else uses 6-digits with SHA-1, Authy uses SHA-256 and 7 digit codes. Although there are some attacks on SHA-1 algorithm, they do not apply on its HMAC version used with TOTP. In this context SHA-1 is as secure as SHA-256 – no more, no less. Seven digit code does give slightly increased security but not a significant one. It pretty much boils to fact that the only benefit Authy gets from this is user lock-in.

There is at least one 6-digit SHA-1 TOTP client on every platform you can think of. From Linux command line to a Pebble watch. You can have your code generated wherever you want. Not so with Authy – it only supports iPhone, Android, BlackBerry and Chrome. Forget about native Windows or OS X application.

Yes, Authy can import other keys (e.g. Google’s), largely helped by the fact that all other TOTP services use exactly same process Authy intentionally avoids. If you do that you get a benefit of syncing all your tokens across all your devices. Think about that for a moment. For that to work Authy has to store them centrally. Can you really ignore fact that Authy suddenly has access to tokens for all services you hold dear and that some SSL bug might cause their exposal? I prefer not to even think what damage rogue employee might do.

In some regards I appreciate proprietary services like VIP Access more – while they are not cooperating with other applications and are fracturing auth universe, at least they are not trying to steal all your other tokens. While intentions might be the best, Authy is doing just that – stealing all you tokens by a false pretense it can keep that data secure.

Among all the crazy stuff, only saving grace for Authy is ability to PIN protect mobile application. Considering all other nonsense Authy brings, I don’t think it’s worth it – just practice locking your phone.

All this is not really Authy’s fault. They have their business case whether they continue to provide API for two-factor authentication or if they decide to run with all collected data. I am disappointed with CloudFlare for their lousy job in analyzing what users want. Although they did go through motions, their conclusions don’t make sense. Let me give you a few examples:

Although they kick out Google Authenticator platform from their consideration, they end up deciding on essentially same system with Authy – both Google and Authy system rely on standardized TOTP cryptography. There is essentially no difference between them – other than Google having open-source solution and Authy being closed-source. And bug they mention had nothing to do with cryptography anyhow.

Then they mention Authy’s ability to revoke keys as a huge advantage. Compared to others Authy’s system is just over engineered with having separate private/public and token keys. All other systems don’t offer easy revoke functionality because they don’t have to – just generate a new key instead of the old one and you have exactly the same effect because all codes generated with the old key won’t match. All Authy offers here is a dialog box toward customer explaining that key is revoked. At most this is GUI benefit, not a security one.

Lastly they state that TOTP requires “fairly precise match” of the user’s clock for authentication to work. How do you define fairly precise? In RFC itself it is recommended to allow for at least 30 seconds difference (up to 89 seconds). Even if we assume you have valid reason why some of your clocks might be more than 30 seconds off, do you wonder how Authy accomplishes better reliability than others? Only way they can do that is if they accept code for longer and essentially make more codes valid. There is a reason why 30 seconds was selected as a step and why acceptable window is recommended to be within 60 seconds and not e.g. 20 days.

It might just be me, but I think CloudFlare made a bad choice and I won’t be having it.

PS: Gem from Authy’s privacy policy: “If Authy is involved in a merger, acquisition or asset sale, we might not continue to ensure the confidentiality of any personal information nor give affected users notice before personal information is transferred or becomes subject to a different privacy policy.” Honest and worrisome.

PPS: Yes, screenshot is real: iPhone application seems to have a bug where certain private keys that work just fine on Android and Chrome will cause output to be 000000.

Feb 222015

TOTP - Time-Based One-Time PasswordRecently I was working on a project where time-based one-time password algorithm might come in handy. You know the one – you have token that displays 6-digit number and you enter it after your user name and password. It used to be restricted to hardware (e.g. RSA) but these days Google Authenticator is probably the best known.

While rolling something on your own is always possibility, following the standard is always better because all tough questions have been answered by people smarter than you. In this case all things needed were covered in RFC 6238 (Time-Based One-Time Password Algorithm) and RFC 4226 (An HMAC-Based One-Time Password Algorithm).

While specifications do grant you some freedom in algorithm choice and number of digits you wish to generate, looking at other services implementing the same algorithm, 6-digit SHA-1 based code seems to be unwritten rule. Also universal seems the rule to use (unpadded) Base32 encoding of a secret key. Any implementation of one-time password algorithm has obey these rules if it wants to use existing infrastructure – both server side services and end-user applications (e.g. Google Authenticator or Pebble one).

With my OneTimePassword implementation, basic code generation would looks something like this:

var otp = new OneTimePassword("jbsw y3dp ehpk 3pxp");
txtCode.Text = otp.GetCode().ToString("000000"); //to generate new code

If you are on server side, verification would look just slightly different:

var otp = new OneTimePassword("jbsw y3dp ehpk 3pxp");
var isValid = otp.IsCodeValid(code); //to verify one that user entered

If you want to generate a new secret key for end-user:

var otp = new OneTimePassword();
var secret = otp.GetBase32Secret();

Pretty much all basic scenarios are covered and then some. Sample with full code is available for download.

PS: OneTimePassword class supports many more things than ones mentioned here. You can use it in HOTP (counter) mode with TimeStep=0; you can generate your own keys; validate codes; use SHA-256 and SHA-512; other digit lengths… Play with it and see.

Feb 162015

WordPress - Two factor authenticationBeside getting HTTPS working, probably the most important security feature you can get for free on WordPress is two factor authentication.

How does two-factor authentication work? In addition to your usual user name and password, you get to enter a 6-digit number changing every 30 seconds or so. Since that number is based on a key only you should know, you can consider it as another password. However, due to its constant change nature, anybody snooping only gets to know your login for next 30 seconds or so. After that time has passed previously captured code becomes useless. Two factor authentication essentially makes fact your password is known irrelevant.

It is not a fool-proof protection – somebody can just steal your key in addition to your password. However, since key itself is never transmitted over wire, it makes things considerably more difficult for attacker. And it will definitely make common every day non-targeted password attacks irrelevant.

Even if you run without HTTPS (which I don’t recommend) and you have to login over public wireless (scary!) this will keep anybody snooping from getting full account details he might need to login. Yes, there is possibility of somebody using your authentication cookie but, as long as you logout, you can rest assured that nobody can login after you. In a plain-text world there are many other attacks somebody might try against you but two factor authentication closes the most obvious doors.

I personally use Two Factor Auth plugin for this purpose. Although it officially doesn’t support WordPress 4.1 I found it works perfectly fine. Installation is WordPress-simple and by default you will get a pretty usable system of getting codes mailed to your users when they attempt login.

However, each user gets an opportunity to enable “third party” delivery type. That will give QR code you just scan into e.g. Google Authenticator and you mobile phone can generate codes every time you need them. System of generating these codes is completely standardized and I am sure you can find your favorite application – whether is on desktop, mobile phone, or even a watch.

It is a small change that will help security a lot.

PS: If you have Google mail and two-factor authentication is not enabled, what are you waiting?

Feb 102015

Recently I saw SONICable Indiegogo project promising to double the charging speed on computer. It is supposedly an advanced USB cable with a magic switch cutting your charge times in half. But not everything is as it seems.

First onto a topic of “unleashing double the charge power of the regular charge cable”. As you might know, USB standard limits current to any USB device at 500 mA. What is not obvious from this is that even now you can have devices pulling much more than this – all the way until small fuse stops you. Devices obeying the standard pull 500 mA because they are well behaving citizens – not because USB restricts them from more. Just measure current of any USB cup warmer. :)

Some devices, mobile phones in particular, also have a fast charging mode that triggers when they detect a wall charger. Detection method itself used to be different for every manufacturer. Fortunately they got standardized into two camps – Apple and everybody else. Leaving Apple aside, most phones use USB Battery Charging Specification. Deep in technical text there is a Dedicated Charging Port (DCP) detection method consisting of “short D+ to D- through resistance RDCP_DAT“. At end specification we have RDCP_DAT defined as maximum resistance of 200 Ω. In laymans terms – just connect the freaking D+ and D- wire together.

Since standard USB cable has four wires (5V, D-, D+, and GND – let’s forget about ID for now), whole high-tech solution is to connect two wires together. That will make device think it is connected to a wall charger and that it can stop being good 500 mA citizen. It is the phone who will then pull around 1000 mA (rarely more) from computer. Since fuses on USB port are intentionally overdimensioned, computer will generally allow it.

There are thousands of YouTube videos alone showing you how you can do this. All you need is to get an old USB cable and cut it open. Then short data wires (white and green) together and voila – you have a cable giving you 1000 mA magic.

There are devices enabling this on eBay. Quick Google search found me The Practical Meter and USB Meter Pro on Kickstarter using exactly the same “magic” as SONICable. Heck, even my UsbAmps uses exactly the same principle from 2013 onward as a button option. Unofficially, there were people seeing me use small screwdriver to connect D+/D- lines way before that. :)

This functionality is nothing special, nothing secret, nothing patentable, and definitely not magic. Paying for a $25 cable promising you magic when all it does is enabling something you can get either for free or for fraction of a cost is crazy in my opinion. To be completely fair, just based on images, it does look as a nice cable – those with fashion in mind might be able to justify $25 cable. Just don’t buy it for its technology.

And remember – with USB 3.1, its new connector, and a new USB Power Delivery standard all this will become pretty much irrelevant side note in the history of USB.