Archive

Posts Tagged ‘encryption’

Who’s doing what to protect our data?

December 9, 2013 Leave a comment

The Electronic Frontier Foundation has a fascinating graphic on which companies are doing what things to protect their customers’ – our – data in the post Prism/Snowden era.

spacer

eff

What different companies are doing to protect their customers’ data – source: EFF

spacer

What really leaps out is that the companies is that provide consumer cloud services are on our side (Dropbox, Facebook, Google and Twitter); telecommunication companies are on their side (AT&T, Comcast, Verizon); and the main OS providers (Microsoft and Apple) aren’t really sure which side their bread is buttered.

Categories: All, Politics, Security Issues

Password theory is good – password practice is poor

November 25, 2013 Leave a comment

There’s nothing wrong with passwords. At least there’s nothing wrong with the theory of passwords.

You have a locked room. The only way into the room is through a single door. The only way through the door is with a single key. You have the only key. What’s wrong with that?

Throughout this article we’ll talk about locked rooms and keys. The locked rooms are your accounts, mostly on the internet; and they contain your valuable personal data. The keys are your passwords to those accounts. You should have a separate key for each locked room. If you have a single key for multiple rooms and you lose that key or it is stolen, the finder can get into all of your rooms.

So, just like any key to any room, we have a responsibility to keep it or them safe if we want to keep our property safe. We need to make sure they cannot be guessed; that we do not leave them lying around for others to find; that we make it as difficult as possible for hackers to steal them directly from our desktop computers (anti-virus, firewalls and above all else, common sense); and that we do not make copies and use the same key for multiple rooms (we need a different key for every different room).

The problem is that we hear about new password thefts almost every day. Some of them happen because of earlier password thefts. As soon as your password is stolen, you are no longer the only person who can get into your locked room. Any person who has your password, the key to your locked room, can steal all of your personal, private and valuable information. Here’s a selection of thefts, basically just what I can remember – there’s many, many more – from this year alone:

spacer

Adobe 150,000,000 http://kevtownsend.wordpress.com/2013/11/14/adobe-you-really-cocked-up-on-this-one/
Apple 275,000 http://www.theguardian.com/technology/2013/jul/22/apple-developer-site-hacked
Cupid Media 42,000,000 http://www.infosecurity-magazine.com/view/35767/42-million-passwords-compromised-as-hackers-aim-at-cupid-online-dating/
Drupal 1,000,000 http://www.infosecurity-magazine.com/view/32697/drupal-hit-by-massive-data-breach
Evernote 50,000,000 http://www.infosecurity-magazine.com/view/31023/evernote-hacked-50-million-passwords-reset
Living Social 50,000,000 http://www.infosecurity-magazine.com/view/32087/50-million-livingsocial-passwords-stolen
LoyaltyBuild 1,500,000 http://www.infosecurity-magazine.com/view/35604/irish-data-center-breach-hits-15-million-european-consumers
MacRumors 860,000 http://www.infosecurity-magazine.com/view/35592/macrumors-breached-860k-passwords-potentially-compromised/
Morningstar 182,000 http://www.infosecurity-magazine.com/view/33348/morningstar-provides-some-information-about-breach
Nintendo 24,000 http://www.infosecurity-magazine.com/view/33342/thousands-of-club-nintendo-accounts-compromised
Racing Post unknown http://www.infosecurity-magazine.com/view/35814/racing-post-breached-users-passwords-stolen/
Scribd c300,000 http://www.nbcnews.com/technology/scribd-hack-exposes-thousands-users-1B9239618
Twitter 250,000 http://www.wired.co.uk/news/archive/2013-02/02/twitter-hacked
UbiSoft up to 58,000,000 http://www.infosecurity-magazine.com/view/33248/ubisoft-maker-of-assassins-creed-and-ghost-recon-breached
Ubuntu 1,800,000 http://www.infosecurity-magazine.com/view/33556/ubuntu-forum-hacked-18-million-accounts-compromised
vBulletin 900,000 http://www.infosecurity-magazine.com/view/35718/is-there-a-vbulletin-zeroday-out-there/
Yahoo 450,000 http://www.infosecurity-magazine.com/view/26976/yahoo-confirms-what-everyone-already-knew-about-password-breach

