Tag: Password Managers

My Password Manager Needs a Virtual USB Keyboard

You may remember that a couple of years ago, Tavis convinced me to write down an idea of how my ideal password manager would look like. Later the same year I also migrated from LastPass to 1Password, because it made family sharing easier, but like before this was a set of different compromises.

More recently, I came to realise that there’s one component that my password manager needs, and I really wish I could convince the folks at 1Password to implement it: a virtual USB keyboard on a stick. Let me try to explain, because this already generated negative reactions on Twitter, including from people who didn’t wait to understand how it all fits together first.

Let me start with a note: I have been thinking in my idea of something like this for a long while, but I have not been able to figure out in my mind how to make it safe and secure, which means I don’t recommend to just use my random idea for this all. I then found out that someone else already came up with pretty much the same idea and did some of the legwork to get this to work, back in 2014… but nothing came of it.

What this suggests, is to have some kind of USB hardware token that can be paired with a phone, say over bluetooth, and be instructed to “type out” text via USB HID. Basically a “remote keyboard” controlled with the phone. Why? Let’s take a step back and see.

Among security professionals, there’s a general agreement that the best way to have safe passwords is to use unique, generated passwords and have them saved somewhere. There’s difference in the grade of security you need — so while I do use and recommend a password manager, practically speaking, having a “passwords notebook” in a safe place is pretty much as good, particularly for less technophile people. You may disagree on this but if so please move on, as this whole post is predicated on wanting to use password managers.

Sometimes, though, you may need a password for something that cannot use a password manager. The example that comes to my mind is trying to log in to PlayStation Network on my PS3/PS4, but there’s a number of other cases like that in addition to gaming consoles, such as printers/scanners, cameras (my Sony A7 need to log in to the Sony Online account to update the onboard apps, no kidding!), and computers that are just being reinstalled.

In these cases, you end up making a choice: for something you may have to personally type out more often than not, it’s probably easier to use a so-called “memorable password”, which is also commonly (but not quite correctly) called a Diceware password. Or, again alternatively, a 936 password. You may remember that I prefer a different form of memorable passwords, when it comes to passwords you need to repeatedly type out yourself very often (such as the manager’s master password, or a work access password), but for passwords that you can generate, store in a manager, and just seldomly type out, 936-style passwords are definitely the way to go in my view.

In certain cases, though, you can’t easily do this either. If I remember this correctly, Sony enforced passwords to have digits and symbols, and not repeat the same digit more than a certain amount of times, which makes diceware passwords not really usable for that either. So instead you get a generated password you need to spend a lot of time reading and typing — and in many cases, having to do that with on-screen keyboards that are hard to use. I often time out on my 1Password screen while doing so, and need to re-login, which is a very frustrating experience in and by itself.

But it’s not the only case where this is a problem. When you set up a computer for the first time, no matter what the operating system, you’ll most likely find yourself having to set up your password manager. In the case of 1Password, to do so you need the secret key that is stored… in 1Password itself (or you may have printed out and put in the safe in my case). But typing that secret key is frustrating — being able to just “send” it to the computer would make it a significantly easier task.

And speaking again of reinstalling computers, Windows BitLocker users will likely have their backup key connected to their Microsoft account so that they can quickly recover the key if something goes wrong. Nothing of course stops you from saving the same key in 1Password, but… wouldn’t it be nice to be able to just ask 1Password to type it for you on the computer you just finished reinstalling?

There’s one final case for which is this is useful, and that’s going to be a bit controversial: using the password on a shared PC where you don’t want to log in with your password manager. I can already hear the complaints that you should never log in from a shared, untrusted PC and that’s a recipe for disaster. And I would agree, except that sometimes you just have to do that. A long time ago, I found myself using a shared computer in a hotel to download and print a ticket, because… well, it was a whole lot of multiple failures why I had to do it, but it was still required. Of course I went on and changed the password right after, but it also made me think.

