the local part of my email address is just the letter 'd' by itself, which means microsoft has imposed the interesting restriction that my randomly generated password cannot contain the letter 'd' pic.twitter.com/tqTklyotTj
— a kind of synth bagpipe (@notrevenant) January 29, 2019
Be safe on the internet.
An open source checklist of resources designed to improve your online privacy and security. Check things off to keep track as you go.
I’m pretty impressed with this resource. It’s a little US-centric and I would have put the suggestions into a different order, but many of the ideas on it are very good and are presented in a way that makes them accessible to a wide audience.
2004 called, @virginmedia. They asked me to remind you that maximum password lengths and prohibiting pasting makes your security worse, not better. @PWTooStrong
In more detail:
- Why would you set an upper limit on security? It can’t be for space/capacity reasons because you’re hashing my password anyway in accordance with best security practice, right? (Right?)
- Why would you exclude spaces, punctuation, and other “special” characters? If you’re afraid of injection attacks, you’re doing escaping wrong (and again: aren’t you hashing anyway?). Or are you just afraid that one of your users might pick a strong password? Same for the “starts with a letter” limitation.
- Composition rules like “doesn’t contain the same character twice in a row” reflects wooly thinking on that part of your IT team: you’re saying for example that “abababab” is more-secure than “abccefgh”. Consider using exclusion lists/blacklists for known-compromised/common passwords e.g. with HaveIBeenPwned and/or use entropy-based rather than composition-based rules e.g. with zxcvbn.
- Disallowing pasting into password fields does nothing to prevent brute-force/automated attacks but frustrates users who use password managers (by forcing them to retype their passwords, you may actually be reducing their security as well as increasing the likelihood of mistakes) and can have an impact on accessibility too.
- Counterarguments I anticipate: (a) it’s for your security – no it’s not; go read any of the literature from the last decade and a half, (b) it’s necessary for integration with a legacy system – that doesn’t fill me with confidence: if your legacy system is reducing your security, you need to update or replace your legacy system or else you’re setting yourself up to be the next Marriott, Equifax, or Friend Finder Network.
- It’s definitely not the first time you’ve been told. Get your act together.
German chat platform Knuddels.de (“Cuddles”) has been fined €20,000 for storing user passwords in plain text (no hash at all? Come on, people, it’s 2018).
The data of Knuddels users was copied and published by malefactors in July. In September, someone emailed the company warning them that user data had been published at Pastebin (only 8,000 members affected) and Mega.nz (a much bigger breach). The company duly notified its users and the Baden-Württemberg data protection authority.
Interesting stuff: this German region’s equivalent of the ICO applied a fine to this app for failing to hash passwords, describing them as personal information that was inadequately protected following their theft. That’s interesting because it sets a German, and to a lesser extend a European, precedent that plaintext passwords can be considered personal information and therefore allowing the (significant) weight of the GDPR to be applied to their misuse.
Of the many, many, many bad things about passwords, you know what the worst is? Password rules.
If we don’t solve the password problem for users in my lifetime I am gonna haunt you from beyond the grave as a ghost pic.twitter.com/Tf9EnwgoZv
— Jeff Atwood (@codinghorror) August 11, 2015
Let this pledge be duly noted on the permanent record of the Internet. I don’t know if there’s an afterlife, but I’ll be finding out soon enough, and I plan to go out mad as hell…
One of the things people often tweet to us @ncsc are examples of websites which prevent you pasting in a password. Why do websites do this? The debate has raged – with most commentators raging how annoying it is.
So why do organisations do this? Often no reason is given, but when one is, that reason is ‘security’. The NCSC don’t think the reasons add up. We think that stopping password pasting (or SPP) is a bad thing that reduces security. We think customers should be allowed to paste their passwords into forms, and that it improves security…
It’s no secret. We’re really bad at passwords. Nevertheless, they aren’t going away any time soon.
With so many websites and online applications requiring us to create accounts and think up passwords in a hurry, it’s no wonder so many of us struggle to follow the advice of so-called password security experts.
At the same time, the computing power available for password cracking just gets bigger and bigger.
OK, so I started with the bad news, but this cloud does have a silver lining…
Last month, I volunteered myself to run a breakout session at the 2012 UAS Conference, an annual gathering of up to a thousand Oxford University staff. I’d run a 2-minute micropresentation at the July 2011 OxLibTeachMeet called “Your Password Sucks!”, and I thought I’d probably be able to expand that into a larger 25-minute breakout session.
The essence of my presentation boiled down to demonstrating four points. The first was you are a target – dispelling the myth that the everyday person can consider themselves safe from the actions of malicious hackers. I described the growth of targeted phishing attacks, and relayed the sad story of Mat Honan’s victimisation by hackers.
The second point was that your password is weak: I described the characteristics of good passwords (e.g. sufficiently long, complex, random, and unique) and pointed out that even among folks who’d gotten a handle on most of these factors, uniqueness was still the one that tripped people over. A quarter of people use only a single password for most or all of their accounts, and over 50% use 5 or fewer passwords across dozens of accounts.
Next up: attacks are on the rise. By a combination of statistics, anecdotes, audience participation and a theoretical demonstration of how a hacker might exploit shared-password vulnerabilities to gradually take over somebody’s identity (and then use it as a platform to attack others), I aimed to show that this is not just a hypothetical scenario. These attacks really happen, and people lose their money, reputation, or job over them.
Finally, the happy ending to the story: you can protect yourself. Having focussed on just one aspect of password security (uniqueness), and filling a 25-minute slot with it, I wanted to give people some real practical suggestions for the issue of password uniqueness. These came in the form of free suggestions that they could implement today. I suggested “cloud” options (like LastPass or 1Password), hashing options (like SuperGenPass), and “offline” technical options (like KeePass or a spreadsheet bundles into a TrueCrypt volume).
I even suggested a non-technical option involving a “master” password that is accompanied by one of several unique prefixes. The prefixes live on a Post-It Note in your wallet. Want a backup? Take a picture of them with your mobile: they’re worthless without the master password, which lives in your head. It’s not as good as a hash-based solution, because a crafty hacker who breaks into several systems might be able to determine your master password, but it’s “good enough” for most people and a huge improvement on using just 5 passwords everywhere! (another great “offline” mechanism is Steve Gibson’s Off The Grid system)
And it got fantastic reviews! That pleased me a lot. The room was packed, and eventually more chairs had to be brought in for the 70+ folks who decided that my session was “the place to be”. The resulting feedback forms made me happy, too: on both Delivery and Content, I got more “Very Satisfied” responses than any other of the 50 breakout sessions, as well as specific comments. My favourite was:
Best session I have attended in all UAS conferences. Dan Q gave a 5 star performance.
So yeah; hopefully they’ll have me back next year.
Opera 12 has been released, and brought with it a handful of new features. But there’s also been a feature removed – a little-known feature that allowed power users to have the web address appear in the title bar of the browser. I guess that the development team decided that, because the title bar is rarely seen nowadays (the space in which a title once occupied has for a long while now been used as a tab strip, in the style that Google Chrome and Mozilla Firefox eventually copied), this feature wasn’t needed.
But for users of the KeePass Password Safe, this has the knock-on effect of crippling the ability for this security tool to automatically type passwords and other form data into web pages, forcing users to take the long-winded route of manually copy-pasting them each time.
KeePass for Opera Plugin
[button link=”https://addons.opera.com/en-gb/extensions/details/keepass-auto-type/” align=”right” size=”medium” caption=”KeePass for Opera”]Install[/button]
Download KeePass for Opera (browser extension)
Open in Opera to install.
I’ve mentioned KeePass a few times before. See:
Things I’ve been doing instead of blogging, this last month, include:
- Code Week: hacking Three Rings code in a converted hay loft of a Derbyshire farm, as mentioned on the Three Rings blog.
- Hoghton Tower: as is traditional at this time of year (see blog posts from 2010, 2009, 2005, 2003, for example), went to Preston for the Hoghton Tower concert and fireworks display, accompanied by Ruth, and my sister’s 22nd birthday. My other sister has more to say about it.
- Family Picnic: Joining Ruth and JTA at Ruth’s annual family picnic, among her billions of second-cousins and third-aunts.
- New Earthwarming: Having a mini housewarming on New Earth, where I live with Ruth, JTA, and Paul. A surprising number of people came from surprisingly far away, and it was fascinating to see some really interesting networking being done by a mixture of local people (from our various different “circles” down here) and distant guests.
- Bodleian Staff Summer Party: Yet another reason to love my new employer! The drinks and the hog roast (well, roast vegetable sandwiches and falafel wraps for me, but still delicious) would have won me over by themselves. The band was just a bonus. The ice cream van that turned up and started dispensing free 99s: that was all just icing on the already-fabulous cake.
- TeachMeet: Giving a 2-minute nanopresentation at the first Oxford Libraries TeachMeet, entitled Your Password Sucks. A copy of my presentation (now with annotations to make up for the fact that you can’t hear me talking over it) has been uploaded to the website.
- New Earth Games Night: Like Geek Night, but with folks local to us, here, some of whom might have been put off by being called “Geeks”, in that strange way that people sometimes do. Also, hanging out with the Oxford On Board folks, who do similar things on Monday nights in the pub nearest my office.
- Meeting Oxford Nightline: Oxford University’s Nightline is just about the only Nightline in the British Isles to not be using Three Rings, and they’re right on my doorstep, so I’ve been meeting up with some of their folks in order to try to work out why. Maybe, some day, I’ll actually understand the answer to that question.
- Alton Towers & Camping: Ruth and I decided to celebrate the 4th anniversary of us getting together with a trip to Alton Towers, where their new ride, Thirteen, is really quite good (but don’t read up on it: it’s best enjoyed spoiler-free!), and a camping trip in the Lake District, with an exhausting but fulfilling trek to the summit of Glaramara.
That’s quite a lot of stuff, even aside from the usual work/volunteering/etc. stuff that goes on in my life, so it’s little wonder that I’ve neglected to blog about it all. Of course, there’s a guilt-inspired downside to this approach, and that’s that one feels compelled to not blog about anything else until finishing writing about the first neglected thing, and so the problem snowballs.
So this quick summary, above? That’s sort-of a declaration of blogger-bankruptcy on these topics, so I can finally stop thinking “Hmm, can’t blog about X until I’ve written about Code Week!”
After hearing about the recent purchase of social bookmarking service del.icio.us by Chad Hurley and Steve Chen, I remembered that once, long ago, I had a del.icio.us account. I decided to check if my account was still alive, so I trekked over to del.icio.us and took a look.
The site’s changed quite a bit since I last used it. It took a while for me to remember what my password was (it was an old, old one, since before I started using passwords the right way). It also appeared that the site still knew me by my former name (it really had been a while since I last logged in!), so I updated it with my new name.
The next step was to change the password. I generated a random password:
But when I went to change my password, it was rejected. Apparently it didn’t meet their security rules. What? That 30-character, randomly-generated password, containing uppercase letters, lowercase letters, numbers, punctuation, and special characters… isn’t secure enough?
I have a single-character surname. That means that a 30-character password will (assuming a dictionary of 26 letters, 10 digits, and let’s say 20 special characters) have about a 40% chance of being rejected on the grounds that it contains my surname. The longer my password is, the more likely it is to be rejected as insecure. My experiments show that “abcdefghijklmnop” is considered by delicious to be more secure for my account password than, say, “@Ubj#JeqPACrgmSQKn9qRYMBM9nPOj”, on account of the fact that the latter contains my surname.
Silly, silly, silly.
Having found by coincidence a (minor, perhaps exploitable as part of a more-complex attack) security problem with the website of a major high street bank, one would think it would be easier than it evidently is to get it reported and fixed. Several phone calls over a couple of days, and the threat of making a complaint about a representative if they didn’t escalate me to somebody who’d actually understand what I was explaining, I’ve finally managed to get the message through to somebody. How hard was that? Too hard.
If this still doesn’t work, what’s the next step? I’m thinking (1) change banks; (2) explain why to the bank; (3) explain why to the world. Seriously, I expect better from the people looking after my money.
And on that note: time for bed.
Edit: Meanwhile, we see that the PlayStation Network hack may have resulted in the theft of personal information from users’ accounts. While most of the media seems to be up in arms about the fact that this might have included credit card information, I’m most pissed-off about the fact that it might have included unencrypted passwords. Passwords should be stored using irreversible encryption: there’s no legitimate excuse not to do this, these days (the short version for the uninterested: there is a technique which can be used to store passwords encrypted in a pretty-much irreversible format, even if the hacker steals your entire computer: it’s very easy to do, protects against all kinds of collateral damage risks, and Sony evidently don’t do it). If any of Sony’s users use the same password for their email account, social network accounts, online banks, etc. (and many of them will, despite strong recommendations to the contrary), the hackers are probably already getting started with social hacking attempts against their friends, identity theft attacks, etc. Sony: you are a fail.
If you see me in person, you’ll know that this is something I rant about from time to time. But that’s only because people consistently put themselves and their friends at risk, needlessly, and sometimes those friends include me. So let me be abundantly clear:
If you’re reading this, there is at least a 95% chance that your passwords aren’t good enough. You should fix them. Today.
Let’s talk about what what we mean by “good enough”. A good password needs to be:
- Long. Some of you are still using passwords that are shorter than 8 characters. The length of a password is important because it reduces the risk of a robot “brute forcing” it. Suppose a robot can guess 1000 passwords a second, and your password uses only single-case letters and numbers. If you have a 4-character password, it’ll be lucky to last quarter of an hour. A 6-character password might last a week and a half. At 8-characters, it might last a few decades. Probably less, if your password makes one of the other mistakes, below. And the robots used by crackers are getting faster and faster, so the longer, the better. My shortest password is around 12 characters long, these days.
- Complex. Remember how long an 8-character password lasts against a “brute force” attack? If you’re only using single-case letters, you’re reducing that by almost a third. Mix it up a bit! Use upper and lower case letters, and numbers, as standard. Consider using punctuation, too. There’s no legitimate reason for a website to demand that you don’t have a long and complex password, so if one does seem to have unreasonable requirements: write to the owners and threaten to take your business elsewhere if they don’t get with the times.
- Random. If your password is, is based on, or contains a dictionary word (in any language), a name or brand name, a date, a number plate or (heaven forbid) a national insurance number, it’s not good enough. “Brute force” attacks like those described above are usually the second line of attack against properly-stored passwords: first, a robot will try every word, name or date that it can think of, with and without capitalisation and with numbers before and afterwards. Many will also try common phrases like “iloveyou” and “letmein”. WikiHow has a great suggestion about how to make “random” passwords that are easy to remember.
- Unique. Here’s the one that people keep getting wrong, time and time again. You should never, never, use the same password for multiple different services (and you should be very wary of using the same password for different accounts on the same service). This is because if a malicious hacker manages to get your password for one site, they can now start breaking into your accounts on other sites. Some people try to get around this by keeping two or three “levels” of passwords, for low-, medium-, and high-security uses. But even if a hacker gets access to all of your “low” security sites, that is (these days, frequently) still a huge amount of data they have with which to commit an identity theft.The other big reason to make sure your passwords are unique is that it makes it safer to share them, if the need arises. Suppose that for some reason you need to share a password with somebody else: it’s far safer for everybody involved if the password you share with them works only for the service you wanted to give them access to. Every person you trust is one more person who might (accidentally) expose it to a hacker by writing it down.Even if you have to memorise a complex “master” password and keep in your wallet a list of random “suffixes” that you append to this master password, different for each site, that’s a huge step forwards. It’s also a very basic level of two-factor authentication: to log in to your Twitter account, for example, you need your master password (which is in your head), plus the Twitter suffix to the password (which is written down in your wallet).
There’s been a wave of attacks recently against users of social networking websites: an attacker will break into an insecure web forum to get people’s email addresses and password, and then will try to log in to their webmail accounts and into social networking sites (Facebook, Twitter, etc.) using those same credentials. When they get a “hit”, they’ll explore the identity of the victim, learning about their language patterns, who their friends are, and so on. Then they’ll send messages or start chats with their victim’s friends, claiming to be their victim, and claim some kind of crisis. They’ll often ask to borrow money that needs to be wired to them promptly. And then they’ll disappear.
In this interconnected world, it’s important that your passwords are good not only for your benefit, but for your friends too. So if you’re guilty of any of the “password crimes” above – if you have passwords that are short (under 8 characters), simple (don’t use a mixture of cases and include numbers), predictable (using dictionary words, names, dates, etc.: even if they include a number), or re-used (used in more than one place or for more than one site) – change your passwords today.
Here’s some resources to help you do it:
- WikiHow’s guide to choosing secure passwords.
- PCTools’ great random password generator.
- The top 500 worst passwords of all time – if yours is in here, it’s probably already been compromised.
- SuperGenPass – a very good way to use a strong, unique password for every website without having to remember multiple passwords. Free.
- KeePass – a great way to use a strong, unique password for every site and service without having to remember multiple passwords. Free.
- LastPass – another great way to use a strong, unique password for every site and service without having to remember multiple passwords. Free (or cheap, for the premium version).
I recently came across the Mobile One-Time-Passwords project, which aims to make a free, secure alternative to commercial two-factor authentication systems (like SecurID). The thinking is pretty simple: virtually everybody now carries a mobile phone capable of running basic applications, so there’s no reason that such an application couldn’t provide the processing power to generate one-time-passwords based on a shared secret, a PIN number known only to the authenticating party and to the server, and the current date and time stamp.
Great! But it turns out that despite there being libraries to produce server-side implementations of the technology in PHP, Perl, and C, nobody had yet bothered to write one in that most marvelous of programming languages, Ruby.
Well, now I have. So if anybody’s got the urge to add one-time-password based security to their Rails or Sinatra app, or would like to write an MOTP client for their Ruby-capable smartphone: well, now you can.