Secunia CSI7
About us
Careers
Memberships
Newsroom
Contact us
Blog
News
Articles

Designing security without security in mind...

Get this blog as an RSS Feed
Normally, we spend our time buried in deeply technical analyses of vulnerabilities, but that doesn't prevent us from enjoying the simple things in life like when a vendor designs a security feature completely without considering the "security" aspect of it.
15:56 CET on the 6th May 2010
Entry written by Carsten Eiram.

Normally, we spend our time buried in deeply technical analyses of vulnerabilities, but that doesn't prevent us from enjoying the simple things in life like when a vendor designs a security feature completely without considering the "security" aspect of it.

This morning, I was talking to a co-worker outside the Secunia Research department. He had just bought a shiny, new Google Android-based HTC Desire cellular phone and was quite excited about the gadget and all the stuff it could be used for. Cell phones have come a long way and are sometimes even invaluable tools in companies for keeping track of ones contacts and schedule as well as storing various personal and business sensitive information.

Considering all the valuable information stored on such devices, one would hope that they were developed with security in mind to e.g. prevent people from gaining unauthorised access; it should at least be a worthy challenge.

When seeing the "connect the dots" screen-lock feature used for preventing access to the device, it immediately seemed like the idea failed on so many levels. For people, who are not familiar with how this works (including myself about a couple of hours ago), the screen-lock presents you with 9 dots with three rows of dots, having three dots in each row. To gain access, the user has to correctly connect the dots.

This happy owner is by no means a security unconscious person so he had actually given the correct combination (or "unlock pattern" as it's called) some thought. While the combination has to at least consist of four dots, it is, unfortunately, not possible to re-use a dot. This seriously reduces the number of different ways of connecting the dots. Considering most right-handed would start drawing from the left-hand side and most users would pick a gesture that "lies in the wrist", it didn't seem unlikely to gain access without too much of a hassle; it took only five tries...

After a bit of gloating, I was ready for round two to try out a couple of other ideas for gaining access in a straight-forward manner.

This time, I didn't even worry about going for a "brute-force" approach (if casually dragging your finger over a screen can be considered brute force). Instead, I looked at the screen and took note of the smudge marks. Normal use is to press the screen, dragging upwards and downwards, or dragging from side to side. There is a good chance that any other smudge marks may be from the unlock pattern - especially if the user only briefly used it to e.g. make a call before locking it again. It proved to be a simple, but effective approach for gaining access as well. Don't forget to wipe off the screen after use!

The last approach may have limited effectiveness in real life, but was sweet nonetheless and implemented a bit of psychology to unconsciously make the user give me his "password". For this one I needed a new prey and quickly found one. Instead of immediately throwing myself at the phone, I faked interest in how it worked and upon being presented with the screen-lock, I casually asked how it worked. The phone's owner answered: "Oh, you just have to connect the right dots" while unconsciously making a gesture with a finger, matching his unlock pattern. Afterwards, I bet him that I would be able to access his phone, which he didn't believe that I could - he was wrong.

Ultimately, this is a perfect case of a vendor designing a feature (even a security mechanism), but thinking more about the "gimmick factor" than security. We often focus on really elaborate, technical schemes to bypass security mechanisms, but sometimes there may be an awfully simple approach.

In this case, the idea of a unlock pattern screen-lock may not be all that bad. However, it should at least allow re-use of dots and preferably also support separate dot presses instead of just dot connecting to ensure a reasonable number of combinations.

Stay Secure,

Carsten Eiram
Chief Security Specialist

Discuss this blog entry
A new thread in our forum is created. Activate the thread by commenting/discussing below.
Subject: Designing security without security in mind...
 
User Message
thedillpickl RE: Designing security without security in mind...
Contributor 21st May, 2010 08:02
Score: 376
Posts: 872
User Since: 3rd May 2009
System Score: 100%
Location: US
Last edited on 21st May, 2010 08:02
A very eye opening report. One would think that a company producing such an advanced device might have spent a few R&D dollars (or what have you) on this feature.

Security passwords have long been a point of contention. Risk Management wants the password to be no less than twenty three characters, a minimum of ten to be numbers or special characters. The user wants to use the password 'fluffy' because that's their cats name. So who's right?

Of course the first point of security would be to prevent access to the device physically. But things do seem to happen, don't they.

And Carsten, please stay away from my sensitive material!


regards;

Fred

--
XP Home
Chrome, Firefox, IE8
--
consilio et animis
Was this reply relevant?
+3
-0

-

You must be logged in to post a comment.



 Products Solutions Customers Partner Resources Company
 
 Corporate
Vulnerability Intelligence Manager (VIM)
Corporate Software Inspector (CSI)
Consumer
Personal Software Inspector (PSI)
Online Software Inspector (OSI)
 Industry
Compliance
Technology
Integration
 Customers
Testimonials
 VARS
MSSP
Technology Partners
References
 Factsheets
Reports
Webinars
Events
 About us
Careers
Memberships
Newsroom


 
© 2002-2014 Secunia ApS - Rued Langgaards Vej 8, 4th floor, DK-2300 Copenhagen, Denmark - +45 7020 5144
Terms & Conditions and Copyright - Privacy - Report Vulnerability