LOGIN FORMS

Key points for login User wants to access some webpage X – But we only want logged in users to access X – Server checks session & sees user isn't logged in So the server directs the user to a login form – The user submits a username and password – Server verifies these are legitimate – Server updates session to show user is logged in – Server allows the user to get to X

Basic login flow Browser Page X Database Click link Username & password Sry, log in, bro Check session Enter info Check if it's legit Here it is Login page Give me X Ok, give me the login form Update session Ok, you can go to X now Give me X Here it is

Notice Page X is defending itself – It has to check whether the user is logged in – It does this by looking in the session Is $_SESSION["uid"] set and not empty? – If the user isn't logged in, then redirect to login – Page X has to pass along a note to the login form So that the login form knows to redirect user back to X after the user enters valid username and password

Login form requirements The login form must... 1.Accept a URL where the user will be sent after logging in (i.e., page X) 2.Gather credentials (username and password) 3.Check that the credentials are valid 4.Record some sort of information indicating that the user is now logged in 5.Redirect the user to the desired spot (X)

Different login options Use the OSU Central Authentication Service Create a custom login form of your own Use another 3 rd party authentication service

OSU Central Authentication Service (CAS) Documentation: If user's session indicates not logged in { – Compute current URL (X) – Redirect user to CAS; pass current URL as param. } When CAS sends user back to X { – Retrieve the "ticket" that CAS sends back – Check what ONID account goes with that ticket – Mark the user's session as logged in }

CAS login flow Browser Page X CAS/ONID Database Click link Username & password Sry, log in, bro Check session Enter info Check if it's legit Here it is CAS Give me X Ok, give me the login form Create a ticket Ok, you can go to X?ticket=xyz now Give me X?ticket=xyz Here it is Verify ticket Update session

Let's walk through a site skeleton Browse at Download from Good about this skeleton: Simple site structure, has database, authenticates with OSU CAS Bad about this skeleton: Still same page title on every page; still needs input validation

About that site skeleton (3) All the pages include _header.php This PHP provides a checkAuth() function – Returns the user's ONID username Either by finding it in the session (if logged in) OR by retrieving the ONID username with a ticket OR by redirecting the user to log in, which will generate a ticket The add_course.php page is defending itself – So "Page X" is add_course.php in this example

About the key lines of code Remember to start the session… must be the very 1 st line session_start(); Checking if the user is logged in if (isset($_SESSION["onidid"]) && $_SESSION["onidid"] != "") Getting the current URL " $_SERVER["SERVER_NAME"].$_SERVER["SCRIPT_NAME"] Redirecting to the CAS login form $url = " echo " location.replace('". $url. "'); "; Server-to-server connection (to check ticket when user comes back from login) $html = file_get_contents($url); Grabbing substring between and $pattern = '/\\ ([a-zA-Z0-9]+)\\ /'; preg_match($pattern, $html, $matches); if ($matches && count($matches) > 1) $onidid = $matches[1];

Caveats about using CAS If you use CAS, then 1.OSU could pretend to be a certain user They control the login form They can make it say whatever they want So it could say "joesmith" even if it's not the real user 2.Nobody can log into your site if CAS crashes 3.Your site either has to be running on another OSU server, or you need to establish an agreement with the CAS admins

