I came across something clever and rather cute the other night – the Qwerty Card. The basic principle is the Qwerty Card functions as a ‘password generator’ and management system, using three components: a secret key unique to the card, the user-defined password, and a substitution cipher for encrypting the account name. Together, these form the password for a site.
Initially it seems an excellent idea, as it’s generally safer to carry a strong password in a wallet than set a memorable one that’s easier to crack – here multiple passwords are replaced with a card and a substitution cipher. Plus, the Qwerty Card might count as a valid example of ‘two-factor authentication’. Alternatives are available.
The Qwerty Card works perfectly where passwords themselves are never stored and nobody except the owner sees the card. Unfortunately, all too often they are indeed stored and find their way onto Pastebin, and it takes just one exposed password to compromise all the others derived from the card system.
As I’ve mentioned, there are three components to a password – the card’s unique key, the user’s codeword and the encrypted name of the site/service. The password would be something like:
[sh(/J3Hq] [Mar15] [kQf7qk0]
So it gives a password that’s pretty tough to crack without knowledge of the secret key – roughly 118 bits of entropy, give or take a few bits.
What if this password was exposed, because it was intercepted or wasn’t hashed on the server? If a password has eight seemingly random characters followed by something not so random, an attacker might suspect it was generated using a Qwerty Card (in which case it’s safer to encrypt the second and third character sets).
The first set of characters would likely be constant across the owner’s other accounts. It’s also known that the third set of characters is the encrypted system/site name. An attacker would know that whatever’s between those two sets is the real password. And it gets a little worse, as the encryption key would also be partially determined by swapping the characters in the third set with the name of whatever site/system was hacked.
Would I use the Qwerty Card? Perhaps. It’s an excellent solution for a limited number of accounts where the passwords are never stored, or maybe for a workplace where employees require multiple passwords for different services on a network. But again, one exposed password is a single point of failure, and the risk would increase with the number of accounts it’s used for.
The Encryption Key Distribution Problem
Symmetric encryption is only secure if the secret key is protected. Today we commonly use public key encryption for communicating symmetric keys. In the past, keys and ciphertext would typically be communicated over separate channels – the message over radio or telephone, and the key through mail or courier. It worked on the premise that very few adversaries are capable of intercepting both.
There are still systems today that involve the physical transportation of secret keys – numbers stations and key fill devices are just two examples, and I’ve encountered both in a previous job. They come with the added security measures such as chain of custody, expiry and strict handling procedures. So do RSA tokens, to a lesser extent.
What about the Qwerty Card? It works on the same principle that online threats are unlikely to also intercept something that’s physically transported, otherwise what layer of security could RSA tokens (which do occasionally get lost) provide? But how can the recipient be sure it hasn’t been read along the way? Well, physical integrity checking seems the best answer, in the form of tamper-resistant packaging that even fewer adversaries are capable of resealing.
You might also be interested in an alternative that’s free, doesn’t involve re-using a single key, and doesn’t involve sending a secret key through the mail.