When using shared computers, either in a lounge, hotel, Internet cafe (are they still a thing), or anything like that, you need to see the password, which makes it susceptible to shoulder surfing. Again, it would be nice to have the ability to type the password in with a simpler device.

Now, the biggest complain I have received to this suggestion is that this is complex, increases surface of attack by targeting the dongle, and instead the devices should be properly fixed not to need any of this. All of that is correct, but it’s also trying to fight reality. Sony is not going to go and fix the PlayStation 3, particularly not now that the PS5 got announced and revealed. And some of these cases cannot be fixed: you don’t really have much of an option for the BitLocker key, aside from reading it off your Microsoft account page and typing it on a keyboard.

I agree that device login should be improved. Facebook Portal uses a device code that you need to type in on a computer or phone that is already logged in to your account. I find this particular login system much easier than typing the password with a gamepad that Sony insists on, and I’m not saying that because Facebook is my employer, but because it just makes sense.

Of course to make this option viable, you do need quite a few critical bits to be done right:

  • The dongle needs to be passive, the user needs to request a password typed out explicitly. No touch sensitive area on the dongle to type out in the style of a YubiKey. This is extremely important, as a compromise of the device should not allow any password to be compromised.
  • The user should be explicit on requesting the “type out”. On a manager like 1Password, an explicit refresh of the biometric login is likely warranted. It would be way too easy to exfiltrate a lot of passwords in a short time otherwise!
  • The password should not be sent in (an equivalent of) cleartext between the phone and the device. I honestly don’t remember what the current state of the art of Bluetooth encryption is, but it might not be enough to use the BT encryption itself.
  • There needs defense against tampering, which means not letting the dongle’s firmware to be rewritten directly with the same HID connection that is used for type out. Since the whole point is to make it safe to use a manager-stored password on an untrusted device, having firmware flashing access would make it too easy to tamper with.
    • While I’m not a cryptography or integrity expert, my first thought would be to make sure that a shared key negotiated between the dongle and the phone, and that on the dongle side, this is tied to some measurement registers similar to how TPM works. This would mean needing to re-pair the dongle when updating the firmware on it, which… would definitely be a good idea.

I already asked 1Password if they would consider implementing this… but I somewhat expect this is unlikely to happen until someone makes a good proof of concept of it. So if you’re better than me at modern encryption, this might be an interesting project to finish up and getting to work. I even have a vague idea on a non-integrated version of this that might be useful to have: instead of being integrated with the manager, having the dongle connect with a phone app that just has a textbox and a “Type!” button would make it less secure but easier to implement today: you’d copy the password from the manager, paste it into the app, and ask it to type of the dongle. It would be at least a starting point.

Now if you got to this point (or you follow foone on Twitter), you may be guessing what the other problem is: USB HID doesn’t send characters but keycodes. And keycodes are dependent on the keyboard layout. That’s one of the issue that YubiKeys and similar solutions have: you either need to restrict to a safe set of characters, or you end up on the server/parser side having to accept equivalence of different strings. Since this is intended to use with devices and services that are not designed for it, neither option is really feasible — in particular, the option of just allowing a safe subset just doesn’t work: it would reduce the options in the alphabet due to qwerty/qwertz/azerty differences, but also would not allow some of the symbol classes that a number of services require you to use. So the only option there would be for the phone app to do the conversion between characters and keycodes based on the configured layout, and letting users change it.

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:

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.

Musings on bank security: part 1, authentication for account access

A couple of months ago I promised a post on bank security. The topic is not an easy one to write about, as I would not say I have the chops to talk about it. After all I have never worked at a bank, and unlike Andrea I have not spent years researching into payment processing security.

I am, though, confident enough to write about some of the user side security implementations (and blunders) of banks, for the simple fact that I have had more interaction, than the average person, with multiple banks in different countries. I can thus compare notes about these different banks and countries, so I can point out what is good and what is mental in their implementations, as I see it.

If you are looking for more in-depth security analysis, such as Point-of-Sale security or Chip-and-PIN analysis, I would suggest you look up talks of people like Andrea Barisani, linked earlier, or Krebs on Security — who should probably write an ATM skimmer guide, companion to Spam Nation. Both of them spent real time digging into the inner working of banks, which I haven’t done.