spacer

Criminals get passwords either by knowing them (because they are given them, or they are insufficiently hidden), or they guess them. In the first case they use social-engineering psychology to persuade the user to hand them over (more information on social engineering here, and spear-phishing here), or they find them unhidden by the user. In the latter case they guess the most common passwords, or use automated dictionaries to try every possibility until the right password (key) for a known account (locked room) is found.

Most websites include a limit on the number of failed access attempts allowed within a predetermined period. This means multiple attempts to guess the right password while online are almost certain to fail. That is why criminals steal password databases from websites – so that they can try millions of automated guesses offline without being interrupted. The purpose is still to find the key to gain entry to your locked room, and to steal everything of value within it.

But there’s an easy solution: use complex passwords that cannot be manually guessed, and electronically hide them so that automated guessing still won’t work.

There are two methods for ‘electronically hiding’ text: encryption and hashing. Encryption involves converting text into an apparently meaningless jumble of characters in a manner that can only be unjumbled if you have the secret decryption key – which can be the same as (symmetric encryption) or different to (asymmetric encryption) – the encrypting key for your password. Encryption, by definition, comes with the ability to decrypt – the ability to return the jumble back to the original text. Hashing is different. Hashing is one-way only. Hashing converts the original text into a meaningless jumble that cannot be de-hashed back to the original.

Hashing is the right solution for websites to hide their users’ passwords. It means that even the website doesn’t need to know the password, only the hash, which they cannot return to the original password key. With this method passwords need never and should never be stored by websites.

When you create a new account you are asked to provide a password. That password is hashed, paired with your user ID (often, but not necessarily, your email address), associated with your account, and stored. Whenever you want to access your account, you again enter your password. It is hashed again. If your user ID and the new hash result match with something stored, you are allowed access to the associated account.

Hint: if you forget your password, distrust a website that is able to send you your old password by email – it shouldn’t have your password. The ‘correct’ procedure is to guide you to a place where you can create a new password.

So, the effective use of passwords is a partnership. User’s need to create good passwords and keep them safe, while internet companies need to store them safely and securely. It is my contention that done properly, this will be enough.

Alternatives to the simple password
Before we go too far on the strengths and weaknesses of passwords, we should mention the alternatives.

Passwords are designed to provide user authentication – to prove that Joe Smith really is not just any Joe Smith, but the right Joe Smith. In security terms, authentication is often described by the number of factors it uses – with the implication and a degree of validity that the more factors used, the more secure the authentication. (Personally, I do not believe that is necessarily true.) ‘Factors’ in this sense are things you know (like a password), things you have (like a token), things you are (like a biometric), and so on. The two most commonly used additional factors today are soft tokens and biometrics.

Soft token 2FA
An example of the most commonly used two-factor user authentication is the separate token sent out-of-band to the user’s mobile phone. This is a one-off code. Now you could say that ‘the thing that is owned’ is the separate code, or the phone that it is received on. Either way, the user now requires something he knows (password) and something he owns (phone/token).

I have two problems with this. Firstly, whenever you introduce complexity into security, you also introduce weakness – the phone and the communication sending it can both be attacked separately. The second issue is that this complexity makes it harder to use – and users do not want any more difficulty. If 2FA is an option, most users opt to ignore it. That in itself is not an issue, because we’re back where we started. But the fact that there **is** a 2FA option can mean that users take less care, whether they opt for 2FA or not, simply because it is clear that the vendor is taking more care. There is a danger that 2FA can cause a false sense of security.

Biometric authentication
Biometrics is getting a lot of publicity. Governments use facial biometrics for surveillance and passports; law enforcement uses fingerprints for criminal recognition; and Apple uses finger scans for opening the new iPhone.