Next option: Custom login form More complicated in some ways than CAS – You have to create a login form – And you have to create a registration form – You also handle storage & lookup of credentials This means securely storing passwords – Hashing is mandatory (we'll cover in a moment) – Now init.php also creates a "users" table

Login flow with your own form Browser Page X Your Database Click link Username & password Sry, log in, bro Check session Enter info Check if it's legit Here it is Your login form Give me X Ok, give me the login form Update session Ok, you can go to X now Give me X Here it is Check session

Let's walk through a site skeleton Browse at Download from Good about this skeleton: Simple site structure, has database that stores user credentials Bad about this skeleton: Still same page title on every page; still needs input validation

About that site skeleton (4) All the pages include _header.php This PHP provides a checkAuth() function – Returns the user's uid Either by finding it in the session (if logged in) OR by redirecting user to login.php – This uid is a primary key in our own "users" table The add_course.php page still defends itself – So "Page X" is add_course.php in this example And now we also have an add_user.php – So that the user can register – This page does NOT require user to log in first

About the key lines of code for setting up a table, storing passwords Creating a table with auto-assigned primary key to store our users create table users(uid integer NOT NULL AUTO_INCREMENT, username varchar(64), password varchar(512), primary key(uid) ) Checking if username is taken $query = $mysqli->prepare("select uid from users where username = ?"); $query->bind_param("s",$username); if ($query->execute()) { $query->bind_result($uid); if ($query->fetch()) /* then username is already taken… display an error */ … Hashing a password before storing it in the database $hashedPassword = base64_encode(hash('sha256',$password. $username)); if ($stmt = $mysqli->prepare("insert into users(username,password) values(?,?)")) { $stmt->bind_param("ss", $username, $hashedPassword); $stmt->execute(); …

About the key lines of code for redirecting to login & authenticating Remember to start the session… must be the very 1 st line session_start(); Checking if the user is logged in if (isset($_SESSION["uid"]) && $_SESSION["uid"] != "") Getting the current URL " $_SERVER["SERVER_NAME"].$_SERVER["SCRIPT_NAME"] Redirecting to our own login form $currentUrl = currentUrl(); $urlOfLogin = "login.php?sendBackTo=".rawurlencode($currentUrl)."&cb=".microtime(true); echo " location.replace('$urlOfLogin'); "; Retrieving the uid for a given username and password $hashedPassword = base64_encode(hash('sha256',$password. $username)); $query = $mysqli->prepare("select uid from users where username = ? and password = ?"); $query->bind_param("ss",$username, $hashedPassword); if ($query->execute()) { $query->bind_result($uid); while($query->fetch()) $_SESSION["uid"] = $uid; …

How does hashing work? Hashing basically trashes data in a reproducible, mostly unique, and irreversible way – Reproducible: The hash of "Big Bird" is garbage, but it's always the same garbage. – Mostly unique: The hash of "Oscar" is also garbage, but it's different garbage than the hash of "Big Bird" – Irreversible: Somebody who sees a certain hash is essentially unable to tell if it came from "Big Bird" or from "Oscar"

Consequences of hashing Irreversibility – Even if somebody steals the database, it's impossible to recover the passwords Uniqueness – If the password the server is expecting is abc, then entering def won't generate the same hash Meaning people can't log in with the wrong password Reproducibility – If a certain password is used to create an account, then the same password can be used to log in.

Other 3 rd party services: Generally fairly similar to CAS If user's session indicates not logged in { – Compute current URL (X) – Redirect user to 3 rd party; pass current URL } When 3 rd party sends user back to X { – Retrieve a token of some sort (like a "ticket") – Check what account goes with that token – Mark the user's session as logged in }

Generic 3 rd party login flow Browser Page X User database Click link Username & password Sry, log in, bro Check session Enter info Check if it's legit Here it is 3 rd party Give me X Ok, give me the login form Create token Ok, you can go to X now (with token) Give me X (with token) Here it is Verify token Update session

Caveats about using 3 rd party If you use 3 rd party, then 1.3 rd party could pretend to be a certain user They control the login form They can make it say whatever they want So it could say "joesmith" even if it's not the real user 2.Nobody can log into your site if 3 rd party crashes 3.Users might get confused about why they're being asked to log into 3 rd party site "Why is this website asking me for my Google password? It must be a scam!"

Additional notes about 3 rd party Some 3 rd party services require you to write JavaScript and also server-side code (e.g., Google) The login form (or a button for it) appears inside your own web page You have to write JavaScript that gets called when the user has logged in (i.e., the callback is to a JS function, rather than a redirect) – In your JavaScript, you get your hands on a token id – And then your JavaScript sends this token id to your server Then you also have to write server-side code (PHP) to do a server-to-server connection to check the token – Analogous to checking a CAS ticket

Tradeoffs CAS (OSU ONID)Custom login3 rd party Each page X has to defend itself XXX Redirect to a login form, redirect back XXX You have to hash passwords X You have to implement a login form X You have to implement a register form X You can only run your site on an OSU server (or set up separate agreement) X OSU could pretend to be a user X You have to do a server-to-server call XX 3 rd party could pretend to be a user X Potential risk of user confusion due to appearance of 3 rd party login form X You may have to write a lot of JavaScript X