10/20/2015 ©2006 Scott Miller, University of Victoria 1 User Authentication Content Generation The Use of Cookies Content Pooling Rev 1.5

 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  Uses encrypted “secret” key data to ensure only the specific client can understand the data being sent from the server and vice versa 10/20/2015 ©2006 Scott Miller, University of Victoria 2

10/20/2015 ©2006 Scott Miller, University of Victoria 3 SMTP

 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 10/20/2015 ©2006 Scott Miller, University of Victoria 4

 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  Simple knowledge of what limitations in certain SW exist can help plug security holes 10/20/2015 ©2006 Scott Miller, University of Victoria 5

 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) 10/20/2015 ©2006 Scott Miller, University of Victoria 6

 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 P2P applications  Media Streaming  Etc. 10/20/2015 ©2006 Scott Miller, University of Victoria 7

 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 JavaScript or complex client-side forms)  Be creative! * If you don’t know this, I may cry at this point. Please don’t make me cry! 10/20/2015 ©2006 Scott Miller, University of Victoria 8

 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 10/20/2015 ©2006 Scott Miller, University of Victoria 9

 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 10/20/2015 ©2006 Scott Miller, University of Victoria 10

 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 10/20/2015 ©2006 Scott Miller, University of Victoria 11

 Can use one large database for many different web applications  Pool content of different applications/local sites to save space, individual calls  Can break content “workload” into smaller slices and dynamically call running slices  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 10/20/2015 ©2006 Scott Miller, University of Victoria 12

 Cookies:  If you want to have a cookie deleted or ignored, you can do the following:  Add a cookie the regular way with response.addCookie(Cookie)  Set the Cookie to delete in the following way  Cookie deleteme = new Cookie (“name”, “”);  deleteme.setMaxAge(0);  response.addCookie(deleteme); 10/20/2015 ©2006 Scott Miller, University of Victoria 13

 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 10/20/2015 ©2006 Scott Miller, University of Victoria 14