I have three concerns. Firstly, nearly all biometrics can be forged. It took researchers just days to break through Apple’s iPhone finger scan. Secondly, what do you do if your biometric is compromised? If your password is compromised, you create or request a new password. What do you do if your iris, or your voice, or your thumbprint is compromised? And thirdly, it’s that old false sense of security – people using biometrics tend to think they are more secure than they actually are.

My contention, which I shall try to demonstrate below, is that passwords – used correctly – are adequate on their own. All we have to do is use them correctly.

Creating secure passwords and keeping them safe
Criminals get into locked rooms by guessing the password key.

When Gawker was breached in 2010, researchers found that the ten most popular passwords were

  1. 123456
  2. password
  3. 12345678
  4. lifehack [LifeHacker is a Gawker publication]
  5. qwerty
  6. abc123
  7. 111111
  8. monkey
  9. consumer
  10. 12345

When LinkedIn was breached in 2012, researchers discovered that the ten most popular passwords were:

  1. password
  2. 123456
  3. 12345678
  4. 1234
  5. qwerty
  6. 12345
  7. dragon
  8. pussy
  9. baseball
  10. football

How long do you think it would take to guess passwords like these?

Of course, if the passwords are all held in a single database without any form of electronic jumbling, then a password thief doesn’t need to guess anything because he’s got them written down in front of him. So the websites store the passwords ‘hashed’.

Now the criminals have to start guessing. To help this process, they use computers and specialized dictionaries called rainbow tables. Rainbow tables are effectively long lists of precomputed hash outputs together with the original input text that was used.

Stolen password hashes are then simply compared to the rainbow tables. If the hash output is found, then the password is known – that is, the password has been cracked.

So when you consider a new password, you should also consider how they are cracked with rainbow tables. Any word that appears in a dictionary will be in the tables. Any number up to at least 999,999,999 will be in the tables. All conceivable combinations of letters up to a certain length, and all conceivable combination of letters and numbers up to a certain length, will appear in the tables. In short, if you use a password made up of any combination of letters and numbers up to, say, seven characters, and that password is stolen, you should consider it already cracked and available to the criminals.

This will include some of the commonly recommended methods for coming up with passwords – such as initial letters from quotations. “into the valley of death rode the six hundred” could provide ‘itvodrt600′. That looks like a strong password – but you should assume that it’s in a rainbow table somewhere.

The way to avoid rainbow tables is to use a very long password that mixes uppercase, lowercase, numbers, special characters and punctuation marks. The problem then becomes one of usability – passwords that are difficult to guess are even more difficult to remember.

The best way to produce, store locally and safely, and use strong passwords is to use a reputable and recommended password manager. I’m not going to recommend any myself – you must research that on your own. But the one I use generates passwords for me such as

%wc;I’,;Gp*CfQr9FUFpZYm|

I consider that to be reasonably secure against most tables.

The responsibility of the website
The fact remains that if the vendor doesn’t keep passwords hashed, then it really doesn’t matter how complex I make them.

So if it is incumbent on me to generate strong passwords, then it is equally incumbent on the website to store them securely. That means hashing them.

Actually, it means more than that. It means using a strong hashing algorithm (not all are equally good); it means using a slow algorithm (some were designed for speed when computers were slow, with the unintended consequence of making cracking faster and therefore easier); and they should be salted. Salting is the addition of additional random characters to the user’s password. Basically, salt makes the password even harder to crack – it turns a medium strength password into a strong password.

This is standard best-practice. Unfortunately, too many websites do not conform to best practice. In the last few weeks we have heard:

  • Adobe did not hash its passwords; it encrypted them (better than nothing, but not as good as hashing) It also stored users’ password hints next to the encrypted passwords in plain text – making it, in some cases, obvious what the password was.
  • LoyaltyBuild stored users’ credit card numbers unencrypted and with the cards’ CVV numbers.
  • Cupid Media stored its users’ passwords in plaintext.

