Passwords, password managers, and family life

Somehow, I always end up spending time writing about passwords when I even breach the subject on Twitter.

In this case, I’ve been asking around about password managers, as after many years with LastPass I want to reconsider if there is a better alternative, particularly as my needs have changed (or rather, are going to, in the not too distant future).

One of the thing that I’m looking for is a password manager that can generate diceware/xkcd-style passwords: a set of words in a certain language that are easy to say on (say) the phone, and type on systems where there is no password manager app. The reason for this is that there are a few places in which I need to be able to give the password to someone else who might not otherwise be trusted with the full password list. For instance the WiFi password for my apartment, or my mother’s house.

But it’s a bit more complicated than that. There are a number of situations where an account is not just an user. Or rather, you may want to allow h multiple users (people) to access the same account. Say for instance my energy provider’s dashboard. Or the phone provider. Or the online grocery shopping…

All of these things expect a single (billing) account, but they may rather be shared with a household than with a single individual. A few services do have a concept of a shared account, but very few do, and that makes less and less sense as the world progresses to such an everything-connected level.

I think it might be easy to figure out from the way I’ve been expressing this just above, but just to make sure not to leave “clues” rather than clear information that can be obviously be taken for public knowledge, I got to think about this because I have (finally, someone might say) found a soulmate. And while we don’t yet live together, I start to see the rough corners of these. We have not gotten to “What’s the Netflix password, again?” but I did end up changing the password to the account for Los Angeles transport card, to give her access, after setting it first with LastPass (we were visiting, and I added both of our TAP cards to the same account).

As I made clear earlier, part of this was a (minor) problem with my mother, too. But significantly less so: she never cared to have access to the power provider, phone company, and so on. Just as long as she had a copy of the invoices from time to time (which I solved by having a mailing list, which only the two of us subscribe to, as the contact address for all the services I use or used for the household in Italy).

Service providers take note: integrating with Google Drive or Dropbox so that the invoices get automatically added to a shared folder would be a lovely feature to have. And not just for households. I would love if it was easier to just have a copy of my invoices automatically added to, and indexed by, Google Drive.

But now, with a partner, it’s different. As the word implies, it’s a partnership, an equal standing. Once we will move in, we’ll share the expenses, and that means sharing the access to the accounts. Which means I don’t want to be the only one having the passwords. So I need a password manager that not only allows me to share the passwords easily, but also that allows her to use the passwords easily — which likely will translate to be able to read them off the phone, and type in a work computer’s incognito window (because she likely won’t be allowed to install the password manager on a work computer).

Which is why I’m looking for a new password manager: LastPass is actually fairly great when it comes to sharing passwords with other accounts. But it’s effectively useless when it comes to “typeable” passwords. Their “Make pronounceable” option is okay to make it easier to spell out, but I don’t want to have to use an eight-letters password to be able to type it easily, when I could just as easily use a three-words combination that is significantly stronger.

And while I could just use xkcdpass on my laptop and generate those shared passwords (which is what I did with my mother’s router), that does not really scale (it still keeps me as the gatekeeper), and it does not make the security usability for my SO. And it wouldn’t be fair to keep the password hygiene for me only.

Similarly, any solution that involves running personal infrastructure (servers, cron, git, whatever) is not an option: not only I’m increasingly not relying on it myself (I even gave up on running my own blog’s webapp!), but most of my family is not even slightly interested in figuring out how to do that. And I don’t blame the least, they have enough of their own things to care about.

If you have any suggestions for a new password manager, please do let me know. I think I may try 1Password next, if nothing else because I think Troy Hunt’s opinion is worth something, and if he backed 1Password, there has to be a reason.

Designing My Password Manager

So while at the (in my opinion excellent) Enigma, Tavis decided to nerd snipe me into thinking of how would I design a password manager. This because he knows (and disagree with) my present choice of using LastPass as my password manager of choice, despite the existence of a range of opensource password managers.

The main reason why I have discarded the choice of the available password managers is that, in my opinion, they all miss the main point of what a password manager should be: convenient. Password reuse is a problem because it’s more convenient than using dozens, maybe hundreds of different passwords for all the different services. An easy to use password manager is even more convenient than reusing password.

The first problem I found with effectively all of the opensource password managers I know of just use a single file-blob, and leave to you the problem of syncing it. The best I have seen was one software providing integration with Dropbox, Google Drive and ownCloud to sync the blob around, just as long as you don’t make conflicting changes on different devices. To me, the ability to make independent changes to services is actually a big requirement. This means that I would be using a file format that allows encrypting “per row”, both the keys and the values (because you don’t want to leak which accounts the user registered on, if the file is leaked). I would probably gravitate around something like the Bigtable format.

Another problem, which is present in Chrome SmartLock too, is the lack of support for what LastPass call “equivalent domains”. Due to many silly reasons, particularly if you travel a lot or if you live in different countries, you end up collecting a long list of websites using either separate domain names, or at least different TLDs. An example of this is Amazon, that use a constellation of different domains, but all share the same account management (except for Amazon Japan). A sillier example for this are Yelp and TripAdvisor, that decide to change your TLDs depending on the IP address you’re coming from, despite being the kind of services you would use particularly outside your usual country.

Admittedly, as Tavis suggested, these should be solved by the services themselves, using a single host for login/identity management. I do not expect this to happen any time soon. My previous proposal for this was defining equivalence as part as a well known configuration file (together with other improvements to password management). I now have some personal introspection questions about this, because I wonder if there is a privacy risk in sending requests to other domain to validate the reciprocal equivalence configurations. So I think I’ll leave this up for debate for later.

The next design bit is figuring out how should the password generator behave. We already have a number of good password generators of different types, including software implementations of diceware passwords (despite the site repeatedly telling you not to use computer random generators — to add to the inconvenience), and xkcdpass, that generate passwords that are easier to remember or at least to type. I think that a good password manager should allow for more than just the random-bunch-of-characters passwords that LastPass uses.

