I’ve been putting this off for far, far too long. I knew migrating to a password manager was going to be a long boring task and now I’ve started, I wasn’t wrong. Migrating to LastPass itself hasn’t been the painful part, the complete mess of all the myriad login implementations has.
The free solution is pretty comprehensive and covers all the popular browser, OS and platforms combinations you’re probably using. However, if you also want help with desktop applications you’ll need to purchase a subscription. The paid subscription is incredibly affordable at around £9. I can hear some of you crying:
“Why LastPass??? Are you mad? They’ve been hacked!!”
Well sure, they have been, like many other organisation have. The online world is a complex one and security is probably the most complex, subtle and poorly understood. The reason I trust LastPass is that in each instance of an issue being found they have responded immediately and, more importantly, in a sensible fashion. They’ve been candid with their users, issuing advisories and getting the fix implemented and deployed as quickly as possible. They don’t hide behind a facade of faked perfection, they “get it”.
Rather paradoxically, security is best handled in an open fashion. When the likes of Tavis Ormandy are poking around you have to be proactive.
LastPass Security Challenge
Migrating was utterly painless, LastPass imports from pretty much any source you could imagine. Once imported you can analyse your stored accounts for issues such as password strength, duplication or any that may have been compromised. How this compromised analysis works is something I haven’t looked into yet but I’m assuming it’s using some lookup process using previously compromised authentication databases.
Luckily the only issues I found were some duplication, yes I was guilty of this too, and some older passwords not being particularly strong.
Updating Passwords
So as I’ve been going through the process of addressing these issues I’ve gotten quite alarmed to be honest. It’s incredible what a sorry state security, and particularly login, is in.
I’ve not done any investigation into how LastPass works in terms of form completion but boy has it got it’s work cut out. Most of the time it succeeds in getting the passwords into the right boxes and the password updating process goes without a hitch.
The problems I’ve seen in many instances are inexcusable and frankly baffling at a technical level. It’s amazing how many sites consider a password of more than 16 or 20 characters as too long. Whoever made these technical decisions absolutely does not understand security and should be removed from the technical decision making process. Many other sites don’t allow special characters which further weakens the potential complexity of the passwords they accept.
Other sites have prevented LastPass from auto-filling the password fields in the web forms and then also block copy+paste in some hugely misguided stupid idea that somehow makes things more secure. It doesn’t, and I am looking at you argos.co.uk.
The arguments here are that the clipboard, the memory used to store copied items, can be compromised. Well, here’s the thing, if your users clipboard is compromised there isn’t a damn thing you can do about it. The user has far bigger problems to deal with than your web login form. The clipboard argument is plain stupid, if you hear it from someone in a technical meeting, calmly explain how misguided an idea it is, we need to kill these ideas.
Online Forums
Then there are the myriad options for online forum software. Things like vBulletin, phpBB et. al. They have horrifically bad login processes and are generally hosted on sites without SSL/TLS, which means credentials are sent in plain text – the worst security offence a site can commit. It makes a complete mockery of the entire concept of security since there simply isn’t any.
They are also usually hosted and configured by people that haven’t got a clue what they are doing and no doubt find the whole security issue gets in the way of their big idea anyway. I dread to think of what is happening between the submit button, database and the page reload.
If you can, get someone that knows what they are doing to set things up or use a hosted solution.
Dynamic Forms
Sites also sometimes dynamically load the login or password change textboxes. LastPass can sometimes detect this automatically, or using the advanced options to re-scan the page can update them. Although in many instances this fails as well. Again it seems a lot of the time these are incorrectly configured or somehow non-standard implementations.
LastPass at Fault?
It’s worth saying here that in many instances I might be inclined to point the finger at LastPass, but in all honesty it’s the myriad implementations and mistakes on the part of site developers that is to blame.
It’s clear that many form fields themselves are incorrectly setup, badly named or otherwise implemented in non-standard ways.
Orphaned Credentials
It’s also amazing how many large companies seem to ruin their relationship with users by altering login processes and getting it completely wrong. As I’ve been going through this migration and updating process I’ve found it incredible how many accounts have just vanished.
Granted, some of these accounts haven’t been used for a while, but surely these companies would prefer to keep these details rather than just obliterate a history with a customer? If an account has gone, it’s highly likely my order history followed it down the digital plughole.
I’ve encountered all manner of account migration issues as well. Filling out migration forms that are thoroughly broken despite going over instructions repeatedly. In some instances I’ve had to capitulate and contact their support departments for assistance. That is precisely what companies should do all they can to avoid. Support from their staff isn’t free, that costs time and money for them.
Over-posting Nightmares
This one is also incredibly stupid, and worryingly common. For some reason sites often need you to send other details along with your password resets. Asking for details like first name, last name, addresses or dates of birth, even when you aren’t changing them.
The problems here stems from man in the middle (MITM) attacks. Combined with some of the other issues described here accounts could be easily borked if the POST is changed during transit. Site developers should always require the absolute minimum of data in any request and response cycle. This is even more important when dealing with security tasks.
If it isn’t made obvious from the form layout, you can end up hitting the submit button and LastPass thinks it all went well. No doubt because the site returned a HTTP status code 200 OK response but the response detailed errors. Boom, you now have account details out of sync in your password vault with the details the server has. Your login is now broken for that site. The server still has your old password and LastPass has what it thinks is your new one.
Password Rules Roulette
This problem is completely inexcusable on the part of site developers. Enter a strong 25 character password, hit the submit button and then it errors telling you that the password needs to be at least 6 characters long.
Well, er … OK. I could try to figure out what your password rules are but this really should be taken care of by unit testing adequately. The login form should advise of any password rules before you allow the form to be posted. Or at least have the validation occur on the client side rather than waiting for the server to respond with an error and only then giving the user a clue about your password rules.
This also follows along to another problem, when a site decides to change their password rules and neglect the fact that all their legacy users have passwords that no longer match the new rules. I had one scenario where the login process allowed me in but the password change form rejected the old password as it didn’t match the new rules. Utterly ridiculous.
The obvious and simple solution to this is implement the new rules only on the New and Confirm New password boxes. Let the accounts slowly migrate from there and if it’s a more serious issue force a password change cycle on the next login.
Please Send Us Your Password … Again?
The other great chestnut is situations where you log into a site to manage your account. For some reason some sites seem to think that in order for you to manage your account it makes sense to ask for your password again. This is one of the core issues OAuth attempted to solve (not constantly sending passwords over the wire) , so asking us to do it twice is less than optimal. It doesn’t increase security in any meaningful way, in fact it doubles the risk of interception by definition.
Do you somehow not trust your own initial login result? You have already established the users identity during the initial login process, the only reason they can even get to the account management screen is precisely because you HAVE identified them? If you are feeling the need to do this maybe you have an issue elsewhere? If you’re concerned about long session maybe have an inactivity timeout on the server session? Most modern web servers have this ability baked in. Although I would argue that some aspects of security concerns have to be accepted by the user as well as by site developers.
Hints? LOL
Please provide a hint so you can remember your password …
h*jTyKj%^ZiCqwldlE!@R@xIL*A^vs&NqQ8^8tCT0C5uTF3$Ag
Er … seriously folks, hints are stupid at the best of times, don’t make them mandatory … ever.
I actually even encountered a local government site that believed that it was sufficient to show me the hint text rather than having any kind of real password reset/recovery process. Seriously, my jaw hit the floor at that one. Incredibly stupid. You have to email them to reset a password. Literally, unbelievable.
Another completely awful idea that some hint implementations use are often called “security questions”. You’re presented with a drop down of fixed questions which you choose from and then provide an answer to. This isn’t a good idea on any level. Some of these questions can appear pretty innocuous, but some of the answers could provide useful meta data should the databases be compromised and published by a nefarious party. I also think it would be safe to assume that these question and answer combinations aren’t encrypted and trivial for a hacker to piece together with data from other sources.
Emailing Passwords!?? Just … no
I’m amazed at how often I’ve seen this one. You change your password on a site to something nice and strong. Excellent. Then the nice developers email it back to you IN PLAIN TEXT to help you remember it. Guys, you just crapped a big one. You’ve shafted any security you think you have.
I recently had a scenario on a site I was building where during a license purchase a management account was auto generated. Since this involved the creation of a special kind of user account. The database also required a non-null password. In the background the server would auto generate a password, do the usual hashing and salting process and immediately throw the the plain text version away.
That left a user account with a password that noone had ever known. The email address associated with the new account was then sent a time-restricted, one-time-use tokenised reset link, not the password itself. The account was also marked to force a password reset. So the server would never accept the generated password anyway. If the token expired before the user attempted their first login, they could use the forgot password process to generate another token.
Case Sensitivity
Usernames and passwords are usually case sensitive meaning “hello” is not the same as “HELLO”, or even “Hello”. Upper and lower case characters are not equal, not are the strings that contain them, obvious for a developer, less so for a general user. I’ve had a number of scenarios where I’ve ended up with “split records” in LastPass. It seems that just prior to a login POST request some JavaScript on the page upper-cased my username prior to sending it over the wire to the server. This confused LastPass and instead of updating an existing record in my vault, it created a new one. This smacks of some odd code smell in the site code or database in my opinion, especially considering the username was an email address.
To Login or Not Login … Registration?
This is an odd scenario sometimes. The login and registration forms are on the same page/form. This is odd and confusing, certainly for a password manager. As I’ve been going through my stored credentials I’ve found many instances where the credentials were stored multiple times. Often with a sub-domain prefix, like “register.”. Account creation and logging an existing user into your site are two completely different tasks and shouldn’t be mixed. Adding pages/urls to sites for such core functions are hardly major tasks for developer. Having forms on pages with different actions is all well and good but shouldn’t make a developer “page shy”, go on, create another page, you know it makes sense!
Code Project!!!?? Noooo Surely not?
One of the password change processes that I was truly shocked at was Code Project’s. The password change form is in a stupid tool-tip attached to a piece of text styled like a link. When I entered the LastPass generated password I was informed that it was very strong. Not surprising. I was then greeted with an odd message about my current password being wrong. I was then also unable to click any links on the site and needed to ditch the tab to get the site working again. All very odd.
OAuth
OAuth was an attempt in getting login right. Whilst it isn’t an authentication mechanism per se, it attempts to federate login. Reducing the number of passwords a user has and also the number of times a password is sent over the wire. Anyone that has followed the history of OAuth knows that its inventor walked away from OAuth2 during the production of the specification for reasons too numerous and complex for this article.
Suffice to say we need some new standardisation efforts, badly.
I’ll Just Leave this here … yes this is from a real site …
… and no, you shouldn’t … ever.
The Future??
Firstly, I don’t consider myself a security expert by any stretch of the imagination. I’ll leave that moniker to the likes of Tavis Ormandy, Troy Hunt, Steve Gibson and Moxie Marlinspike. Having said that, I’m not a security noob either.
Everyone should also take their online security seriously. Developers having a huge responsibility to ensure we don’t make silly mistakes but users also have to accept some of the responsibility, that’s inescapable. Use a password manager, it’s really not difficult and empowers you to be more secure online.
The idea of a password protected system is now over 50 years old. There are lots of efforts to improve things such as OAuth and SQRL. OAuth has it’s own issues and none of the things on the immediate horizon appear to be the panacea we need.
One interesting idea I’ve encountered recently is the password-less email sign on that Medium uses. I was initially skeptical but having used it and thought about it, there is a lot of merit in that scenario. It doesn’t suit every situation at all but we need that kind of original thinking to tackle this problem.
So, what are you waiting for, go download a password manager … go on … off you pop.