What is the point of coming up with a long, complicated, unguessable password if the website just hands it to the criminals on a plate?

Conclusions and recommendations
For password access to locked rooms to work, they need to be strong (from the user) and hashed and salted by the website. Clearly that frequently doesn’t happen; and that’s why we have rampant identity theft.

Since it doesn’t happen voluntarily, we need a new code of practice backed by regulation if necessary. Much of it will fall on the website; but that’s a small price to pay for a secure and trusted internet.

Firstly, websites should require a minimum strength password from their users – so strong, in fact, that it becomes easier to use a password manager than to try to make them up.

Secondly, users must learn not to reuse the same password on multiple sites. Security audits must confirm this as part of staff awareness training, and schoolchildren need it to be taught in schools.

Thirdly, websites must be required, by law if necessary, to make it clear how they protect their users. Inadequate password security could then be shunned by users and ridiculed by professionals.

With these three basic developments, password-protected access will do the job it was designed to do: locked rooms will stay locked, personal and private.

Categories: All, Security Issues

There are no absolutes in security

August 19, 2013 2 comments

I’ve had a comment on my latest Dropbox post (Is it safe to carry on using Dropbox (post Prism)? Yes and No: Part III) that I have rejected. This is a very heavily moderated blog, but I thought I’d explain why I rejected this one.

The comment started by saying, “As Dropbox stands today on its own, yes, completely agree that there is the *possibility* of your data being “looked in on” by people without your knowledge or permission.” It then added, “However, there are 3rd party services out there like xyznnn (www.xyznnn.com) that are completely tapproof, i.e. YOU hold the keys, not Dropbox or the 3rd party vendor. Meaning that your data cannot be accessed without you knowing about it. Read more in this blog post: xyznnn.”

It was, naturally, submitted by a member of the marketing department of the xyznnn company; so it is absolutely an attempt at advertising to the readers of this blog. That, in itself, is not enough for me to reject it. If such a comment adds value to the subject or will genuinely help the reader, I will still generally allow it.

But this one is flatly wrong. First of all, never trust anyone who says or implies that any security is unbreakable. In fact, if anyone says that, you can begin to distrust their understanding of security. So, rather than helping the readers, I consider claims such as “completely tapproof” and “your data cannot be accessed” to be misleading and potentially dangerous.

I will not knowingly help promote products that make what I consider to be statements verging on hyperbole and are fundamentally inaccurate — there are simply no absolutes in security. And that is why this particular comment was rejected.

Categories: All, Security Issues

Chinese [irony alert] whispers…

July 10, 2013 Leave a comment

I got this note from a PR company working for a quite major security company. It said, “In response to the MOD being the victim of a cyber espionage attack that has led to the theft of key data…” and pointed to an article on V3.

That article does indeed say,

The Ministry of Defence (MoD) was the victim of a cyber espionage attack that led to the theft of key data, in the latest evidence of the sustained cyber threats facing the UK.

The comment from the PR company talked about the importance of protecting encryption keys. “Failure to retain custody of your encryption keys is a huge issue that essentially negates the benefits of encryption,” said the spokesman.

This is, of course, perfectly true and valid. But we should go back to the source of V3′s article, the latest 2013 annual report from the UK’s Intelligence and Security Committee. Not once does it use the phrase ‘key data’. In fact, not once does it mention encryption.

In fact it doesn’t even say that the MoD was the victim. What it says is,

Government departments are also targeted via attacks on industry suppliers which may hold government information on their own systems. We have been told that cyber espionage “[has] resulted in MOD data being stolen,***. This has both security and financial consequences for the UK.

So this should be a story about supply chain security, not about encryption keys.

It is from such little misunderstandings that global cyberwar evolves…

Categories: All, Security Issues

Is data in Switzerland any more secure?

July 10, 2013 Leave a comment