In particular, for me, I have a few websites for which I use passwords generated by xkcdpass, because I need to actually type in the password, rather than use the password manager autofill capabilities. This is the case of Sony and Nintendo accounts, that need to be typed from consoles, and of Telegram, as I need to type the password on my watch to receive messages there. Unfortunately implementing this is probably going to be an UX nightmare — one of the reason being the ability to select different wordlists. Non-English speakers are likely interested in using their own language for it. Or even the English speakers that are not afraid of other languages, and may decide to throw off a possible attacker anyway.

Ideally, the password generation settings would be stored on a domain-by-domain basis, so that if a certain website only allows numbers in its passcode, or it has a specific character limit, the same setting is used to generated a password if it’s ever breached. This may sound minor, but to me it would be so much more of a time (and frustration) saver, that it would easily become a killer feature.

But all of these idea fall to nothing without good, convenient, and trustworthy client implementations. Right now one of the many weak spots of LastPass is its Chrome extension (and Firefox too). A convenient password manager, though, ought to be able to integrate with the browser and, since it’s 2018 after all, with your phone. Unfortunately, here is where any opensource offering can’t really help as much as we would all like: it still relies (hugely) on trust. As far as I can tell, there is no way to make absolutely certain that the code of a Chrome extension on the Web Store, or of an Android app on either Play Store or F-Droid, corresponds exactly with a certain source distribution.

Don’t get me wrong, this is a real problem right now, with closed source extensions too. You need to trust the extension is not injecting malicious content in your webpage, or exfiltrating data out of your browser session. Earlier this year a widely used Chrome extension was reported as malicious, but it wasn’t until that was identified that it was removed from Chrome’s repository. At least I can have a (maybe underserved) trust in LogMeIn not to intentionally ruin their reputation by pushing actively malicious code to the Store. Would I say the same for a random single developer maintaining their widely used extension?

What this means to me is that building a good replacement for LastPass is not just a technical problem that needs to be solved by actively syncing with cloud storage services… it’s a problem of social trust, and that requires quite a bit of thought from many actors of the market: browser vendors, device manufacturers, and developers, which I’m not sure is currently happening. So I don’t hold my breath, and keep at compromises. I made mine with my threats in mind, you should make yours with what concerns you the most.

Password Advice

Somehow in all the posts I’ve written about 2FA and other security concerns, I have not really spent much time talking about passwords themselves, except to say that I believe in password managers and use LastPass.

The topic of what a strong password is always a tricky one, as the infosec professionals tend to divide themselves between those that subscribe to XKCD’s policy that raw password length is more important than composition, and those that keep insisting that dictionary attacks are the only thing worth protecting against, with some graduation between these two positions. I would say that in this case, the correct answer is somewhere in between.

There are indeed too many ways for a simple password to become just too easy. A password that requires to only have numbers (effectively, a PIN), is not only bad because of the small number of combination possible, but also because humans will lead to something they can memorize easily… a date. Or, if they are mathematicians, physics, chemists, or spent enough time in one of those disciplines, they’ll end up using one of the important constants.

Similarly, if only letters are allowed, lots of people will go for names, or nouns, or in general what we call “dictionary words” (which is confusing for a Scrabble player, because proper names are not considered part of the dictionary there). And once you ask for both letters and numbers, you just end up with leetspeak, which is pretty much a simple translation layer on top of the dictionary, which may extend the entropy a little bit, but not really in a significant way.

Effectively, the password composition rules, probably designed to stop people from using dictionary passwords, just slightly increased the size of the dictionary, but not really the safety of those passwords. Which is why most of everybody got very happy when NIST dropped the composition rules in their recommendations.

And as the Naked Security article points out, the recommendation focused a lot on the length of passwords. Because a longer password is a stronger password, if it’s not in the dictionary. And an easy way for it not to be in the dictionary is following XKCD’s approach and using a set of words, instead of a password. This is unfortunately not as scalable as we would like, as too many websites refuse strong passwords.

So what you need is to maximise the entropy extracted from your memorable passphrase so that it fits within the rules of the various websites. One of this is SuperGenPass, which I used to use myself. It applies a derivation function on top of the passphrase and the website domain do generate a new variable-length password. It sound cooler than it is, because unless you also keep a mapping between equivalent domains, and you keep in mind which website still has composition rules that require symbols and which don’t, and the length of the passwords for each, you now augmented your memorable passphrase with a constellation of parameters that are nearly impossible to remember. Including how many times the password was compromised.

On the other hand, SuperGenPass is still a better option that Manuel Blum (of CAPTCHA fame) tried to suggest to people during the last ENIGMA conference. Blum’s suggested method is, supposedly, a way to mentally apply a formula that collapses a “master password” and the name of a given site into a string of letters and numbers that can be used as a password. Most of the people in the known at the conference have been openly disagreeing with this option being even remotely friendly to users, not just for the requirement of being able to perform complex mental arithmetic (which I’m not fond of myself either, to be clear) but also because it does not solve any of the actual issues with memorizing passwords.

In particular, Blum’s method ends up generating passwords that are relatively short, bringing them within the reach of non-dictionary bruteforce attacks. They also do not the memory problem because in addition to the master password, and the formula, you would have to know the length of the password expected by each site. And in addition to that you need to have a “generation” number to use when the password gets invalidated (and the site refuses to let you keep or re-use the old password). It effectively only solve one issue: the fact that once your password is leaked, it’s very hard (if at all possible) to figure out the master password and thus compromise another website.

I’ll also add that I find Blum’s theatricals annoying. In the talk he goes on to say that when he’s asked for the password of a website like REI, he can say he does not remember whether he had an account with that website, but if he did, he can tell what the password is. This obviously can’t be true, given the limitations I listed above: you’d have to know the length of the password, and you would have to know the “generation” of it, if you have ever burnt through any because of compromised passwords.

