Security by annoyance

TOTP (Timed One Time Password) uses a secret which is a block of binary data. It suffers from being symmetric in that the server doing the checks, and the user (usually in an app on their phone) both have to know the same secret.

This presents the problem of getting this secret from one to the other. This story is about that journey.

A friend has a customer that wants to use some specific device they already have to provide OTP codes, and so has to send the secret to him to load on to the server.

Firstly, this is not quite how it is usually done - the usual way is the server makes a (new, random) secret, provides it to the customer (often as a QR code), who confirms receipt by entering the current OTP code. All done over https to be secure. Sorted.

But in this case the customer had the secret and wanted to send it.

As I say, the secret is just a small block of binary data, usually expressed as base32.

They sent, by email, an RFC6030 XML file, signed, with base64 coded encrypted secret in it. They also sent a simple 16 byte binary file which is the key, by email.

• The base64 had to be converted to binary
• The first 16 bytes extracted as IV
• The remaining bytes stored, in binary, as the encrypted data
• The IV had to be converted to hex for openssl command line
• The 16 byte binary key file had to be converted to hex for openssl command line
• openssl command line for AES-CBC was run and produced a binary decoded file
• This had to be converted to base32 and loaded on the system as the secret

Was this secure?

Short answer: no. Both parts sent by email. Sent as separate email as obviously no hacker could possibly intercept both emails!!!

Alternatives?

Almost any secure messaging app, e.g. signal, interactively whilst talking to the contact, sent as base32, and ideally as a disappearing message.

Or email the base32 over PGP encrypted email.

Or, well, almost anything else! Reading the Base32 over the phone FFS (though phone calls are rarely encrypted in transit over the network).

Storing the key?

One thing done on the back end system, apart from encrypted disk, etc, is to store the secret encrypted with the users password and salt. The password is not stored, only an argon2 hash. This means you can validate a password+totp code, but you cannot extract either the password or the TOTP key from a leaked copy of the database. I mean, yes, if someone can get a copy of the system and database, and trojan a user in to entering password, they can decode the TOTP as well, but that requires that extra user interaction step for each compromised user record.

P.S. what is my involvement?

Mostly helping my friend out to understand what he had to do. We are all cautious to ensure security, as you would expect.

JSON all the things

I have a feeling that industry is moving away from XML and towards JSON...

Just a feeling, but even HMRC, who used to used XML for VAT and do for RTI, have moved to JSON for MTD (VAT).

Fundamentally XML is too complicated - especially with name spaces. The options in XSD (which is the common way to define what is valid in an XML file) is also a bit of a mess - defining the order of the XML objects even, which is a pain if you ever work with any XML. JSON does not expect values in an object to be in any order (just in an array).

JSON is simpler in many ways, but there are differences. The type of a simple value can be more than just text (as you have in XML), it can be null, boolean, number, or text. Javascript tents to just convert between things seamlessly in most cases. It does get to be fun in arrays where each value can be a different type, even an object or array itself.

JSON also makes it a lot easier to create and process using languages like Javascript, obviously.

As it happens, at A&A, we have been working on new APIs for our control systems (more on that another day), and these are all JSON based too. But this week I have started on some work on the accounts system.

I now have JSON for documents, i.e. invoices. We currently allow customers to access invoices in XML, PDF, Plain text, and HTML, and as of now also JSON. You can ask for a JSON attachment to be automatically included in your invoice emails if you wish - digitally signed, obviously.

Whilst we have loads of work behind the scenes improving the way the accounts work, this JSON interface should be pretty stable now.

JSON vs XML

Recently, I tweeted

Why does ACME use JSON, arrrg! I know XML is a pain, but surely that would have been better. I need to knock up a JSON library now :-) The plan is for @firebrick to have ACME @letsencrypt built in - not in this coming release of code but next one, soon...

— RevK® (@TheRealRevK) 7 April 2018

Well, I am starting to wonder if JSON is better than XML in some ways now. I have coded a new JSON library for the FireBrick today. It was not hard, in fact, the simplicity does make me wonder if neater in some ways than XML.

Both have a clear formal spec, but what do they have different?

• XML has all sorts of special cases like CDATA and processing instructions and comments, JSON does not
• XML does not allow a null character even escaped, JSON allows it
• XML has all of that pesky namespace stuff. It has its place but for a lot of systems it does not help matters and makes it more complex
• XML has no concept of even simply types for data, JSON has strings, numbers, boolean, and null as distinct and identifiable types.
• XML only has objects with attributes and sub objects, JSON has arrays which XML does not.

The JSON library was actually really easy and the syntax if very strict, surprisingly so, to be honest.

So I am leaning towards JSON as being better than XML for now.

What is this all in aid of? Well FireBricks use code we control and we have coded everything from operating system startup to IPSec. So I needed to make a JSON library. There are "standard" open source libraries we could use, but having only taken a day to do this I suspect integrating something in to our build system would have taken longer.

But why do I need JSON all of a sudden? Well ACME uses JSON, and I am working on ACME coding to allow FireBricks to easily have Let's Encrypt certificates for https. So I start with a JSON library.

A good days work I think.