Authentication CS 4720 – Mobile Application Development CS 4720
System Security • Human: social engineering attacks • Physical: “steal the server itself” • Network: treat your server like a 2 year old • Operating System: the war continues • Application: just discussed • Database: protecting the data CS 4720 2
Application Level Security • Refers to security safeguards built into a particular application and operate independently from the network level security • Authentication • Authorization • Integrity / Confidentiality • Non-repudiation / Auditing CS 4720 3
Authentication • Verifying that the requester is the requester… • … and that the service is the service • This requires a mechanism of “proof of identity” • What are some ways accomplish this? • Username / password • Signed Certificates • Authentication Applications CS 4720 4
Authorization • Now that we know who you are, what are you allowed to do? • Permissions • Role-based security • How does this work in a database system? • How about an operating system? CS 4720 5
Integrity / Confidentiality • What happens if a message is: – Captured and reused? – Captured and modified? – Monitored as is passes by in a passive manner? • How do we verify a message hasn’t been tampered with? – Digital signature • How do we verify it hasn’t been viewed? – Encryption CS 4720 6
Non-repudiation / Auditing • When we’re charging to use a web service, how do we prove you used the service so we can charge you? • How do we track your activities? • Digitally signed logs, effectively • Also saves the certificate used to perform the transaction (like a signature on a receipt) CS 4720 7
User Management • Integrity / Confidentiality and Non-repudiation / Auditing are good things to consider for more complex apps, but probably don’t apply to your current projects • Most of you, however, want to have users login and be able to do different things • So Authentication and Authorization are important CS 4720 8
User Management • Let’s assume the simplest case – you want to have people login to your app • Options? – You could have local accounts coded in the app – Create usernames and passwords (we can do this in Firebase pretty easily, but you can also build your own webservice) – Use a third-party service for authentication (such as Google, Facebook, GitHub, etc.) CS 4720 9
Local Accounts • There may be good reasons to do something like this • Accounts stored in core data or a flat text file • You can create your own API • Good for multiple users on one device… • … but this is mobile, so how often does that happen? CS 4720 10
Build A Webservice • You can probably imagine a service that you could make using a database and Flight (or something else) that can return an authorization message if a username and password is correct • In this instance, users would still have to create accounts (or have them created for them), but you would have control CS 4720 11
Use an Authentication Service • We have probably all used one of the following to login to something OTHER than that service: – Google – Facebook – Twitter – GitHub • Even Netbadge! • How do these work? • Let’s start with Netbadge CS 4720 12
Netbadge Login System • Netbadge (or more accurately, PubCookie or Shiboleth) • http://www.pubcoo kie.org/docs/how- pubcookie- works.html CS 4720 13
OAUTH2 • The industry standard for this sort of token authentication is OAUTH2 • It is used in some form by all of the major login systems mentioned above • APIs can be slightly different, but the overall idea is the same • It looks similar to Netbadge, with a few more steps CS 4720 14
OAUTH2 Diagrams • http://tutorials.jenkov.com/oauth2/overview.h tml • https://developer.android.com/training/id- auth/authenticate.html • http://brentertainment.com/oauth2/ CS 4720 15
Example Code • https://github.com/googlesamples/google- services/tree/master/android/signin CS 4720 16
Authorization • Now that you know who the user is, what do they have the ability to do? • OAUTH2 can do some of this – Part of the protocol is to respond with a permission set – Useful if you want an app to login to Google and only have access to certain things – These things are noted when the login occurs CS 4720 17
Authorization • In your apps, you will most likely have user groups • Every user is given a certain set of permissions based upon their grouping – Such as student, faculty, admin, etc. • Permissions for each group are hardcoded into the app • Which group a user belongs to can be stored in a few different places CS 4720 18
Authorization • Example: – Menu ordering app – Customer user logs in and gets a screen to add items to cart – Server logs in and gets a list of tables they are serving – Cook logs in and gets a list of orders to prepare • Same login page and system but different functionalities are available CS 4720 19
Mobile Security • Questions to ask yourself as a developer: – Is the mobile backend as secure as the app itself? – Is data encrypted whenever and wherever it’s stored? – Does the app use HTTPS encryption – and enforce it? – Has the app binary been scrubbed of sensitive information? – Have steps been taken to thwart reverse engineering and analysis? CS 4720 20
Mobile Security • What are the “bad guys” after? CS 4720 21
Mobile Security • Personal data stored on the device – Not just name and address! – Passwords – Confidential documents – Financial information • Sensor data – GPS location (to track people) – Microphone / Camera (espionage) • False installs (for ad hits, for instance) CS 4720 22
Recommend
More recommend