Okay, so SuperGenPass and Blum’s methods are both useless. I have already said that my personal preference is to use LastPass (but you can use whichever password manager you want), and have it generate random passwords that are long enough, so that they can’t be bruteforced. You don’t have to remember a 40 characters password for each website, you just need a strong, long, memorable password for your manager, and from there, you can just have the new password stored in encrypted form. No derivation function, no need to remember how many times you changed password for a given site: in case of compromise, just go and generate a new 40 characters password.

But all of this just pushes the problem around, as the password manager, your system and some high-value accounts now need strong, long, memorable passwords, or even better passphrases. Your password manager, because that’s what protects every other password you have. You system, because you log in to it so many times a day (don’t you?), that you need something you can remember rather than something you can store. And valuable accounts, because some of them are too important to store in a single point of failure such as a password manager (my personal Google account password is not stored in LastPass — which is why I can actually trust it to unlock access to my LastPass account when I’m in countries I have not visited before).

This brings me to my personal suggestions on how to make such a memorable password in the first place. I don’t think you can do so with mental algorithms, or with a long word association game like Randall Munroe thinks — I never can remember the order of the four words in his example. I can tell you that’s the case because one of the throwaway accounts I shared with people used that as password, and I always had to look up xkcd for it. Oh and by the way, don’t ever use that string for a password for Internet-accessible services, because it’s high-up in the dictionaries of common passwords, together with love, sex, secret and god.

Instead, I like the option that my high school computer science teacher provided us with. Take a memorable quote, and mangle it, in a memorable way. His example, in Italian, would be to take the first line of a famous poetry from Giacomo Leopardi (La donzelletta vien dalla campagna), replace one word with another non-sense one, and another for an alternative, but similarly sounding word (La donzellotta vien dalla montagna — replacing “countryside” with “mountain”). This works well for a number of uses, and I have indeed been using it in various forms for many years, when long passphrases are needed.

You can extend this not only to poetry, but to quotes from movies or lines from songs. Even an unmodified phrase, such as the title of a book, can be much stronger than your average password, particularly if the book is not extremely famous and its title long. Even if there was a dictionary of book titles to go through, there are significantly more combinations of those that can be used than just single-words. The best thing, though, is to just mutate the title, quote or line in such a way that it’s not obvious. This also prevent an unexpected information leakage if you start whistling the song to yourself as you login on the system.

For instance, if you take Monty Python’s famous song, you can take the line

Always look at the bright side of life

This by itself, if looking at mindless bruteforce, is a fairly strong passphrase. Indeed a random online calculator of password “search space” (that at first sight appears to not spew nonsense, so I thought it made sense linking to it), reports the search space to 2.10×10e73 combinations. I actually think they are lowballing it, as they assume that you only need to search the space of the characters you’re composing from, but adding a digit to the passphrase does not extend its strength.

It’s the fact that you can use digits, that increases the number of combinations that brute forcing needs to go through. There is a caveat that if you don’t use numbers, your password will fall into a simpler search space, but that requires the attacker to either settle for a smaller search space to begin with, or target you and know you’re not using numbers. And in that case, shoulder-surfing is still probably easier.

As the website I linked shows, though, this number does not actually represent a password strength by itself. In addition to the fact that these are all normal English words, this is a phrase that can be found not only as a song title, or as a song line, but also as a common phrase in use. If an attacker is bruteforcing strong passphrases, a list of commonly used phrases would be the first part of a dictionary attack to use.

So what if you mutate some of the words?

Sometimes look at the dark side of death

This phrase is actually longer than the other, and the search space is reported as 1.52×10e77. But it truly is not that more complicated than the other if the attacker is focusing on strong passwords. Indeed, you’re just replacing a some of the words with either their antonyms, or with similar adverbs. Replacing “Always” with “Never”, “Sometimes”, “Often”, and so on means that the brute forcing just need to go and mutate some of the words separately with a list. It’s the passphrase equivalent to replacing ‘l’ with ‘1’ and ’t’ with ‘7’. If “password” is the first dictionary word tried, “p4s5w0rd” is not far down the list either.

Always look at the bright grail of Brian

This phrase has the same search space, but since you’re not replacing antonyms, but rather mashing up a famous Monty Python song with the title of the movie it came in and another effectively unrelated movie. You can still sing it to yourself in your head to the same tune, while at the same time it makes it nearly impossible for a mutating algorithm to think of doing it.

See, here is the trick for safe, strong, and memorable passwords: creativity. Because computers don’t have creativity and so they can’t figure out your passphrase that easily.

It gets even better if the passphrase is in a different language than the site it’s for. Even better, if the passphrase itself is actually composed in one language, but typed in another, with a 1:1 substitution of words that do not build a sensible phrase:

Sempre guarda a il splendente graal di Brian

The hard part with these two suggestions is that if you go too over the top with the substitutions, you end up with not memorizing your passphrase, and that makes things… complicated. But that’s really up to you to be careful with, and there’s no hard and fast rule to help you in that context.

Password Managers and U2F

Yet another blog post that starts with a tweet, or two. Even though I’m not by either trade or training clearly a security person, I have a vested interest in security as many of you know, and I have written (or ranted) a lot about passwords and security in the past. I have in particular argued for LastPass as a password manager, and at the same time for U2F security keys for additional security (as you can notice in this post as I added an Amazon link to one).

The other week, a side-by-side of the real PayPal login window and a phishing one that looked way too similar was posted, and I quoted the tweet asking PayPal why do they still not support U2F — technically PayPal does support 2-factors authentication, but that as far as I know that is only for US customers, and it is based on a physical OTP token.

After I tweeted that, someone who I would have expected to understand the problem better, argued that password managers and random passwords completely solve the phishing problem. I absolutely disagree and I started arguing it on Twitter, but the 140 characters limit makes it very difficult to provide good information, and particularly to refer to it later on. So here is the post.

