Authentication & Authorisation Is the user allowed to access the site?

October 2012Web Programming2 Restricting access to a page ● Is the user who they say they are? – Did they enter the right username and password? ● Is the user (even if authenticated) allowed to access this page? – Some pages may only be for certain people

October 2012Web Programming3 Two basic methods ● The HTTP level – is user allowed to see this page? ● The server-side script code – is user allowed (e.g.) to access this database, or to access it in this way? – May have: ● UID and password for page ● UID and password for database ● They may be different (and are, for example, in my csmanagegames.php for the assignment)

October 2012Web Programming4 Server side possibilities 1)Everyone can see the page; server side script accesses the DB on user's behalf with a non-specific account (e.g. cs- guest) 2)Page is restricted; if page is accessed, assume it's OK to access DB (using a non-specific account) 3)Page access is not restricted, but you need to give a UID/password to access the DB (e.g. using a form) 4)Both page and DB access are restricted (unnecessary effort?)

October 2012Web Programming5 How it's done ● Systems tend to restrict page access but then allow free DB access (option 2) – Database passwords can then be in the script – But the identity of the person who accessed the database is more difficult to trace ● How I did it for csmanagegames.php was via one database account (mine!), but restricting to read only unless user was logged in to the page (with a session) – if statements to control who sees what

October 2012Web Programming6 Who is this user? ● The normal way for authenticating a user is UID/password ● Other technologies exist (e.g. new ones such as fingerprinting, iris scanning, etc); card readers for online banking ● Used with sessions to maintain a login (so user doesn't have to repeat password for each page)

October 2012Web Programming7 HTTP level authentication ● Response from server can be “401 Authorization required” – Has a “WWW-authenticate” header – browsers (normally) handle this by popping up a box ● Request can have an “Authorization” header field – details from the pop-up (UID/password) – If OK, server will send the page

October 2012Web Programming8 On Apache ●.htaccess file AuthType Basic AuthName "Personal stuff" AuthUserFile /aber/ais/myfriends Require valid-user

October 2012Web Programming9 Script based authentication ● Instead of relying on HTTP and browsers to request the authentication data, use a script ● Use an XHTML form ● Keep usernames and associated password in a database ● Database will typically have just two columns: user ID and password ● Passwords are normally encrypted to the database (see later for HTTPS)

October 2012Web Programming10 Script based authentication 2 1.Generate form page 2.Get UID and password (from POST method – don't use GET!) 3.Encrypt the password (PHP has functions to do this) SELECT username from passwordtable WHERE userid=givenuserid AND password=encryptedpassword

October 2012Web Programming11 HTTP authentication - pros/cons  Easy – just write a config file  Browsers provide standard prompting  Browsers remember passwords  Can only have one login at a time (that's all the HTTP headers will send) – not nested

October 2012Web Programming12 For high security Browsers remember passwords! This is a big problem where high security is required. There are two ways to overcome this ● – You're trusting the browser to recognise and obey the autocomplete attribute ● For top security, allow user to select from a dropdown menu – this will also help foil keyloggers, e.g. (next page)

October 2012Web Programming13 Top security for internet banking Using some sort of password field, plus a dropdown selection like this, gives about as good a security as possible

October 2012Web Programming14 Browsers remember other things too ● Like credit card numbers ● And account names – Even knowing a bank account number can be useful to a criminal, or... – Did you really want your partner to know that you had an account called “KinkySlaveboy” on some dodgy site? ● Use the autocomplete="off" attribute whenever appropriate

October 2012Web Programming15 Database authentication ● Not so important now, as we can restrict access to the scripts that access the database. ● But one warning: if your password is a string in your PHP code, other people might just manage to get to read it! – How? Consider exploits we've looked at before, or maybe simply looking over your shoulder when you're editing the script.

October 2012Web Programming16 IP restriction ● Server and server-side scripts can see the IP address of a request ● Can limit access on this basis – e.g. some BBC pages are restricted to IP addresses that are registered as being in the UK ● But hackers can get around this ● And genuine users may have a problem with their own machine, so try to use another

October 2012Web Programming17 Snooping ● Passwords must be in requests ● Authorisation field is not encrypted ● Form field data are not encrypted ● Answer: SSL; it's a secure and encrypted connection ● URLs use it – HTTP operates, but the messages are encrypted, checked for tampering and for known origin ● Details are a comms issue (i.e. not CS25010) – But if you're interested, check this: –