Over the last few days numerous IT magazines have run a story about a surge in customers for Swiss hosting companies. For example, “Artmotion has witnessed a 45% growth in revenue amid this new demand for heightened privacy,” says Computer Weekly.

Most of these stories have come from, yes, a post-PRISM press release issued by Artmotion. “Artmotion, for example,” says the press release, “has witnessed 45 per cent growth in revenue amid this new demand for heightened privacy.”

Why are companies moving to Switzerland? Well, remember that we now live in post-Snowden enlightenment. “The desire for data privacy has therefore seen a surge in large corporations turning to Switzerland to take advantage of its privacy culture. Enterprises can host data in Switzerland clouds without fear of it being accessed by foreign governments,” says Computer Weekly.

“The desire for data privacy has therefore seen a surge in large corporations turning to ‘Silicon’ Switzerland to take advantage of the country’s renowned privacy culture. Here they can host data without fear of it being accessed by foreign governments,” says the press release.

Computer Weekly and the press release then both quote Mateo Meier, director at Artmotion:

Unlike the US or the rest of Europe, Switzerland offers many data security benefits. For instance, as the country is not a member of the EU, the only way to gain access to the data hosted within a Swiss Datacenter is if the company receives an official court order proving guilt or liability.

But my question is this: how do you get the data to Switzerland? Even if PRISM can’t get it when it’s there, Tempora will get it en route. And the NSA and GCHQ are in bed together in such an incestuous relationship that it would make a great movie (first available on The Pirate Bay).

That means that data in transit to and from the host will need to be encrypted (outside of the browser because we know we cannot trust either Google or Microsoft) in true and genuine end-to-end encryption. That won’t work for a traditional public-facing website.

What about a private cloud not open to the public? Still won’t work without encryption unless all of the users have a secure link to the server – and the only way to do that is with encryption.

What about secure back-up of company data? No, you still have to encrypt it to get it to and from the host securely.

So it doesn’t matter where you host your data, the only way it can be secure is if you encrypt it. But if you encrypt it, it doesn’t matter where you host it (provided of course the NSA/GCHQ doesn’t have a backdoor into the encryption itself).

I’m all in favour of Switzerland trying to make hay from the PRISM/Tempora fall out – but don’t assume that your data is safe just because of Swiss privacy laws. You need encryption, not geography, to be private.

Categories: All, Security Issues

Cryptocat — encryption can make you safe, or very very unsafe

July 7, 2013 Leave a comment

One of the first rules of security is that you never use a product that employs any form of proprietary cryptography. And if a security guy then says ‘be careful’, you’d best be very very careful — no matter how many magazines or newspapers say the product is the real deal.

That’s what happened with Cryptocat which is a secure chat product that “could save your life and help overthrow your government,” according to Wired — it could “save lives, subvert governments and frustrate marketers.” Forbes said that it “establishes a secure, encrypted chat session that is not subject to commercial or government surveillance.” Sounds good.

But security folk weren’t so sure. “Since Cryptocat was first released,” warned Christopher Soghoian in July 2012, “security experts have criticized the web-based app, which is vulnerable to several attacks, some possible using automated tools.”

Patrick Ball expanded in August 2012:

CryptoCat is one of a whole class of applications that rely on what’s called “host-based security”… Unfortunately, these tools are subject to a well-known attack… but the short version is if you use one of these applications, your security depends entirely the security of the host. This means that in practice, CryptoCat is no more secure than Yahoo chat, and Hushmail is no more secure than Gmail. More generally, your security in a host-based encryption system is no better than having no crypto at all.
When It Comes to Human Rights, There Are No Online Security Shortcuts

Security professionals, then, were not surprised when last week Steve Thomas wrote about his DecryptoCat — which does what it says on the can: it cracks the keys that let you read the messages.

If you used group chat in Cryptocat from October 17th, 2011 to June 15th, 2013 assume your messages were compromised. Also if you or the person you are talking to has a version from that time span, then assume your messages are being compromised. Lastly I think everyone involved with Cryptocat are incompetent.
DecryptoCat