The argument: you can’t phish a password you don’t know, and using password managers, you don’t have to (or have a way to) know that password. Works well in theory, but let’s see how that does not actually work.

Password managers allow you to generate a random, complex password (well, as long as the websites allow you to), and thanks to features such as autofill, you never actually get to see the password. This is good.

Unfortunately, there are plenty of cases in which you need to either see, read, or copy to clipboard the password. Even LastPass, which has, in my opinion, a well defined way to deal with “equivalent domains”, is not perfect: not all Amazon websites are grouped together, for instance. While they do provide an easy way to add more domains to the list of equivalency, it does mean I have about 30 of them customised for my own account right now.

What this means is that users are actually trained to the idea that sometimes the autofill won’t work because the domain is just not in the right list. And even when it is, sometimes the form has changed, and autofill just does not work. I have seen plenty of those situations myself. And so, even though you may not know the password, phishing works if it convinces you that the reason why autofill is not working is not because the site is malicious, but just because the password manager is broken/not working as intended/whatever else.

This becomes even more likely when you’re using one of the more “open” password managers. Many think LastPass is bad, not just because they store your password server-side (encrypted) but also because it interacts directly with the browser. After all, the whole point of the LostPass vulnerability was that UI is hard. So the replacements for geeks who want to be even more secure usually is a separate app that requires you to copy-paste your password from it to the browser. And in that case, you may not know the password, but you can still be phished.

If you want to make the situation even more ridiculous, go back to read my musings on bank security. My current bank (and one of my former ones) explicitly disallow you from using either autofill or copy-paste. Worse they ask you to fill in parts of your password, e.g. “the 2nd, 4th, 12th character of your password” — so you either end up having to use a mnemonic password or you have to look at your password manager and count. And that is very easily phisable. Should I point out that they insist that this is done to reduce chances of phishing?

I have proposed some time ago a more secure way to handle equivalent domains, in which websites can feed back information to the password managers on who’s what. There is some support for things like this on iOS at least, where I think the website can declare which apps are allowed to take over links to themselves. But as far as I know, even now that SmartLock is a thing, Chrome/Android do not support anything like that. Nor does LastPass. I’m sad.

Let me have even more fun about password managers, U2F, and feel okay with having a huge Amazon link at the top of this post:

//platform.twitter.com/widgets.js

Edit: full report is available for those who just don’t believe the infographic.

This is not news, I have written about this over two years ago after U2F keys were announced publicly — I have been using one before that, that is not mystery clearly. Indeed, unlike autofill and copy-paste, U2F identification does not involve interaction with the user-person, but is rather tied to the website’s own identification, which means it can’t be phished.

Phishing, as described in the NilePhish case above, applies just as equally to SMS, Authenticator apps and push-notifications, because what the user may perceive is just a little bit more delay. It’s not impossible, though a bit complicated, for a “sophisticated” (or well-motivated) attacker to just render the same exact page as the original site, defeating all those security theatre measure such as login-request IDs, custom avatars and custom phrases — or systems that ask you the 4th, 9th and 15th characters of your password.

User certificates, whether as a file enrolled in the operating system or on a smartcard, are of course an even stronger protection than U2F, but having used them, they are not really that friendly. That’s a topic for another day, though.

LastPass got hacked, I’m still okay with it

So LastPass was compromised and so they report. I’m sure there are plenty of smug geeks out there, happy about users being compromised. I thought that this is the right time to remind people why I’m a LastPass user and will stay a LastPass user even after this.

The first part is a matter of trust in the technology. If I did not trust LastPass enough to not have easy access to the decrypted content, I wouldn’t be using it to begin with. Since I do not trust the LastPass operators, even in the case the encrypted vault were compromised (and they say they weren’t), I wouldn’t be worrying too much.

On the other hand I followed the obvious course of not only changing the master password, and change the important passwords just to be paranoid. This is actually one good side of LastPass — changing the passwords that are really important is very easy as they instrument the browser, so Facebook, Twitter, Amazon, PayPal, … are one click away from a new, strong password.

Once again, the main reason why I suggest tools such as LastPass (and I like LastPass, but that’s just preference) is that they are easy to use, and easy to use means people will use them. Making tools that are perfectly secure in theory but very hard to use just means people will not use them, full stop. A client-side certificate is much more secure than a password, but at the same time procuring one and using it properly is non-trivial so in my experience only a handful of services use that — I know of a couple of banks in Italy, and of course StartSSL and similar providers.

The problem with offline services is that, for the most part, don’t allow good access while from phones, for instance. So you end up choosing, for things you use often from the phone, memorable passwords. But memorable passwords are usually fairly easy to crack, unless you use known methods and long password — although at least it’s not the case, like I read on Arse^H recently, that since we know the md5 hash for “mom”, any password with that string anywhere is weakened.

Let’s take an example away from the password vaults. In Ireland (and I assume UK simply because the local systems are essentially the same in many aspects), banks have this bollocks idea that is more secure to ask for some of the characters of a password rather than a full password. I think this is a remnant of old bank teller protocols, as I remember reading about that in The Art of Deception (good read, by the way.)

While in theory picking a random part of the password means a phishing attempt would never get the full password, and thus won’t be able to access the bank’s website unless they are very lucky and get exactly the same three indexes over and over, it is a frustrating experience.

My first bank, AIB, used a five-digits PIN, and then select three digits out of it when I log in, which is not really too difficult to memorize. On the other hand, on their mobile app they decided that the right way to enter the numbers is by using drop-down boxes (sigh.) My current bank, Ulster Bank/RBS, uses a four digits pin, plus a variable length password, which I generated through LastPass as 20 characters, before realizing how bad that is, because it means I now get asked three random digits off the four… and three random characters of the 20.