In my discussion of security features, I’ll be accepting as valid the research on security questions, published earlier this year by Google. Not only I find the results pretty consistent with my personal experience (even though this could be counted as confirmation bias), but once again because I accept the results and information coming from people who have had more time, and more data, to think about the problem.

The objective of this blog is to discuss which security features are in use by banks to protect customers, and whether these features work towards or against that goal, but before I dig into the nitty gritty details, I think it’s important to define what these security features are meant to protect in the first place. It might sound obvious, but talking about this with different people showed it not to be the case.

The obvious part is that you don’t want a random attacker to gain access to your bank account and transfer your money to their account. This is the very minimal protection you expect from your bank. You also don’t want people to know how much money you have, or where you spend it — leaving aside the favourite talking points of privacy advocates on the matter, knowing this kind of information is a treasure trove for blackmail.

There are many more pieces of information that should stay private, and often are not. Most people (but of course, not everybody) know to keep the number of their credit/debit card safe. What is not that obvious is that your IBAN (and BIC) should be kept secret, too — for my readers in the United States, these vaguely correspond to account numbers and ABA. People are used to see IBANs for various companies and utilities displayed on websites or invoices, explicitly so you can make payments to them, but that does not mean personal accounts should be advertised the same way. Jeremy Clarkson fell for it, too: he assumed that having someone’s IBAN, Sort Code – which is actually already part of IBAN, but let’s move on – and registered address would at most let people sending money to him.

What he found out is that, in addition to sending money to him, someone could set up a direct debit against his account. In this case, the “prankster” decided to set up a £500 direct debit, if my memory does not betray me, towards Diabetes UK. And he probably didn’t even notice that until he went to check his statement. On the other hand, if you think of doing the same to a person on a regular income, you can easily cause them trouble. This is a kind of attack I like to call Denial-of-Cash: it is a similar attack to a Denial-of-Service — it does not gain the attacker anything directly, but it’s a common tactic to set up blackmailing, or just to cause (big) inconvenience to a target. Protecting against Denial-of-Cash is in my opinion just as important as protecting against blatant theft.

As I’ll show later, most banks have proper protection in place against theft, but Denial-of-Cash is a different story. Usually there is tight security against transferring money to a new account, but transfers to a known account require minimal or no security. An attacker may not be able to take the money from the victim, but they may still be able to remove economic means from the the victim, at least for a while — I say this because I’d expect most of the frequent payees would allow you to get your money back at some point, even if they are utility companies rather than family members.

You could think that nobody would have time to waste in this kind of attacks, since it still require going after access to a bank account. But then I would point out that the Internet is full of people spending time, and money, to achieve what is at best nuisance and at worst terror: (D)DoS, SWATing and doxxing. Given how much time people have to spend going after public figures they don’t like, this kind of attack is far from unlikely.

Now, before I start talking about the actual security features, I should provide the list of banks I’m going to talk about. These are going to be split across four different countries: Italy, USA, Ireland and (in a very small way) UK — these being the countries I spent considerable amount of time living in, or having contact with.

My longest-serving bank is my Italian one, as I’ve been a customer of UniCredit Banca for well over ten years; you may know this bank from some of their branches in other european countries, including many in the former Eastern block. I doubt it shares infrastructure or security features between these branches though.

In Ireland, where I currently live, I have tried three different banks: AIB, KBC Ireland – a Belgian bank, although I’m not sure if it shares anything with their main branch – and Ulster Bank. The latter is part of RBS Group, and so is my only UK bank – Ulster Bank, Northern Ireland – and I know for sure they do share lots, if not all, the systems between them.

To complete the picture, in the United States I have and use a Chase account. I also used to have the City National Bank account, a smaller Californian bank, from when I lived in Los Angeles, but I have no idea what their systems look like at all now, so I’d rather not talk about them.

