WEB APPLICATIONS A CLOSER LOOK User Authentication Content

User Authentication Generally uses forms, CGI (or similar application), DB, cookies Form: Enter user ID/password CGI: Connect to DB to process login DB: Holds user ID/password pairs (and optionally settings, etc. ) Cookies: Keeps track of session (keeps this user “connected”) Secure Sockets Layer (SSL) is used to keep information secure 3/19/2018 Uses encrypted “secret” key data to ensure only the specific client can understand the data being sent from the server and vice versa © 2006 Scott Miller, University of Victoria 2

Data Flow: User Authentication SMTP 3/19/2018 © 2006 Scott Miller, University of Victoria 3

User Authentication: Security Soft/Hard Lockouts Soft: After a few unsuccessful attempts, the user is temporarily locked out. Usually a warning is sent to the user before and at the lockout Hard: After a set amount of unsuccessful attempts, the user is “permanently” locked out. No warnings are sent to avoid “brute force” attacks Enforce “strong” passwords Definition of strong varies with source. Use numbers, capital and lowercase letters, punctuation or ascii characters, use 8+(or 10+) characters 3/19/2018 © 2006 Scott Miller, University of Victoria 4

User Authentication: Security Heuristic monitoring Statistical monitoring of user activity; alert system admins when “odd” activity occurs “Live” login protection No scripts to reset usernames/passwords Must authenticate with live help desk to login Usually a step in hard lockout protection Be aware of most current security issues, and permissions/holes 3/19/2018 Simple knowledge of what limitations in certain SW exist can help plug security holes © 2006 Scott Miller, University of Victoria 5

Content Generation Know your goals! All CG methods are based on trade-offs e. x. CGI: slow, but adequate for smaller sites SSI: limited, but better P/C JSP: Good combination of both, but VERY slow on first compile – more complicated PHP: Good support for DB, P/C, only good to about 20 users (scripting: interpretation slow) 3/19/2018 © 2006 Scott Miller, University of Victoria 6

Content Generation Performance Based on needs, cost, maintenance projections API vs. Full Custom Parse and Dispatch example ONLY for SERIOUS web traffic Heavily rely on DB Be familiar with DB (SQL, for example) to be able to make calls to generate content Remember: Content doesn’t consist of products, searches and logins Web based P 2 P applications Media Streaming Etc. © 2006 Scott Miller, University of 3/19/2018 Victoria 7

The Use of Cookies What do I probably bore you all the most with? STATE! Cookies maintain “state”* Cookies can be used in many ways Send many cookies to maintain lots of user info Send a unique key for a session and store all the user’s info/history/commands on the server side Send client side information and have the client generate user data to send as cookies to the server (ex. with Java. Script or complex client-side forms) Be creative! 3/19/2018 * If you © 2006 don’t know this, I may Scott Miller, University of Victoria cry at this point. Please don’t make me cry! 8

Cookies: Security Long-term vs. session based SSL, encryption, probability Hash based Single hash can be stolen Extra “hidden” information could help – hard to implement Visibility HTTP is text based Realms = paths: Remember how to assign security to each different application/resource you are running 3/19/2018 © 2006 Scott Miller, University of Victoria 9

Cookies: Theft or Borrowing Cookies were used as original spy-ware Large pages keep track of all searches, web history to sell to marketing corporations Targeted banner ads Banner payout protection Targeted searches to save actual processing or bandwidth Old Infoseek: Attempt to use your browsing habits (heuristics) to predict future searches Very limiting on “true” searching Same principle as marketeering 3/19/2018 © 2006 Scott Miller, University of Victoria 10

Content Pooling Used for integrating and swapping content with other sites, domains or applications Sites/Domains: Used to retrieve fresh content Partner sites Media Applications: Share content between different applications, local domains, etc. Can be used to make sites more efficient 3/19/2018 © 2006 Scott Miller, University of Victoria 11

Content Pooling: Efficiency Can use one large database for many different web applications Can break content “workload” into smaller slices and dynamically call running slices Pool content of different applications/local sites to save space, individual calls Pool same database by smaller running pieces Can distribute or centralize workload Have 1 database for logins to multiple applications on 1 site Have each different slice of a database on a different server (CPU load distribution): Share all content as if in same DB 3/19/2018 © 2006 Scott Miller, University of Victoria 12

Unrelated note: Info for Lab 6 Cookies: If you want to have a cookie deleted or ignored, you can do the following: Add a cookie the regular way with response. add. Cookie(Cookie) Set the Cookie to delete in the following way Cookie deleteme = new Cookie (“name”, “”); deleteme. set. Max. Age(0); response. add. Cookie(deleteme); 3/19/2018 © 2006 Scott Miller, University of Victoria 13

Reading for Next Class Practice your content for the course Look over code Look over theory Understand the system (1 system) we’ve gone over the entire semestre! Work on Assignment 3 and Lab 5/6! NEXT CLASS: Databases 3/19/2018 © 2006 Scott Miller, University of Victoria 14