Let that sink in a moment: they’ll ask me for the second, fifth and sixteenth character of a twenty characters randomly generated password. So no auto-fill, no copy-paste, no password management software assisted login. Of course most people here would just not bother and go with a simple password they can remember. Probably made of multiple words of the same length (four letters? five?) so that it becomes easy to count which one is the first character of the fourth word (sixteenth character of the password.) Is it any more secure?

I think I’ll write a separate blog post about banks apps and website security mis-practices because it’s going to be a long topic and one I want to write down properly so I can forward it to my bank contacts, even though it won’t help with anything.

Once again, my opinion is that any time you make security a complicated feature, you’re actually worsening the practical security, even if your ideas are supposed to improve the theoretical one. And that includes insisting on the perfect solution for password storage.

Why is U2F better than OTP?

It is not really obvious to many people how U2F is better than OTP for two-factor authentication; in particular I’ve seen it compared with full-blown smartcard-based authentication, and I think that’s a bad comparison to do.

Indeed, since the Security Key is not protected by a PIN, and the NEO-n is designed to be semi-permanently attached to a laptop or desktop. At first this seems pretty insecure, as secure as storing the authorization straight into the computer, but it’s not the case.

But let’s start from the target users: the Security Key is not designed to replace the pure-paranoia security devices such as 16Kibit-per-key smartcards, but rather the on-phone or by-sms OTPs two-factor authenticators, those that use the Google Authenticator or other opensource implementations or that are configured to receive SMS.

Why replacing those? At first sight they all sound like perfectly good idea, what’s to be gained to replace them? Well, there are plenty of things, the first of being the user friendliness of this concept. I know it’s an overuse metaphor, but I do actually consider features on whether my mother would be able to use them or not — she’s not a stupid person and can use a computer mostly just fine, but adding any on more procedures is something that would frustrate her quite a bit.

So either having to open an application and figure out which of many codes to use at one time, or having to receive an SMS and then re-type the code would be not something she’d be happy with. Even more so because she does not have a smartphone, and she does not keep her phone on all the time, as she does not want to be bothered by people. Which makes both the Authenticator and SMS ways not a good choice — and let’s not try to suggests that there are way to not be available on the phone without turning it off, it would be more to learn that she does not care about.

Similar to the “phone-is-not-connected” problem, but for me rather than my mother, is the “wrong-country-for-the-phone” problem: I travel a lot, this year aiming for over a hundred days on the road, and there are very few countries in which I keep my Irish phone number available – namely Italy and the UK, where Three is available and I don’t pay roaming, when the roaming system works… last time I’ve been to London the roaming system was not working – in the others, including the US which is obviously my main destination, I have a local SIM card so I can use data and calls. This means that if my 2FA setup sends an SMS on the Irish number, I won’t receive it easily.

Admittedly, an alternative way to do this would be for me to buy a cheap featurephone, so that instead of losing access to that SIM, I can at least receive calls/SMS.

This is not only a theoretical. I have been at two conferences already (USENIX LISA 13, and Percona MySQL Conference 2014) and realized I cut myself out of my LinkedIn account: the connection comes from a completely different country than usual (US rather than Ireland) and it requires reauthentication… but it was configured to send the SMS to my Irish phone, which I had no access to. Given that at conferences is when you meet people you may want to look up on LinkedIn, it’s quite inconvenient — luckily the authentication on the phone persists.

The authenticator apps are definitely more reliable than that when you travel, but they also come with their set of problems. Beside the not complete coverage of services (LinkedIn noted above for instance does not support authenticator apps), which is going to be a problem for U2F as well, at least at the beginning, neither Google’s or Fedora’s authenticator app allow you to take a backup of the private keys used for OTP authentication, which means that when you change your phone you’ll have to replace, one by one, the OTP generation parameters. For some services such as Gandi, there is also no way to have a backup code, so if you happen to lose, break, or reset your phone without disabling the second factor auth, you’re now in trouble.

Then there are a few more technical problems; HOTP, similarly to other OTP implementations, relies on shared state between the generator and the validator: a counter of how many times the code was generated. The client will increase it with every generation, the server should only increase it after a successful authentication. Even discounting bugs on the server side, a malicious actor whose intent is to lock you out can just make sure to generate enough codes on your device that the server will not look ahead enough to find the valid code.

TOTP instead relies on synchronization of time between server and generator which is a much safer assumption. Unfortunately, this also means you have a limited amount of time to type your code, which is tricky for many people who’re not used to type quickly — Luca, for instance.

There is one more problem with both implementations: they rely on the user to choose the right entry and in the list and copy the right OTP value. This means you can still phish an user to type in an OTP and use it to authenticate against the service: 2FA is a protection against third parties gaining access to your account by having your password posted online rather than a protection against phishing.

U2F helps for this, as it lets the browser to handshake with the service before providing the current token to authenticate the access. Sure there might still be gaps on is implementation and since I have not studied it in depth I’m not going to vouch for it to be untouchable, but I trust the people who worked on it and I feel safer with it than I would be with a simple OTP.

My thoughts on the Self-Hosting Solution

You probably noticed that in the (frequent) posts talking about security and passwords lately, I keep suggesting LastPass as a password manager. This is the manager that I use myself, and the reason why I came to this one is multi-faceted, but essentially I’m suggesting you use a tool that does not make it more inconvenient to maintain proper password hygiene. Because yes, you should be using different passwords, with a combination of letters, numbers and symbols, but if you have to come up with a new one every time, then things are going to be difficult and you’ll just decide to use the same password over and over.

Or you’ll use a method for having “unique” passwords that are actually comprised of a fixed part and a mobile one (which is what I used for the longest time). And let’s be clear, using the same base password suffixed with the name of the site you’re signing up for is not a protection at all, the moment more than one of your passwords is discovered.

