1 of 21

Authorization

CS 4720 - Mobile Application Development

​

​

CS 4720

2 of 21

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

3 of 21

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

4 of 21

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

5 of 21

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

6 of 21

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

7 of 21

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

8 of 21

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

9 of 21

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 web service)
    • Use a third-party service for authentication (such as Google, Facebook, GitHub, etc.)

​

CS 4720

10 of 21

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

11 of 21

Build a Web Service

  • 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

12 of 21

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

13 of 21

Netbadge Login System

  • Netbadge (or more accurately, PubCookie or Shibboleth)
  • http://www.pubcookie.org/docs/how-pubcookie-works.html

CS 4720

14 of 21

OAUTH2

  • The industry standard for this sort of token authorization 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
  • AND it’s AUTHORIZATION not AUTHENTICATION
  • If you want authentication, use OpenID Connect

CS 4720

15 of 21

OAUTH2 Diagrams

CS 4720

16 of 21

Example Code

​

CS 4720

17 of 21

Authorization

  • Now that you know who the user is, what do they have the ability to do?
  • OAUTH2
    • 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

18 of 21

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

19 of 21

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

20 of 21

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?
  • What are the “bad guys” actually after?

CS 4720

21 of 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