(4) Trust and Security on the Web

• Web-based applications introduce many risks
  • do you trust your browser? (it may not safeguard your information)
  • do you trust your computer? (it may have a virus)
  • do you trust your network? (it may be monitored on various levels)
  • do you trust the server? (it may be a fake phishing [http://en.wikipedia.org/wiki/Phishing] server)
  • who do you trust, regarding what, and why? and what does it mean?
• Most of these risks are amplified by the Web's scale
  • phishing and spamming only work because the Web makes fraud more effective
• Controlling Web access is important for safe browsing
  • trusting shared browsers is risky (they may store logins and cache pages)
  • trusting the network can be risky (more and more networks are wire-tapped)
  • trusting the server is risky (phishing and poor server security)

(5) Privacy Options

(6) Security Options

(7) Encryption Options

(9) Secure Communications

• Public-Key cryptography [Security Mechanisms; Public-Key Cryptography (1)] is computationally expensive
  • it is possible to encrypt all traffic using asymmetric key pairs
  • this generates considerably more load on the server side
• Combining public-key [Security Mechanisms; Public-Key Cryptography (1)] and secret-key [Security Mechanisms; Secret-Key Cryptography (1)] cryptography
  1. check the public key for authenticity (using a Certificate [Security Mechanisms; Certificate (1)])
  2. generate a key for a symmetric encryption scheme
  3. use the public key to securely transmit the generated key
  4. use the generated key for securely transmitting the payload
• Combines the advantages of both methods
  • the ability of public-key algorithms to work without a secure channel (handshake)
  • the lower complexity of secret-key algorithms (record layer)

(10) HTTP and Security

• HTTP sends clear-text messages
• Making HTTP secure requires additional mechanisms
• Encryption is done by a layer on top of TCP
  • Secure Sockets Layer (SSL) is the protocol layer invented by Netscape
  • Transport Layer Security (TLS) is the standardized Internet version
  • TLS adds more encryption schemes and more flexibility
• Lower-level methods may also provide encryption
  • Virtual Private Networks (VPN) provide IP-based encryption
  • WEP and WPA provide network interface encryption
  • lower-level methods typically are not end-to-end (i.e., browser/server)

(11) HTTP and SSL

(12) Preconfigured Trust

• Clients have a long list of pre-installed root certificates
  • who is managing HTTP/HTTPS/SSL/TLS? the client application or the device?
• A Certification Authority (CA) can issue trusted certificates
  • there is no real definition of what a CA is supposed to do
  • CAs may have the right to delegate CA status to other CAs
  • CAs may have different levels of certificates
• Updated CA lists often are part of system or browser updates
  • Microsoft and Apple include CA lists in system updates
  • 3rd party browsers sometimes manage their own CA lists

(13) Certificates in Firefox

(14) Certificates in Opera

(15) Certificates in Windows (i.e., IE/Safari/Chrome)

(17) Web Application Security

• Browsers are supposed to provide a safe sandbox
  • broken code cannot harm the computer
  • malicious code cannot steal data from the computer
  • malicious code cannot steal data from other sites
• Browsers should not be able to lie to their users
  • the address bar shows users what they are looking at
  • the lock icon allows users to inspect security
• Introducing trusted 3rd parties in this scenario is not easy
  • any form of external site verification [http://www.verisign.com/trust-seal/faq/index.html] can easily be forged
  • the Web guarantees connectivity to a site and not a well-behaving site

(18) Trusted Computing

• Developed to avoid the threats of malware
  • programs must be signed before they can be executed
  • basic procedures are built into the hardware of the computer
  • it is impossible for such a computer to execute untrusted code
• Often data storage also is managed cryptographically
  • only trusted code gets access to managed data
  • data is never stored unencrypted and thus cannot be easily stolen
  • security vs. convenience and lock-in are important questions
• Digital Rights Management (DRM) was also pulled into the platform
  • content owners would have much better control over content use

(19) Native Application Security

• The return of the trusted computing platform
  • Apple's iPhone implements what Microsoft dreamed of 10 years ago
• Only software submitted to and verified by Apple can be executed
  1. signing up as a developer creates an identity verified by Apple
  2. submitting an application means that it is signed with that identity
  3. accepting the application means that Apple is signing with its identity
  4. software installation only works with signed installation packages
• Jailbreaking the iPhone is disabling this authentication chain
  • applications need not to be signed by Apple anymore
• Android has a simple user setting to allow unsigned applications
  • installation packages do not have to be signed at all

(21) Open Authentication

• Applications often use resources from a variety of sources
  • browser-based applications often are called mash-ups
  • server-based applications might be called mash-apps
• Browser-based applications might run into browser restrictions
  • JSONP [Cross Site Scripting (XSS); JSON with padding (JSONP) (1)] is one way to get around browser restrictions
  • setting up proxies is another way for achieving the same goal
• Access control for 3rd party resources is a common scenario
  • granting access without revealing the access credentials
  • give them a token instead of giving them credentials

(22) Delegation vs. Federation

• Delegated Authentication allows services to delegate authentication
  • services delegate user authentication to other services
  • the set of authentication services often is small and fixed
• Federated Authentication allows services to share identities
  • authentication is done locally but the account information is openly available
• Credit card procedures provide real-world examples for both methods
  • using generic cards is federated: stores accept payments when approved by Visa
  • using branded cards is delegated: cards have to be authenticated by the brand
• OpenID is a popular federated authentication scheme
  • it's actually open identification and not all implementations are federated

(23) OAuth Control Flow

(24) OAuth Process

• OAuth supports the 3-legged authentication scenario
  • users are interacting with applications
  • service providers are providing access-controlled resources
  • consumers need access to the resources on behalf of the user
• OAuth uses a scheme with redirects and authentication tokens
  1. users access the consumer who then need access to the service provider
  2. consumers get a request token from the provider
  3. consumers redirect the user to the service provider
  4. users authenticate with the provider based on the request token
  5. successful authentication means that the access token is marked
  6. the user is redirected back to the URI provided in the first redirect
  7. the consumer exchanges the request token into an access token
  8. the type of access allowed by the token is controlled by the provider