In addition to the banks themselves, I can provide some comparison with other financial services: Charles Schwab (a stock broker), Transferwise (a service that allows you to transfer money across currencies at acceptable rates and fees) and PayPal. I should probably count Tesco Ireland as well, since they are my credit card provider, but I’ll just add a note later about that.

Also, before I continue, I would point out that this is already making me uneasy. My paranoia would push me to hide where my money actually is. I will continue, though, under the assumption that anything that happens would be proving my point, and I hope I have enough redundancies, so that a Denial-of-Cash attack would not really be feasible. I will also point out that my birthdate is not strictly a secret, also my mother’s maiden name is not very well known and that’s going to stay that way — it is obvious to the people who know me in person from Italy, but other than that there is no online connection between me and my mother. This should appear obviously relevant pretty soon.

Let’s start with accessing the websites of the banks — all the six banks have an online banking system: this is actually a requirement for me, especially as I’m traveling for a good part of the year, and not even live in the country the bank is in for most of them. With the exception of Chase, the other banks provided me a numeric-only user ID.

For both KBC and Ulster Bank, the user ID was formed by my birthdate followed by four allegedly random digits; but in the particular case of Ulster Bank, you can lie on your date of birth at registration time, as I found out by making a mistake.

Chase is the only bank that let me chose my own username — they insisted in a alphanumeric one, so it’s not my usual one either. Transferwise and PayPal, as they are essentially “born on the Internet”, use email addresses as identifiers, which I like, since it’s one fewer parameter to commit to memory, but is obviously not secret. Charles Schwab generates usernames based on names.

The situation with passwords is more interesting. The Internet companies are the ones that act the most natural by allowing a single password, with all kind of characters and a fairly high length limit. Chase is the second most sane by allowing me to select my password, although it is case-insensitive – and I’m not sure if they use a hashing that normalizes the case, do a case normalization on the client side, or if they store passwords unencrypted, I hope for one of the first two.

Ulster Bank comes third by allowing me to choose both my password (long, alphanumeric, case sensitive) and a numeric-only PIN, but then they mess it up by doing something crazy. Then it’s followed by Charles Schwab (8-characters alphanumeric password), UniCredit (8-digits numeric-only PIN) and AIB (5-digits numeric-only PIN, and the same craziness as Ulster Bank). KBC is not in the list by not having a password and doing something slightly more insane, which I’ll get to later.

What Ulster Bank and AIB both do, which I find crazy, is asking you to provide them with only parts of your password and/or PIN. For example, they may ask you the 1st, the 6th and the 13th characters of the password — in the case of Ulster Bank they ask three out of four digits of your PIN, and three out of at most 20 characters of your password, together, to log into their Anytime Banking website.

This is not a completely mindless choice: it finds its reasoning in dealing with phishing attacks — if you know your bank will never ask you for the full password, the attacker can only hope to get parts of it, and it’s then unlikely they’ll be able to enter your online banking, as they’d have to be asked exactly those characters they just phished out of you.

Unfortunately this improves security only in theory. In practice it makes it worse. The first problem is that lots of people will not consider “my bank will never ask me the full password” as an absolute truth, and because of that, phishers can still just ask for the full password and be done with it. The second problem is that it requires people to come up with passwords that are not only memorable (and those are bad passwords), but also easy to count into, for example by joining together very short words, or other similar mnemonic tricks. The third problem, which honestly bothers me the most, is that this stops me from using a password manager like LastPass to auto-fill the password for me. See also this Wired article that was published while this blog post was still in draft.

As for the phishing this technique is supposed to prevent, I’m sceptical. The base idea is that a phishing attempt would only easily get three characters from the password by phishing the form, and thus it would require an incredible luck for them to be asked exactly those three characters. I can find multiple ways to invalidate this precondition, take for example the 5-digits PIN of AIB, the phishers only have to tell the user that they were mistaken in one of the digits and then ask for new challenge, asking the two missing ones.

