The long journey of creating secure web access - Part I.
Tresorit is designed to protect sensitive data from any threat in the cloud. This means that no one can read the content of a ‘tresor’ without the owner’s permission, not even Tresorit employees with administrator access and no other unauthorized eyes, even in case our servers get compromised. But can we guarantee that level of security for web access too? Well, not yet. We are working on it, and this (and the following) post gives you a deeper insight what does that exactly mean.
Addressing major Security concerns
Using client-side encryption alone is not enough for such high-grade protection: we protect our customers’ password, protect users from phishing, fake or infected clients and several other vulnerabilities. From our previous post you may remember our ground rules saying we won’t apply any fake/semi security solutions. In the case of web access there are 4 key issues that have to be resolved before a truly secure web interface can be created
- Browser and website vulnerabilities
- Danger of phishing
- Bad random generators
- Lack of code integrity protection
Many aspects of these issues have been addressed since 2011, but they are still major problems. Discussing all of them would make a single post way too long to read – so we broke it down into two parts. In part I. we discuss the first two, browser and website vulnerabilities and danger of phishing.
Why browsers and websites are vulnerable?
However browser developers are doing a great job of securing their applications, the pressure of continuously implementing new features results in an increasing number of security risks. According to Secunia, in 2013 there were 291 vulnerabilities in Chrome, 257 in Firefox and 41 in Internet Explorer. Browsing the CVE (Common Vulnerabilities and Exposures) databases, you can find several serious errors, even vulnerabilities which can result in an attacker running basically any software on your computer.
Browsers make the best targets: users visit unknown sites with the same applications they use to read company emails or post on Facebook. This means that one tiny leak in a browser can affect dozens of other systems. In addition, the web is full of non-conform or simply outdated sites – a good browser is supposed to display all of them. This means that even though newer standards may prevent security incidents, browsers must load ill-formed or old-standard sites as well.
What’s more, one of the most serious attack techniques, cross-site scripting (XSS), usually can’t be prevented simply by the browser (even if browsers are getting more and more smart on this area), the website’s developer must handle hardwire protection in the code) . This level of awareness is an unrealistic expectation.
Furthermore, browsers need to use several plugins, like Adobe Flash, Adobe Reader or Java. It is telling that IT security experts recommend not to use Flash or Java at all, and to block JavaScript on unknown sites. This is also not a simple issue. I do this on all of my devices, but my girlfriend went mad after about 2 minutes of using my computer.
Let’s be polite here and say that browsing is not such a great experience without those tons of plugins: absence of plugins results in a broken mess instead of a flashy and well-designed webpage that should appear with all those scripts running. I can imagine how users would just LOVE a browser that denies those extensions by default. If you haven’t tried before, experiment with NoScript and you will instantly see that today’s sites are full of scripts, and that seamless browsing is almost impossible without those extensions.
At Tresorit we want to give maximum security for our users. Offering a web application means that we should also consider all the risks mentioned above. The possibility that customers’ data could be targeted by an XSS or attack that we simply can’t prevent is very high.
Danger of phishing
Web phishing is a social engineering technique used to attack a system: hackers use innovative methods to get a user to visit a fake website, like sending a fake email or a chat message. They then try to steal sensitive information (passwords, credit card numbers, etc.) from the user by showing a fake copy of trusted sites like Facebook or PayPal and suggest a sign-in. Most of the time, users don’t even recognize that they are signing into a fake site, because after the attacker gets the password, they are redirected to the real site. Just an example: [http://grnail.com] can be misleading, especially displayed with one specific font.
There are several cases where hackers stole money with phishing sites. Making a website where we ask for your password means creating a possibility of becoming a victim of a phishing site. This is a hard decision, because we know that web access is a very important feature, especially in a cloud service.
In order to prevent becoming a phishing site victim, never click on links in strange emails, and check a site’s certificate (usually displayed as a ‘green bar’ next to the site’s address in the search tab) every time before entering sensitive information!
Nowadays, you can find more and more tools protecting you from phishing: browsers and mail clients check public phishing databases, and deny following fake links. But this works only if a phishing site was recognized, reported to the public databases, and if the user updated to the latest database
Find out more about the vulnerabilities of the web access! In the following post we are discussing two more issues that make web access vulnerable: bad random generators and lack of code integrity protection.
In a previous blog post we mentioned that Tresorit is committed to real security and we are working on making 100% sure we don’t put user data at risk. This time we are interested in your point of view: do you think we should make sacrifices to speed up the web access?
Let us know your opinion in the comments!