So convenience being important, because inconvenience just leads to bad security hygiene, LastPass delivers on what I need: it has autofill, so I don’t have to open a terminal and run sgeps (like I used to be) to get the password out of the store, it generates the password in the browser, so I don’t have to open a terminal and run pwgen, it runs on my cellphone, so I can use it to fetch the password to type somewhere else, and it even auto-fills my passwords in the Android apps, so I don’t have to use a simple password when dealing with some random website that then patches to an app on my phone. But it also has a few good “security conveniences”: you can re-encode your Vault on a new master password, you can use a proper OTP pad or a 2FA device to protect it further, and they have some extras such as letting you know if the email you use across services are involved in an account breach.

This does not mean there are no other good password management tools, I know the name of plenty, but I just looked for one that had the features I cared about, and I went with it. I’m happy with LastPass right now. Yes, I need to trust the company and their code a fair bit, but I don’t think that just being open source would gain me more trust. Being open source and audited for a long time, sure, but I don’t think either way it’s a dealbreaker for me. I mean Chrome itself has a password manager, it just feels not suitable for me (no generation, no obvious way to inspect the data from mobile, sometimes bad collation of URLs, and as far as I know no way to change the sync encryption password). It also requires me to have access to my Google account to get that data.

But the interesting part is how geeks will quickly suggest to just roll your own, be it using some open-source password manager, requiring an external sync system (I did that for sgeps, but it’s tied to a single GPG key, so it’s not easy for me having two different hardware smartcards), or even your own sync infrastructure. And this is what I really can’t stand as an answer, because it solves absolutely nothing. Jürgen called it cynical last year, but I think it’s even worse than that, it’s hypocritical.

Roll-your-own or host-your-own are, first of all, not going to be options for the people who have no intention to learn how computer systems work — and I can’t blame them, I don’t want to know how my fridge or dishwasher work, I just want them working. People don’t care to learn that you can get file A on computer B, but then if you change it on both while offline you’ll have collisions, so now you lost one of the two changes. They either have no time, or just no interest or (but I don’t think that happens often) no skill to understand that. And it’s not just the random young adult that ends up registering on xtube because they have no idea what it means. Jeremy Clarkson had to learn the hard way what it means to publish your bank details to the world.

But I think it’s more important to think of the amount of people who think that they have the skills and the time, and then are found lacking one or both of them. Who do you think can protect your content (and passwords) better? A big company with entire teams dedicated to security, or an average 16 years old guy who think he can run the website’s forum? — The reference here is to myself: back in 20002001 I used to be the forum admin for an Italian gaming community. We got hacked, multiple times, and every time it was for me a new discovery of what security is. At the time third-party forum hosting was reserved to paying customers, and the results have probably been terrible. My personal admin password matched one of my email addresses up until last week and I know for a fact that at least one group of people got access to the password database, where they were stored in plain text.

Yes it is true, targets such as Adobe will lead to many more valid email addresses and password hashes than your average forum, but as the “fake” 5M accounts should have shown you, targeting enough small fishes can lead to just about the same results, if not even better, as you may be lucky and stumble across two passwords for the same account, which allows you to overcome the above-mentioned similar-but-different passwords strategy. Indeed, as I noted in my previous post, Comic Book Database admitted to be the source of part of that dump, and it lists at least four thousand public users (contributors). Other sites such as MythTV Talk or PoliceAuctions.com, both also involved, have no such statement ether.

This is not just a matter of the security of the code itself, so the “many eyes” answer does not apply. It is very well possible to have a screw up with an open source program as well, if it’s misconfigured, or if a vulnerable version don’t get updated in time because the admin just has no time. You see that all the time with WordPress and its security issues. Indeed, the reason why I don’t migrate my blog to WordPress is that I won’t ever have enough time for it.

I have seen people, geeks and non-geeks both, taking the easy way out too many times, blaming Apple for the nude celebrity pictures or Google for the five million accounts. It’s a safe story: “the big guys don’t know better”, “you just should keep it off the Internet”, “you should run your own!” At the end of the day, both turned out to be collections, assembled from many small cuts, either targeted or not, in part due to people’s bad password hygiene (or operational security if you prefer a more geek term), and in part due to the fact that nothing is perfect.

Make password management better

When I posted my previous post on accounts on Google+ I received a very interesting suggestions that I would like to bring to the attention of more people. Andrew Cooks pointed out that what LastPass (and other password managers) really need, is a way to specify the password policy programmatically, rather than crowdsourcing this data as LastPass is doing right now.

There are already a number of cross-product specifications of fixed-path files used to describe parameters such as robots.txt or sitemap.xml. While cleaning up my blog’s image serving I also found that there is a rules.abe file used by the NoScript extension for Firefox. In this optic, adding a new password-policy.txt file to define some parameters for the password policy of the website.

Things like the minimum and maximum length of the password, which characters are allowed, whether it is case sensitive or not. These are important information that all the password managers need to know, and as I said not all websites make it clear to the user either. I’ll recount two different horror stories, one in the past and one more recent, that show how that is important.

The first story is from probably almost ten years ago or so. I registered with the Italian postal service. I selected a “strong” (not really) password, 11 characters long. It was not really dictionary-based, but it was close enough if you knew my passwords’ pattern. Anyway, I liked the idea of having the long password. I signed up for it, I logged back in, everything worked. Until a few months later, when I decided I wanted to fetch that particular mailbox from GMail — yes, the Italian postal service gives you an email box, no I don’t want to comment further on that.

What happens is that the moment I tried to set up the mail fetching on GMail, it kept failing authentication. And I’m sure I used the right password that I’ve insisted using up to that point! I log in on the website just fine with it, so what gives? A quick check at the password that my browser (I think Firefox at the time) think is the password of that website shows me the truth: the password I’ve been using to log in does not match the one I tried to use from GMail: the last character is not there. Some further inspection of the postal service website shows that the password fields, both in the password change and login (and I assumed at the time the registration page for obvious reasons), set a maxlength value to 10. So of course, as long as I typed or pasted the password in the field, the way I typed it when I registered, it worked perfectly fine, but when I tried to login out of band (through POP3) it used the password as I intended, and failed.