This is a big deal, because Cryptocat has been marketed towards dissidents operating in repressive regimes. As Soghoian wrote:

We also engage in risk compensation with security software. When we think our communications are secure, we are probably more likely to say things that we wouldn’t if our calls were going over a telephone like or via Facebook. However, if the security software people are using is in fact insecure, then the users of the software are put in danger.
Tech journalists: Stop hyping unproven security tools

Add to that the current revelations on the NSA/GCHQ mass surveillance, and our understanding from last week’s Snowden revelations that the NSA automatically and indefinitely retains encrypted messages, then we can say with pretty near certainty that if you have been using Cryptocat, at least the US and UK governments are aware of everything you said.

Categories: Uncategorized

Access to communications data by the intelligence and security Agencies

February 6, 2013 Leave a comment

Have a look at this flow chart. It’s taken from the Intelligence and Security Committee’s report on the Communications Bill, and “illustrates how the elements of the Bill would work in practice.” It is UK democracy at work.

Comms Bill Flow Chart

It starts with the authorities deciding that certain data is wanted. If the service provider objects, see how he has the right to appeal. If he accepts the request, he gets a notice to retain the required data. If he rejects the request, he gets a notice to retain the required data. If he still objects, it might go to court. If he wins the case, “HMG negotiates and serves a notice on a different Service Provider to collect and retain some or all of the required data using Deep Packet Inspection (DPI) or similar techniques.” In other words, they chose a different ISP and start all over again. That’s pure democracy: keep asking the question until you get the answer you want.

Of course, it’s not the only worrying thing about the Access to communications data by the intelligence and security Agencies report. My primary concern is that it is not an investigation into the Communications Bill at all. It is really a libation to the Bill. Its only criticism is that the government should have done a better job at selling the Bill to the population. But having said that, the Committee still tries to obfuscate and mislead.

Consider the section on ‘encryption’. It is heavily redacted (another example of modern democracy: ‘don’t tell the plebs what we’re doing’). It effectively says little more than

spacer

From the encryption section of the report

From the encryption section of the report

spacer

Makes you wonder, doesn’t it. What are those ‘options’? And what does it mean for the service provider to provide an unencrypted version of encrypted communications data?

I asked two interested experts to explain the issue for me – and rather than try to comment on their replies, I’m reproducing them in full.

spacer

James Firth, CEO of the Open Digital Policy Organisation Ltd

The problem arises because communications can be – effectively – layered. So a portion of ‘content’ at one (higher) layer is actually communications data at a lower layer.

A classic example is webmail. Alice logs in to mail service provider G via secure HTTPS and sends a message to Bob. All her ISP knows is that Alice has a web session with G.

Various proposals being touted – sometimes in the various drafts – include forcing mail service providers to abide by the Comms Bill. Jurisdiction could be enforced in some way for any company with a UK presence, but it would be impractical as the Bad Guys would just use other companies.

But there have been scarier options touted.

If Alice didn’t use a secure method to connect to her mail service provider her ISP could be forced to scan all CONTENT in order to detect nested communications data. In this model her ISP would scrape the email “to” and “from” fields from her web session. I doubt this would pass muster with various EU Directives but that’s been suggested.

Even scarier suggestion – if Alice DID use SSL to connect to her mail service provider it has been suggested – I have a very good contact confirming this – that legislation could be introduced to force her ISP to store the whole encrypted transaction, even though this includes the content.

The idea being that HMG could get a court order – here or in e.g. the US – at a later date to force her mail service provider to disclose their private SSL key. From that it would – in *some cases* – be possible to replay the SSL transaction to discover the session key and decrypt the contents, then extract the communications data, and – honest guv – ignore any content.

