“I forgot my phone. Can I use your tablet to check my gmail?”
“Sure, here you go.”
“I can’t log in.”
“Why not?”
“It sent a text to my phone to check if I was who I say I am.”
“Well, that’s useful.”
(AKA “something you know, plus something you have, except that you don’t always have it, especially in emergency situations”)
This conversation, or some variation, is pretty common. In the search for “really secure”, we have begun to verge upon “too secure to use.” Never mind the fact that in an increasingly ruthless age of user-data sale by online services, I don’t WANT Google, Facebook, etc to know my cell-phone number. Never mind the almost daily announcements of massive data breaches at organizations that store increasingly personal data like where your father was born or part of your social security number. Leaving all that aside, what about anonymity? I propose we go in a different direction.
Many people already use simple algorithmic passwords, like “use the same seed word everywhere, but add the third character of the domain name at the end” or “reverse the first word in the organization name and add my initials”. This has pretty solid benefits. First, it’s very easy to create long, fairly uncrackable passwords that are very easy to remember. Second, even if someone breaks your password for one account, they only get that one account’s password, not all your other accounts’ as well. Third, it requires no personal data to be stored on the account’s server (or lies about personal data, which you then have to keep straight in your head), which allows for a fair bit of anonymity if you wish it.
So far, so good, but this only solves part of the problem! With an algorithmic password, you’ve isolated your accounts from each other’s breaches, and generated fairly secure passwords, but those individual accounts can still be broken or breached. If one password is stolen or hacked, you’ll need to change it, and changing it means either now using a different algorithm or seed word for just the breached account, or changing them to something new for all your accounts. This maintenance can quickly become as unwieldy and complicated as managing normal passwords.
I propose the scheme of algorithmic passwords/second authentication factors that morph over time. There are many ways to achieve this that require different levels of user and server-side complexity, but all use a randomly generated or time-morphing security seed presented to the user at login, and password algorithms that can be represented in a simple password algorithm language, perhaps similar in concept to PERL regular expressions (but without the insane complexity). This scheme retains all the benefits of normal algorithmic passwords, while adding the advantages that a) passwords become almost impossible to brute-force attack, since the answer will be different for every guess, and b) even if a password is broken, unless the account is immediately commandeered, the breach will be sealed as soon as the current session expires, so no one can lurk in someone else’s account.
A simple way to add this would be for servers to allow users to define their algorithm at account creation, rather than, or in addition to, entering a password. At login, the user is presented with the randomly generated or time-based security seed. Using the previously entered algorithm, the server-side generates a response to this seed, as does the user (which they themselves encode brain-side using the same algorithm). The responses are compared, and a match results in authentication. While easy to implement, this method would still require users to manage their algorithms on a site by site basis, and a server breach could result in one’s algorithm being revealed, forcing the same maintenance headaches previously described.
Most convenient to the user, and likely most secure, would be a method that uses a highly secured authority service out in the network that the user can inform of their desired algorithm. At login, the user is presented with the randomly generated or time-based security seed. This seed is sent securely to the authority service, and the algorithmically generated response is compared to the user’s entered response. Again, this could be treated as the password itself, as a pure second authentication factor separate from a normal password, or as a hybrid of the two (say as a suffix to an entered password). With this method, a user’s algorithms can be managed from a single location, and a server breach would not compromise the algorithm, while retaining all the benefits previously mentioned. The down-sides are that a) it requires a complex back-end implementation, b) the authentication server becomes a potential bottleneck and single point of failure for all accounts, so it needs to be really secure and reliable, and c) it requires network access, making it problematic for some implementations.
There are lots of possible variations on these two basic schemes, but they are the most straightforward. In the grand scheme, this would be a fairly easy user authentication methodology for most organizations to implement, and it would make user’s accounts more secure while making their lives easier.
Just puttin’ it out there…