A similar, more recent story happened with LastMinute. I went to change my password, in my recent spree of updating all my passwords, even for accounts not in use (mostly to make sure that they don’t get leaked and allow people to do crazy stuff to me). My default password generator on LastPass is set to generate 32-characters passwords. But that did not work for LastMinute, or rather, it appeared to. It let me change my password just fine, but when I tried logging back in, well, it did not work. Yes, this is the reason that I try to log back in after generating the password, I’ve seen that happening before. In this case, the problem was to be found in the length of the password.

But just having a proper range for the password length wouldn’t be enough. Other details that would be useful are for instance the allowed symbols; I have found that sometimes I need to either generate a number of passwords to find one that does not have one of the disallowed symbols but still has some, or give up on the symbols altogether and ask LastPass to generate only letters and numbers. Or having a way to tell that the password is case sensitive or not — because if it is not, what I do is disable the generation of one set of letters, so that it randomises them better.

But there is more metadata that could be of use there — things like which domains should the password be used with, for instance. Right now LastPass has a (limited) predefined list of equivalent domains, and hostnames that need to match exactly (so that bugs.gentoo.org and forums.gentoo.org are given different passwords), while it’s up to you to build the rest of the database. Even for the Amazon domains, the list is not comprehensive and I had to add quite a few when logging in the Italian and UK stores.

Of course if you were just to tell that your website uses the same password as, say, google.com, you’re going to have a problem. What you need is a reciprocal indication that both sites think the other is equivalent, basically serving the same identical file. This makes the implementation a bit more complex but it should not be too difficult as those kind of sites tend to at least share robots.txt (okay, not in the case of Amazon), so distributing one more file should not be that difficult.

I’m not sure if anybody is going to work on implementing this, or writing a proper specification for it, rather than a vague rant on a blog, but hope can’t die, right?

How to analyze a dump of usernames

There has been some noise around a leak of users/passwords pairs which somehow panicked people into thinking it was coming from a particular provider. Since it seems most people have not even tried looking at the account information available, I’d like to point out some ways that could have helped avoiding the panic, if only the reporters cared. It also fits nicely into my previous notes on accounts’ churn.

But before proceeding let me make one thing straight: this post contains no information that is not available to the public and bears no relation to my daily work for my employer. Just wanted to make that clear. Edit: for the official response, please see this blog post of Google’s Security blog.

To begin the analysis you need a copy of the list of usernames; Italian blogger Paolo Attivissimo linked to it in his post but I’m not going to do so. Especially since it’s likely to become obsolete soon, and might not be liked by many. The archive is a compressed list of usernames without passwords or password hashes. At first, it seems to contain almost exclusively gmail.com addresses — in truth there are more addresses but it probably does not hit the news as much to say that there are some 5 million addresses from some thousand domains.

Let’s first try to extract real email addresses from the file, which I’ll call rawsource.txt — yes it does not match the name of the actual source file out there but I would rather avoid the search requests finding this post from the filename.

$ fgrep @ rawsource.txt > source-addresses.txt

This removes some two thousands lines that were not valid addresses — turns out that the file actually contains some passwords, so let’s process it a little more to get a bigger sample of valid addresses:

$ sed -i -e 's:|.*::' source-addresses.txt

This should make the next command give us a better estimate of the content:

$ sed -n -e 's:.*@::p' source-addresses.txt | sort | uniq -c | sort -n
[snip]
  238 gmail.com.au
256 gmail.com.br
338 gmail.com.vn
608 gmail.com777
123215 yandex.ru
4800129 gmail.com

So as we were saying earlier there are more than just Google accounts in this. A good chunk of them are on Yandex, but if you look at the outlier in the list there are plenty of other domains including Yahoo. Let’s just filter away the four thousands addresses using either broken domains or outlier domains and instead focus on these three providers:

$ egrep '@(gmail.com|yahoo.com|yandex.ru)$' source-addresses.txt > good-addresses.txt

Now things get more interesting, because to proceed to the next step you have to know how email servers and services work. For these three providers, and many default setups for postfix and similar, the local part of the address (everything before the @ sign) can contain a + sign, when that is found, the local part is split into user and extension, so that mail to nospam+noreally would be sent to the user nospam. Servers generally ignore the extension altogether, but you can use it to either register multiple accounts on the same mailbox (like I do for PayPal, IKEA, Sony, …) or to filter the received mail on different folders. I know some people who think they can absolutely identify the source of spam this way — I’m a bit more skeptical, if I was a spammer I would be dropping the extension altogether. Only some very die-hard Unix fans would not allow inbound email without an extension. Especially since I know plenty of services that don’t accept email addresses with + in them.

Since this is not very well known, there are going to be very few email addresses using this feature, but that’s still good because it limits the amount of data to crawl through. Finding a pattern within 5M addresses is going to take a while, finding one in 4k is much easier:

$ egrep '.*+.*@.*' good-addresses.txt | sed -e '/.*@.*@.*/d' > experts-addresses.txt

The second command filters out some false positives due to two addresses being on the same line; the results from the source file I started with is 3964 addresses. Now we’re talking. Let’s extract the extensions from those good addresses:

$ sed -e 's:.*+(.*)@.*:1:' experts-addresses.txt | sort > extensions.txt

The first obvious thing you can do is figure out if there are duplicates. While the single extensions are probably interesting too, finding a pattern is easier if you have people using the same extension, especially since there aren’t that many. So let’s see which extensions are common:

$ sed -e 's:.*+(.*)@.*:1:' experts-addresses.txt | sort | uniq -c -d | sort -n > common-extensions.txt

