How Can We Prevent Network Security Problems in Smartphone Apps?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.21036/LTPUB10054 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Mobile appWebsiteInformation privacySoftware developerWeb browserCellular automatonRule of inferenceDifferent (Kate Ryan album)SmartphoneTelecommunicationSoftwareAmsterdam Ordnance DatumTelebankingInternetworkingInformation securityShift operatorProgramming paradigmGroup actionSlide ruleCodeInteractive televisionWeb applicationLecture/ConferenceMeeting/Interview
01:17
CodeComputer scienceInformation securityVirtual machineMereologyMathematical analysisSoftware developerRootMobile appGroup actionAdditionLecture/ConferenceMeeting/Interview
02:48
Rule of inferenceCodeExtension (kinesiology)Software developerInternetworkingMobile appComplex (psychology)Information securityCausalityView (database)Android (robot)SoftwareRange (statistics)Process (computing)TelecommunicationLevel (video gaming)Personal digital assistantDifferent (Kate Ryan album)Physical systemWordError messageEncryptionoutputLecture/ConferenceMeeting/Interview
04:28
Computer programmingMereologyLevel (video gaming)Software developerComputing platformNumberInformation securityInteractive televisionCodeUtility softwareMobile appPattern languageInterface (computing)SoftwareCentralizer and normalizerStress (mechanics)DataflowOnline helpUsabilityLecture/ConferenceMeeting/Interview
06:17
Expert systemStudent's t-testSoftware testingInformation securityObservational studyFocus (optics)Forcing (mathematics)Vector potentialSound effectFeedbackSoftware developerTerm (mathematics)Level (video gaming)GoogolMechanism designNear-ringPublic domainSign (mathematics)EmailOpen sourceDivisorComputing platformPasswordScaling (geometry)Vulnerability (computing)UsabilityField (computer science)Heegaard splittingInformation privacyService (economics)Lecture/Conference
Transcript: English(auto-generated)
00:00
Our research question was how do we need to rethink SSL development in an appified world. We discovered large-scale problems with the network security of many apps and this is particularly relevant because there's been a paradigm shift from browser-based interaction with internet to smartphone-based interaction with the internet.
00:21
We have an app for everything and these app contain lots of personal details so we have online banking app which contain the credentials to our accounts, we have social networking apps which contain our private data, we have medical apps. Everything has an app and unlike in the browser world where
00:40
there are dedicated teams creating the security software for the communication between the browser and the website, apps are developed by thousands of different developers who now all have to deal with the network security code and we found that there are a lot of problems there. 20% of the Android apps
01:01
which tried to use SSL to secure their network communication failed in doing so and actually created insecure apps. In this slide our question was why do these problems occur and how can we prevent them from occurring in the future. The approach we use to analyze this problem is split into two
01:20
parts. We have the classical part where we did a empirical analysis of the code so we downloaded 13,500 apps and sat down ourselves and looked at the code which was going wrong and this is the kind of the traditional computer science way of doing things. You look at the code and you try and figure out
01:41
where the problems are and you try and fix them. Now my research group is mainly interested in the human aspects of IT security so the second part is the more unusual part where we actually contacted the developers to find out why things went wrong on the human side. We contacted roughly 80 developers who we had identified in our previous analysis that they had done
02:04
something wrong and asked them if we could talk to them. We would inform them about the security problems their apps had and asked if they were willing to give us an interview so we could try and figure out why things have gone wrong. Now the majority of the developers had to turn down our request
02:24
many of them citing legal reasons so we'd get answers like we'd love to talk to you guys but our legal department says we're not allowed to. In the end we had 14 developers who agreed to do interviews with us and we talked to them about the problems we'd found in their code and then tried to
02:41
figure out the root causes which had led to them including this insecure code in their apps. The key findings of our research were that the problems creating secure network code are independent of skill level of the developers. We had a whole range of different skill levels in our interviewees so everything
03:04
from developers who were creating their very first app to expert developers with a security background. In the case of the novice developers we got answers such as this was the first app we were building, we found this problem in our code, we googled it and we copy and pasted the first solution
03:21
we found off the internet that made the error go away and we thought we were good. They didn't know that the solution they found on the internet was actually insecure. But we also had expert developers who were expert enough to actually analyze network traffic and to correctly identify the fact that their app was communicating with encryption but they did not
03:42
understand the problem to the extent that they would actually see that this encryption was insecure because an attacker could remove it on the network side and not in the app side. This is a really interesting finding because the traditional view is if we educate developers enough then they won't make mistakes and we quite clearly saw here that even expert
04:02
developers do not understand the full complexity of this process of securing the network communication using SSL and that led us to the conclusion that it's not the developers fault, it is the system which is too complex. So the whole process of creating a secure network communication on Android and on
04:20
iOS was so complex that if developers felt they had to modify it they got it wrong in too many cases. The relevance of our work is again split into two parts. The first part is again the traditional part. We found a very huge number of very serious security flaws and that is of course a very central
04:43
role of security researchers. We uncover flaws, we inform the people of these flaws and help them get them fixed. So hopefully through our work millions and millions of people will be protected when using apps and that of course is one of our main goals. On the human aspect side the relevance is
05:03
that we are now pushing for a global rethinking of how we interact with security code. We found that developers aren't infallible. Now this does sound kind of obvious when stated like that but it is something which has not
05:21
really gained much traction in the IT industry. We still expect the people who code to be so good they don't make mistakes and we think that platform developers have to consider the human aspects of their developers so they need to talk to them before they write the platform code. So they need to figure
05:40
out what are the requirements of the developers who were using the software and if they get those requirements down and then try and optimize the usability of their programming APIs, application programming interfaces which is one of the interaction patterns we use when offering software to developers. If they increase the usability of these many of the security
06:04
problems we see today would never even occur because the developers don't get the chance to make the mistakes anymore. They are making when the platform is just developed on a pure technical level without taking the human aspects into account. The future work I see in our research again is
06:21
split into two parts. We have the near-term goal of discussing these findings with platform developers such as Google, Microsoft, Blackberry and getting them to talk with their developers and get their feedback in an early stage of the platform development as this has been shown to increase the usability
06:43
and the security of the platform. On a more longer term view the really interesting thing is that this is a very new way of approaching IT development. My research domain is usable security and privacy and the main focus of this research domain has always been the end user because it has been
07:03
believed that the end user is the one who needs the most help. We all know that people click away the warnings, they open emails they shouldn't open and they choose insecure passwords. So researchers in this domain have focused on the human aspects of why do people choose weak passwords, how can we make
07:20
them choose better passwords and this is an interdisciplinary science. We have psychologists, sociologists, economists who all work together looking at the human factors of why security goes wrong for the end users. The methodology used there is quite simple. We do user studies and we do
07:40
them at a large scale. So we use services like Mechanical Turk on Amazon or Craigslist or recruiting students and then we'll have ideas and test them with hundreds if not thousands of users to then be able to also quantify the effects of our research ideas. This isn't possible with developers in
08:01
the same way because you can't just recruit a thousand developers and have them try something out. We struggle to find 14 for interviews and this creates a lot of challenges on the methods side where I see a lot of potential for collaborating with scientists from other disciplines who
08:20
maybe have similar problems of having to study subjects who aren't as easily available as students. That is something where we'll be investing a lot of work trying to figure out how we can actually study these experts who aren't as easily recruited, who aren't easily fooled into believing the studies about something else so you can't kind of pretend it's not about security. So you
08:41
have all these kind of biases which we didn't have to deal with up to now but now are becoming relevant so that's a very interesting field of future research for us.