But even more importantly, there are more sophisticated phishing attempts — say that you are going through a malevolent VPN or proxy, the attacker can implement a pass-through to your bank and still let you access all its functions — I’ve seen the proof of concept for similar sites, and heard colleagues in IT security talking about similar phishing attempts. In this case the attacker only needs to make sure to not close your session when you’re done, and just before the session gets interrupted by your bank, take control of it. Most people wouldn’t notice the added latency, and not everybody figures out something is wrong if the full name of the bank is missing on the location bar.

These requirements thus do nearly nothing to stop cybercriminals, but they weaken both the password quality and the password management, the worst of both worlds. My suggestion, based on both experience and the research brought by other groups and experts, is to allow people to set their passwords, at least alphanumeric ones (allowing symbols is good, requiring them not so much), and stop using PINs — phishing will happen anyway, make it harder for criminals to gain access to accounts by guessing numeric 6- or 8-digits passwords, which end up most likely as dates, either date of birth of the owner, or friends and family, or simply important dates in their life.

When I started this discussion I explicitly left KBC alone; the reason for this is that they don’t use passwords, and instead rely on their mobile application for authentication — and this is going to be the next topic of discussion for all the banks. To login on the KBC online banking from your computer you need first to have the mobile app configured, and log into that one. Then you can use their one-time PIN generator to use for login, together with the user ID that the bank gave you.

It may sound at first like a good idea, but it requires you to not lose access to your mobile phone, if you want to access your bank for any reason. The easy case if your phone crashes, or breaks, and you have to reset/replace it, in which case you just need to get another SMS on the registered phone to set up a new copy of the application (but it does not help if you’re traveling and the phone number is not actually available.) Worse, if you get your phone stolen, you now will have to first wait for a new SIM to take control of the phone number before you can gain access to your bank account.

At this point I think it makes sense to point out that there are two “schools” in dealing with mobile banking applications: AIB, Ulster Bank, and Chase allow you to install many copies of the app on different devices, so you can always have one at hand set up to access your account. On the other hand, KBC and UniCredit only allow you to set up the application on one device, and if you need to install it on a different one you have to deauthorize the one already installed.

The best, in my opinion, mobile app is the one from Chase: you simply install it and then login with the same credentials as the online banking website. It’ll ask you the password every time, but it does work fine with LastPass, and you can switch accounts as needed, which I find great.

All the other banks require setting up the application for one account only. I hope this is because they generate client-side secure credentials, but I’m too scared to actually try to figure out what the apps are doing. But nonetheless, it means that to set up the application you need access to the registered phone number. Luckily, none of them require to read the SMS out of the device store, which means you can use them on phone-like devices that can’t receive SMS, or even on a device that is not configured for the given phone number.

This becomes important when you have bank accounts spanning different countries (four in my case, but only three need a local phone number); to solve this problem, I ended up buying a Nokia 130 featurephone which is dual-SIM, and allows me access to my 3 UK and Wind Italy phone numbers — if I had kept my number on 3 Italy I would have had a three-of-a-kind! This by the way works out fine unless I’m physically in the UK, as then the 3 UK can’t connect, as the phone is not 3G.

