Improving Application Security by removing passwords
Passwords and security go hand-in-hand. Or so we’re told. But human nature is the inherent weakness: when we’re asked to provide a password, we don’t mix it up, because, we need to remember it.
The better applications ask for ‘strong’ passwords, which in itself is a good thing. At least 8 characters long. Upper-case. Lower-case. A couple of digits. And don’t forget the punctuation symbols too.
However, and be honest, how many times do you just substitute ‘$’ for ‘s’ and add the number ’1' to your favourite password, just to pass validator? You’re not alone, and in good company :-)
A relatively recent alternative approach, nobly led by Apple with Safari suggesting strong password and storing it securely, has solved one aspect of the problem with the genuinely random passwords, but I still watch users trying to remember them, or worse again: writing them down. There’s absolutely no point in having a slip of paper in your drawer or phone case that reads:
Right? Or again, blushing a little?
It may not be paper. Think of account details stored in a text file on a shared drive… Identity theft does not always strike from the outside!
So… what’s the alternative?
While building a number of online applications over recent years, I developed a design pattern that eliminates the password all together, improves usability and strengthens security.
Working within the observation that most users access most business applications (not Apps) from their laptop or desktop PC, and in addition, these machines offer improving physical security, there is another way.
All online systems already utilise the activation-through-email link model to validate the user’s email address and then subsequently to set a password.
Too good to be true?
My design pattern is to use this process to validate the email address, but then to activate the application session directly, without requiring the user to provide the password. Neat, or what? The user experience is immediate. No need to compose, repeat and remember the password. Or as some systems do, no need to login immediately after setting a new password!
The way it works is that the activation key is, of course, unique, disposable, time-limited and tied to the email address. Once confirmed, the server generates a high-entropy system unique and long-lived session identifier. That’s pretty much what happens in web applications anyway, although our session identifiers are a little longer and therefore harder to guess.
Of course, there is also a core assumption that all server connections use encrypted connections, for example https (SSL), to prevent curious onlookers from spotting the session identifiers, and your data too!
What about session timeouts?
Many applications have transitioned to the ‘always on’ model, where the user is permanently logged-in. The password-less model automatically supports this.
This works especially well for regular interactions, especially where content is consumed. Such systems frequently implement a 2 Factor Authentication (2FA) security model, where a second means of identification, for example a code sent by SMS messsage or a number generated using Google Authenticator, is used to additionally secure key transactions or profile updates. Our model works well in this case too.
An important security policy often overlooked, is automatic device locking. Whether a desktop, laptop or smartphone, it must lock after as short a period of inactivity as possible. There is just too much at stake for these devices to be freely accessible, especially as many are becoming effectively impossible to compromise and only a fingerprint is needed to unlock it.
But I have multiple devices…
Yup! So do I. And that’s the real world. We each expect to access our business applications at our desks, on the train and on the sofa!
No problem! Provide the email on the new device, and authorise access on another (we like including a 2FA pass here too.. just to be sure).
What happens when I log out?
The session key is simply cleared from the user’s device. Done.
If this was the last active session, then the user will need to start again, requesting a new link via email. But the chances are, they’ll have forgotten their password just as often, so no real pain here.
Why can’t I just set a password?
Back firmly in the realm of human nature ..
If I didn’t give the application a secret only known by me, how can I be sure that only I can access it?
This is real-world feedback, which in part prompted my authoring this article, where users need jut a little education into the realms of securing their online presence, in plain language.
All said and done, we also caved on some implementations, and provided our clients’ users the option to set a password, keeping help-desks a little quieter. Such are users!
I offer this article to stimulate discussion on the topic. If you think that this is a sufficiently strong argument to eliminate passwords, then spread the word and instruct your developers to remove passwords from your application.
26th October 2017