LOGIN FORMS http www flickr comphotostorkildr3462607995 Key points

LOGIN FORMS http: //www. flickr. com/photos/torkildr/3462607995/

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 Click link Login page Page X Database Give me X Check session Sry, log in, bro Ok, give me the login form Here it is Enter info Username & password Check if it's legit 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: http: //onid. oregonstate. edu/docs/technical/cas. shtml • 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 Click link Page X CAS/ONID Database CAS Give me X Check session Sry, log in, bro Ok, give me the login form Here it is Enter info Username & password Check if it's legit Create a ticket Ok, you can go to X? ticket=xyz now Give me X? ticket=xyz Verify ticket Update session Here it is

Let's walk through a site skeleton Browse at http: //web. engr. oregonstate. edu/~scaffidc/courses/cs 290/skeleton 3 Download from http: //web. engr. oregonstate. edu/~scaffidc/courses/cs 290/lectures/site_skeleton 3. zip 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 check. Auth() 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 "http: //". $_SERVER["SERVER_NAME"]. $_SERVER["SCRIPT_NAME"] • Redirecting to the CAS login form $url = "https: //login. oregonstate. edu/cas/login? service=". $page. URL; echo "<script>location. replace('". $url. "'); </script>"; • Server-to-server connection (to check ticket when user comes back from login) $html = file_get_contents($url); • Grabbing substring between <cas: user> and </cas: user> $pattern = '/\<cas\: user\>([a-z. A-Z 0 -9]+)\<\/cas\: user\>/'; 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 Click link Your login form Page X Your Database Give me X Check session Sry, log in, bro Ok, give me the login form Here it is Enter info Username & password Check if it's legit Update session Ok, you can go to X now Give me X Check session Here it is

Let's walk through a site skeleton Browse at http: //web. engr. oregonstate. edu/~scaffidc/courses/cs 290/skeleton 4 Download from http: //web. engr. oregonstate. edu/~scaffidc/courses/cs 290/lectures/site_skeleton 4. zip 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 check. Auth() 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 $hashed. Password = base 64_encode(hash('sha 256', $password. $username)); if ($stmt = $mysqli->prepare("insert into users(username, password) values(? , ? )")) { $stmt->bind_param("ss", $username, $hashed. Password); $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 "http: //". $_SERVER["SERVER_NAME"]. $_SERVER["SCRIPT_NAME"] • Redirecting to our own login form $current. Url = current. Url(); $url. Of. Login = "login. php? send. Back. To=". rawurlencode($current. Url). "&cb=". microtime(true); echo "<script>location. replace('$url. Of. Login'); </script>"; • Retrieving the uid for a given username and password $hashed. Password = base 64_encode(hash('sha 256', $password. $username)); $query = $mysqli->prepare("select uid from users where username = ? and password = ? "); $query->bind_param("ss", $username, $hashed. Password); 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 Click link Page X 3 rd party User database Give me X Check session Sry, log in, bro Ok, give me the login form Here it is Enter info Username & password Check if it's legit Create token Ok, you can go to X now (with token) Give me X (with token) Verify token Update session Here it is

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 Java. Script 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 Java. Script that gets called when the user has logged in (i. e. , the callback is to a JS function, rather than a redirect) – In your Java. Script, you get your hands on a token id – And then your Java. Script 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 login 3 rd party Each page X has to defend itself X X X Redirect to a login form, redirect back X X X 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 X X 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 Java. Script X