An obvious quick look look of that shows that a good chunk of the extensions (the last line in the generated file) used were referencing xtube – which you may or may not know as a porn website – reminding me of the YouPorn-related leak two and a half years ago. Scouring through the list of extensions, it’s also easy to spot the words “porn” and “porno”, and even “nudeceleb” making the list probably quite up to date.

Just looking at the list of extensions shows a few patterns. Things like friendster, comicbookdb (and variants like comics, comicdb, …) and then daz (dazstudio), and mythtv. As RT points out it might very well be phishing attempts, but it is also well possible that some of those smaller sites such as comicbookdb were breached and people just used the same passwords for their GMail address as the services (I used to, too!), which is why I think mandatory registrations are evil.

The final automatic interesting discovery you can make involves checking for full domains in the extensions themselves:

fgrep . extensions.txt | sort -u

This will give you which extensions include a dot in the name, many of which are actually proper site domains: xtube figures again, and so does comicbookdb, friendster, mythtvtalk, dax3d, s2games, policeauctions, itickets and many others.

What does this all tell me? I think what happens is that this list was compiled with breaches of different small websites that wouldn’t make a headline (and that most likely did not report to their users!), plus some general phishing. Lots of the passwords that have been confirmed as valid most likely come from people not using different passwords across websites. This breach is fixed like every other before it: stop using the same password across different websites, start using something like LastPass, and use 2 Factor Authentication everywhere is possible.

Account churn

In my latest post I singled out ne of the worst security experiences I’ve had with a service, but that is by far not the only bad experience I had. Indeed, given that I’ve been actively hunting down my old accounts and tried to get my hands on them, I can tell you that I have plenty of material to fill books with bad examples.

First of all, there is the problem of migrating the email addresses. For the longest time I’ve been using my GMail address to register everywhere, but then I decided to migrate to use my own domain (especially since Gandi supports two factor authentication, which makes it much safer). Unfortunately that means that not only I have a bunch of accounts still on the old email address, but I also have duplicate accounts.

Duplicate accounts become even more tricky when you consider that I had my own company, which meant I had double accounts for things that did not allow me to ship sometimes with a VAT ID attached, and sometimes not. Sometimes I could close the accounts (once I dropped the VAT ID), and sometimes I couldn’t, so a good deal of them are still out there.

FInally, there are the services that are available in multiple countries but with country-specific accounts. Which, don’t be mistaken, does not mean that every country has its own account database! It simply means that a given account is assigned to a country and does not work on any other. In most cases you cannot even migrate your account across countries. This is the case, for instance, of OVH, and why I moved to Gandi but also of PayPal (in which the billing address is tied to the country of the account and can’t be changed), IKEA and -PSN- Sony Online Entertainment. The end result is that I have duplicated (or even triplicated) accounts to cover the fact I have lived in multiple countries by now.

Also, it turns out that I completely forgot how many services I registered to over the years. Yes I have the passwords as stored by Chrome, but that’s not a comprehensive list as some of the most critical passwords have never been saved there (such as my bank’s password), plus some websites I have never used in Chrome, and at some point I had it clean the history of passwords and start from scratch. Some of the passwords have been saved in sgeps so I could look them up there, but even those are not a complete list. I ended up looking in my old email content to figure out which accounts I forgot having. The results have been fun.

But what about the grievances? Some of the accounts I wanted to gain access to again ended up being blocked or deleted, I’m surprised by the amount of services that either were killed, or moved around. At least three ebook stores I used are now gone, two of which absorbed by Kobo, while Marks & Spencer refused to recognize my email as valid, I assume they at some point reset their user database or something. Some of the hotel loyalty programs I signed up before and used once or twice disappeared, or were renamed/merged into something else. Not a huge deal but it makes account management a fun problem.

Then there are the accounts that got their password invalidated in the mean time, so even if I have a copy of it, it’s useless. Given that some accounts I had not logged into for years, that’s fair to happen: between leaks, heartbleed, and the overdue changes in best practices for password storage, I am more bothered by the services that did not invalidate my password in the mean time. But then again, there are different ways to deal with it. Some services when trying to login with the previous password point out that it’s no long valid and proceed with the same Forgotten password request workflow. Others will send you the password by email in plain text.

One quite egregious case happened with an Italian electronics shop, one of the first online-only stores I know of in Italy. Somehow, I knew that the account was still active, mostly because I could see their newsletter in the spam folder of my GMail account. So I went and asked for the password back, to change the address and stop the newsletter too (given I don’t live in Italy any longer), they sent me back the userid and password in cleartext. They reset their passwords in the mean time, and the default password became my Italian tax ID. Not very safe, if I were to know the user id of anyone else, knowing their tax ID is easy, as it can be calculated based on a few personal, but not so secret, details (full name, sex, date and city of birth).

But there is something worse than unannounced password resets. The dance of generating a new password. I have now the impression that it’s a minority of services that actually allow you to use whichever password you want. Lots of the services I have changed password for between last night and today required me to disable the non-alphanumeric symbols, because either they don’t support any non-alphanumeric character, or they only support a subset that LastPass does not let you select.

But this is not as bothersome as the length limitation of passwords. Most sites will be happy to tell you that they require a minimum of 6 or 8 characters for your password — few will tell you upfront the maximum length of a password. And very few of those that won’t tell you right away will fix the mistake by telling you when the password is too long, how long it can be. I even found sites that simply error out on you when you try to use a password that is not valid, and decide to invalidate both your old and temporary passwords, while not accepting the new one. It’s a serious pain.

Finally, I’ve enabled 2FA for as many services as I could; some of it is particularly bothersome (LinkedIn, I’ll probably write more about that), but at least it’s an extra safety. Unfortunately, I still find it extremely bothersome neither Google Authenticator nor RedHat’s FreeOTP (last time I tried) supported backing up the private keys of the configured OTPs. Since I switched between three phones in the past three months, I could use some help when having to re-enroll my OTP generators — I upgraded my phone, then had to downgrade because I broke the screen of the new one.