If the user is tied to the device, for most bank, what password you use with it is quite different. As I said, Chase lets you login with the same credentials as the online banking, which makes it the most sane solution. AIB also follows the same setting as the website, and it allows you to login with the same three out of five digits of the PIN. UniCredit, while forcing you to register your account number with the application at setup time, it also uses the same PIN you use on the website (with no support for LastPass filling the form, but at least allowing to paste the password copied from it.

Ulster Bank and KBC instead ignore your online banking password (or precisely in the case of KBC it does not have one to begin with), and instead ask you quite explicitly for a PIN (digits only) that is tied to the device itself. I would hope that this is actually use to encrypt the client side certificate, but I’m not sure i I want to verify my hopes.

The problem with mobile PINs is, once again, that it’s one more separate piece of authentication to remember. And with the exception of Chase and UniCredit, as I pointed out, none of them allow you to use LastPass to store the involved PIN. The end result is that people either re-use another set of numbers, like their birthdate, or someone else’s, or even re-use the PIN of the device if there is one at all — and since figuring out the PIN based of oily pattern on the screen is far from impossible, you just have given up access to your bank account details.

Let me make something clear here: if you think that the people around you are all your friends, then you’re mistaken. I would love to live in the world you’re thinking of but I don’t. There are bastards around you just as much as there are great people, and the people you list as “friends” on Facebook are often not. Not only my birthday is not a secret, nor should my sister’s or my mother’s or whatever else. Facebook makes it easy to declare important dates for you — if something is an important date never use it as your PIN! I guess I could write a post about the dangers of 8-digits PINs.

I think this is going to be already quite the post, so I’ll follow up with the rest of my musings on bank security in a separate post.

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.

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?

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.

Heartbleed and SuperGenPass

After an older post of mine a colleague pointed out SuperGenPass to generate different passwords for each service out there from a single master password and the domain name in use. The idea was interesting, especially since it’s all client-side, which sounded very appealing to me.

Unfortunately, it didn’t take long for me to figure out a few limitations in this approach; the most obvious one is of course Amazon: while nowadays the login page even for Audible is hosted at the amazon.com domain, the localized stores still log in on, e.g., amazon.co.uk, but with the same password. Sure it’s easy to fix this, but it’s still a bit of a pain to change every time.

Also, at least the Chrome extension I’m using, makes it difficult to use different passwords for different services hosted at the same domain. You have an option to enable or disable the subdomain removal, so if you disable it, you’ll get different passwords for http://www.example.com and example.com (unlikely to be what you want) while if you enable it, you’ll get the same password for forums.gentoo.org and bugs.gentoo.org (which is not what I want). Yes you can fix it on a per-service basis, but it adds to the problem above.

The last bother in the daily usage of the extension, has been with special characters. SuperGenPass does not, by default, use any special characters, just letter (mixed case) and numbers. Which is perfectly fine, unless you have a website that stupidly insists on requiring you to use symbols as well, or that requires you to use (less stupidly) longer or (insanely stupidly) shorter passwords. You then have to remember.

All three of these complains mean that you have to remember some metadata in addition to the master password: whether you have to change the domain used, whether you’re using subdomain removal or not for that particular service, and whether you have to change the length, or add special characters. It partly defeats the purpose of having a fully stateless hashing password generator.

There is also one more problem that worried me much more: while it makes it so that a leak from a single website would leak your base password for everything else, it does not entirely make it impossible. While there’s no real way to tell that someone is using SuperGenPass, if you’re targeting a single individual, it’s not impossible to tell; in particular, you now know I’ve been using SGP for a while, so if a password for an account named Flameeyes gets leaked, and it looks like an SGP password, it’s a good assumption that it is. Then, all you need to do is guess the domains that could be used to generate the password (with and without subdomain removal), and start generating passwords until you get to the master password used to generate that particular site password. Now you just need to have an educated guess to the domain you’re going to try login as me, and you’re done. And this is with me assuming that there is no weakness in the SGP algorithm — crypto is honestly too hard for me.

And now there is heartbleed — go change all your passwords, starting from xine. But how do you change your passwords when you have them generated? You have to change your master password. And now you have to remember if you changed the password for a given service already or not. And what happens if one of the services you’re using has been compromised before, such as Comixology? Now you have three different master passwords, if not more, and you’re back to square one, like SGP was never used.

So with all this considered, I’ve decided to say goodbye to SGP — I still have a few services that have not been migrated – but not those that I’ve named here, I’m not a moron – but I’m migrating them as I got. There are plenty of things I forgot I registered to at some point or another that have been mailing me to change their password. I decided to start using LastPass. The reason was mostly that they do a safety check for heartbleed vulnerabilities before you set up your passwords with them. I was skeptical about them (and any other online password storage) for a long time, but at this point I’m not sure I have any better option. My use of sgeps is not scalable, as I found out for myself, and the lack of 2FA in most major services (PayPal, seriously?) makes me consider LastPass as the lesser evil for my safety.