The major flaw in this plan is that Google, as one mail service provider, has rolled-out a feature called forward secrecy (http://en.wikipedia.org/wiki/Perfect_forward_secrecy).

Forward secrecy introduces, essentially, a second negotiated secret into the SSL transaction; a secret known only by the client web browser. The protracted SSL handshake with forward secrecy ensures that if one private key was later compromised – e.g. the mail service provider’s key – an attacker would still not be able to reproduce the plaintext from a captured encrypted session.

Clever mail service providers would never want to be in a position where they are forced by a court to hand over their private keys, so forward secrecy is actually in their interests as it devalues their private key as it won’t alone decrypt a captured session. In fact the second secret needed to decrypt a session with perfect forward secrecy should have been destroyed by the client and the server as soon as the session ends.

spacer

spacer

Alexander Hanff, managing director at Think Privacy Ltd

When an SSL connection is made a ‘tunnel’ is set up and as a result all of the HTTP headers are encrypted (these include the specific web page you are requesting from the server) but the TCP and IP data is not encrypted as they exist on different OSI layers – HTTP/SSL exist in layers 5-7 whereas TCP is layer 4 and IP is layer 3 (if my memory serves me correctly you might want to double-check that).

As you correctly state, it would be impossible to get the encrypted content to the server if the 3rd and 4th OSI layers were encrypted, so yes there is still a DNS lookup (which means the ISP knows the domain and the IP address you are trying to communicate with) but they would not know which web page you are trying to access within that domain.

The same should be true of emails which are not hosted by the ISP (for example I run my own email servers) they would know which email server I am trying to communicate with but since my emails are transported over SSL/TLS the would not know whom I am communicating with or anything else which is held within the encrypted packets (I run my own email servers to circumvent the Data Retention aspects of RIPA/Data Retention Directive).

That said, the ISP could easily set up Man in the Middle attacks similar to how Phorm did with their DPI boxes which would allow them to decrypt everything (including the content) which is what I presume was the redacted content in the report released yesterday when they were talking about the government has a feasible method of dealing with encryption. This of course would be completely illegal under RIPA (without a warrant) so they would need to introduce legislation to do this (which would put them in breach of the EU Data Retention Directive but as we know the UK gov are not good at complying with EU Directives so they probably wouldn’t care).

So in summary, yes encryption restricts them from obtaining some of the higher level data they want but not the low-level data such as domain and IP.

spacer

Notice that there is one common element in these two replies: further legislation. It seems highly likely, then, that this Communications Bill will be supplemented by altogether more intrusive legislation (the ‘options’) when the authorities finally realise what everyone has been telling them: this Communications Bill isn’t what they say and will not work. And that, of course, is democracy at work: keep asking the question until you get the response you want.

Categories: All, Politics, Security Issues

The Data Protection Regulation should be amended to force companies to disclose how passwords are stored

December 7, 2012 Leave a comment

Over the last couple of days it has been disclosed that an amazing amount of personal data on 1.1 million Americans has been lifted from the US Nationwide insurance group. Passwords do not appear to be involved – it’s a storage of data rather than an interactive site. But the point is that this data would appear to have been unencrypted – at least the company concerned hasn’t specified one way or the other; and that’s the problem.

Time and again we learn of plaintext passwords being stolen. Plaintext is unacceptable, but it happens. Sometimes, they are stored hashed by SHA1. This is unacceptable because dictionary attacks and Jens Steube’s newly announced brute force attack makes them surprisingly vulnerable; but it happens. At the very least, passwords should be stored hashed with SHA1 – preferably better – and salted.

I for one would be reluctant to commit my password to any site that stores that password with anything less than salted SHA2. But they don’t tell us, do they.

So I call now for the European Commission to amend the proposed Data Protection Regulation to include a requirement for all sites that store user passwords to make it clear on their site, at registration, precisely how those passwords are stored: plaintext, hashed (with what), or hashed and salted. This is the only way we will be able to force vendors to improve the way in which they handle our data.

spacer

See also: Storing passwords: why you should flavour your hash with salt

Categories: All, Security Issues

Is it safe to carry on using Dropbox? Yes and No: Part II

August 5, 2012 12 comments

Ever since the news of a potential breach at Dropbox emerged, my old post “Is it safe to carry on using Dropbox?” has been getting an elevated number of hits. It is time perhaps to update.

Firstly, what’s this about a breach? Well, Dropbox wasn’t breached in the traditional sense of the word. The likelihood is that a number of Dropbox users had the same log-in credentials (email address and password) that they used on a different web account that was breached. The criminals were able to reuse the credentials stolen from elsewhere, and gain access to a number of Dropbox accounts.

Unfortunately, one of these accounts belonged to a Dropbox employee. The criminals gained access to his account and found a file containing an unknown number of users’ email addresses. It was probably these users that were subsequently spammed, leading to the suggestion that Dropbox had been hacked.

This leaves us two questions: is Dropbox safe to use; and what lessons should we learn?

Dropbox is no more nor less safe than it was before; that is, it is not safe. This for two reasons: firstly, it is in the cloud; and secondly, Dropbox is a US company. You don’t know what is happening in a cloud that is not your own; so it is not safe. Dropbox is registered in the US, and is subject to the PATRIOT Act – the US authorities are able to demand details of you and your account simply because they want them. So Dropbox is just not safe for confidential or incriminating content (and nor, note, is any other US-based cloud company).

But why worry if the data you store is neither of these? You can increase the level of security by locally encrypting the files (with something like TrueCrypt) and storing only encrypted files. The basic rule is simple: if it is important that nobody else ever sees the data, don’t use Dropbox; if it doesn’t matter if other people see your files, you can use Dropbox. If you’re somewhere in-between, encrypt.

What should we learn from this? Well, it is good that Dropbox has or will be initiating additional security – including two-factor authentication. This will make your data more safe from hackers, but it has no effect on law enforcement intrusion. And judging from Google’s 2FA, few people will bother using it.

I also very much like the new security page (partial screenshot below). It’s available at your Dropbox settings location, and shows who has recently accessed your account and who is currently accessing your account. This is certainly worth checking regularly. Note also that this is where you change your Dropbox password.

Dropbox security

The new Dropbox security page

But despite this good response from Dropbox, the fact remains that these are reactive and not proactive steps. Security is still an afterthought, added on to systems rather than designed into them. That’s one lesson we don’t seem able to learn. Secondly, it is sad that a Dropbox employee should be guilty of fundamental security no-nos: he stored a file with user emails in plaintext; and he was reusing the same password on at least two different accounts.

These are the main lessons that we all need to learn: do not trust other people or systems to do security for you. It is your, not their, responsibility (or at least, even if it is their responsibility, you cannot assume they will do it).

And finally, and fundamentally, and beyond all others: when will we ever learn to stop re-using the same password on multiple accounts? Tens of millions of passwords have been stolen from tens of major providers this year alone – and that’s just the ones we know about. Are you sure that your own password is not included? If it is, and you re-use it on multiple accounts, then you simply don’t know who has access to your accounts. And if that includes your email account or bank account, not to put too fine a point on it, you’re screwed.

So, is Dropbox safe? Probably not; but that doesn’t mean we shouldn’t use it under certain circumstances. I shall certainly carry on using it. But are we safe? Absolutely not until we start using unique, strong passwords for every different account. Hint. Use a good password manager.

Update: the revelations from Edward Snowden concerning US government access to cloud services, which will include Dropbox, adds new urgency to considering the use of Dropbox. See our latest commentary following Edward Snowden’s Prism revelations: Is it safe to carry on using Dropbox (post Prism)? Yes and No: Part III

See also: Is it safe to carry on using Dropbox following the DMCA takedown revelations? (03/31/2014)

Is it safe to carry on using Dropbox with Condoleezza Rice on the Board? (04/14/2014)

Categories: All, Security Issues
Follow

Get every new post delivered to your Inbox.

Join 127 other followers