Security

1
Security Authentication

• There are applications, where there is no need
  for user authentication for normal users
• E.g. Local bus timetable service.
• Sometimes we do transactions with private or
  financial data or just want to know who the user
  is.
• Need for user authentication.
• Need for secure transactions
• Similarly, the bus timetables cannot be updated
  by just anyone.
• We shall first review some principles and basic
  knowledge.
• Then we go on to explore some practical issues
  related to authentication and sessions on the
  level, which we can also try out with PHP.

2
Keys

• Keys are the basis for encryption.
• They can be used for - identification, -
  encryption, - signatures,- message integrity,
  - and certificates.
• We will skip the mathematics and only explain how
  the keys can be used.

3
Using a secret key -General

• Messages are encrypted using a secret key known
  for both parties.
• Problem How can both parties get to know the
  secret key whilst keeping it secret?
• The sender encrypts the message using an
  algorithm (which may be publicly well know) and
  the secret key (which is secret, as the name
  implies)
• The recipient decrypts the message using a
  well-known algorithm and the secret key (of
  course, the algorithms must be matching).

4
Using a private/public key pair - General

• Each communicating agent has a private key, only
  known to herself, and a public key, known to all.
• Principle both keys are needed for certain
  operations (next slides will explain more).
• The key pair is generated using a random number
  algorithm in such a way that the keys match.
• The private key can be protected with a
  passphrase, which you must know to be able to use
  the private key
• To create the real private key from the
  passphrase and the permanently stored private
  key.
• Private key can also be stored in an ID card and
  then secured with a passphrase.

5
Private/Public key pair usage

• Assume A and B both have their (public
  key,private key) pair.
• Both make their public key public (send it to the
  other, etc.)
• A wants to send a secure method for B
• A encrypts the message using Bs public key.
• The resulting message can only be decrypted with
  Bs private key.
• A wants to digitally sign the message
• The signature is generated from the message and
  As private key.
• With As public key it is possible to verify that
  the signature was made with As private key.

6
Practical considerations

• As secret key algorithms are faster, it is
  practical to use the public keys to agree on a
  one-time session secret key.
• For this, both parties can create one-time
  session key pairs (private and public).
• The secret session key is used for communication.
• This is what e.g. SSL does.

7
Using a private/public key pair - Message
integrity/1

• Message integrity the message has not been
  changed or corrupted
• Tentative solution calculate a code from the
  document and send it along. On receipt, a new
  code is being calculated and compared with the
  code that was sent. If they match, the message
  has not changed.
• Examples of check / hash codes
• Last character of a Finnish person identification
  code
• Last digit of a Finnish bank reference number
• The tentative solution works against corruption
  (a checksum).
• However, if someone wants to change the message,
  then she could also change the code (checksum).

8
Using a private/public key pair - Message
integrity/2

• Improved solution compute the code using the
  senders private key and the message. (Encrypt the
  code using the private key.) Create a signature
  or electronically sign the document.
• The recipient can use senders public key to
  decrypt the code. Then it is possible to check
  message integrity.
• Q Whats the difference between this and
  encryption?
• A The information the sender is giving out can
  be public and non-encrypted. It is only if you
  want to verify that the message has not been
  changed that you use the senders public key to
  check this.

9
Authentication/1

• Suppose you receive mail from pythagoras_at_ancientgr
  eekmathematicians.com and you also get
  Pythagoras public key.
• You receive messages which open with the public
  key -gt you conclude that they have been sent
  using a matching private key.
• How can you be sure who the sender is?
• Several possibilities
• It is Pythagoras himself, it is really his e-mail
  address, it is really his public key.
• It is Pythagoras e-mail address, but someone is
  misusing it somehow, and he has generated a
  public/private key pair and sent you the public
  key (public part).
• It is not even Pythagoras e-mail address.

10
Authentication

• The real question is How can you be sure of a
  senders identity in the Internet world?
• Quite often, you are convinced that such a person
  or company exists.
• Then, you need to know if the e-mail and the
  identity match.

11
Certificates and Certificate Authorities

• A certificate is a document where someone states
  that a public key really belongs to the right
  person/company.
• A certificate must be digitally signed by
  someone.
• That someone may be a person, but more generally,
  it is a Certificate Authority (CA).
• A Certificate Authority (CA) is generally-trusted
  generally-known enterprise.
• The CA makes its public key (or a message digest
  of it) publicly available so widely that it is
  not practical for anyone else to claim to be that
  CA.
• The CA (like VeriSign, see www.verisign.com)
  usually charges money for its services.

12
Certification

• The CA digitally signs public keys. (Or gives
  digital identities with private keys and matching
  digitally signed public keys.)
• Anyone can check the certificate against the CAs
  public key, thus making sure that the CA
  certifies the public key.
• There are different levels of certification, on
  the following lines
• Certifying that a public key and an e-mail
  address belong together.
• Certifying that a public key and a persons
  identity belong together (for this you need to
  visit the CA in person).
• Certifying that a companys name and a public key
  belong together
• Read more from VeriSign website.

13
Certification chains and risks

• A certified person or company can give a
  certificate to another.
• For example, if a CA (A) gives a certificate to
  Netscape (B), and Netscape gives a certificate to
  some Java applet programming company (C), then
  you can verify Bs public key using As and Cs
  public key using Bs.
• It all comes back to a CA, either directly or via
  a certificate chain.
• In fact, it all comes back to the CAs private
  key.
• If someone guesses or steals or is able to
  compute (shouldnt be possible) the CAs private
  key, everything collapses.

14
Remote authentication

• Using an authentication server
• Like the PPT (peruspalvelutunnus, basic user
  account)
• A server will authenticate and digitally sign a
  document (certificate) guaranteeing the identity
  of the user.
• The certificate is used as a guarantee of the
  identity.
• The certificate may include information about
  user rights.
• The certificate will usually expire at some point
  ie. can not be used indefinately.
• Example LDAP authentication.
• We wont go to details, at least not yet.

15
.htaccess

• .htaccess files are one of the basic security
  features of web servers
• .htaccess files can be used for several purposes
• They can also be used for user authentication
• They can restrict user access to a directory
  subtree, naturally including all programs
• A possible usage also is to make a group user
  id, like for a course, and the users can access
  the files with the group user id
• Basically uses Linux/Unix style passwords
• A secure method
• This is not really a method for web applications.

16
One-time keys

• Keys, which you only use once
• E.g. from your bank you may get a set of
  key-value pairs.
• The bank gives you a key and you have to provide
  a matching value.
• Each pair is used only once.
• This way, just getting access to your username
  and password is not enough for the financial
  disaster.

17
Methods for our course

• Many of the methods explained this far are
  methods that are being used by modern web
  technology, whether you know it or not.
• It is important to know about them just to know
  roughly in what the security is based on.
• However, we now move on to the technologies that
  we will use in our course with PHP programming.
• We could easily use some other methods as well,
  e.g. the one-time passwords.

18
Username/password in database

• Typically we want to store information about
  users in the database.
• A natural solution is to put information about
  the username and password in the database.
• The password can be stored as cleartext.
• Easier to help the users.
• Less safety for privacy
• It is possible to store a hashcode of the
  password
• A code computed from the password
• Mathematics guarantee that it is practically
  impossible to get the right code from the wrong
  password
• Like in the passwd files

19
Secure communication by your web server

• Web servers typically can use secure
  communications.
• They also have a certificate (maybe self-made ie.
  not certified by a certification authority)
• The normal secure web protocol is called https
  (secure http)
• The web server may be configured to listen to a
  specific port for https connections.
• Typically Apache web server listens to port 443
  for secure connections.
• Normally the browser indicates secure
  connections.
• For https by default the browser connects to
  server port 443.
• If you as a standard user at cluster.cs.uta.fi
  put your html or web applications in
  public_html/ssl, https will be used. Please try.

20
Sending usernames / passwords from the client

• Input typepassword only hides the password in
  the user interface.
• It does not encrypt the password.
• Dont send the password with GET
• In other words, send it with POST.
• Also the application may only accept POSTed
  usernames and passwords (e.g. a PHP program only
  reads _POST)
• Use a secure connection for authentication.
• In fact, if there is private data, use secure
  connection all the time.

21
Once the authentication is done?

• The browser and the server do not maintain a
  connection.
• Technically speaking, the browser always takes a
  new connection.
• How can we maintain the information about the
  authentication? (In order not to re-authenticate
  every time.)
• Since the connection is not maintained, some
  authentication information must be sent.
• It is not so practical to keep on re-sending the
  username and password.
• Re-send an authentication certificate.

22
Cookies

• To re-send something, the browser must store that
  something.
• The browsers have limited rights to store
  anything.
• They may store things in Cookies, if the user
  settings permit that.
• Basics of Cookie processing
• The server, as a part of the html request, sends
  a request to store a cookie (with a value,
  expiration time, etc.)
• The browser stores the cookie.
• The browser sends all valid cookies to the
  server.
• Notice that Cookies are not that secure.
• Https is more secure for sending cookies, too.

23
Sessions

• A method to preserve data over subsequent
  requests.
• The data may be utilized e.g. for aid in user
  navigation, remembering user-related information,
  etc.
• Principle
• The user (in fact, browser) is assigned a session
  id.
• Related to the session, variable values may be
  stored in the server side (without sending them
  across).
• The browser keeps on sending the session id so
  that the server identifies the session.
• Session Id may be sent in a Cookie.
• Session Id may be sent in the URI.

24
Session security

• Session id is used as identification.
• If the ID is in the URI, it maybe be seen by
  other users.
• If the traffic is not secure, anything (including
  the URI) may be stolen.
• If you use Cookies and the browser accesses other
  sites, it may send the cookie.
• In principle, a moderate level of protection is
  gained, if you use Cookies and https.
• See PHP documentation for more details.
• It is also possible to check the IP number of the
  client computer, where the browser is running.
• But may be faked or many computers may use the
  same public IP address.

25
Starting a session

• Call session_start()
• After that, the session is started and you can
  store session-related data to _SESSION array, to
  be accessed on future visits.
• See examples.
• Other ways (just to know)
• PHP may be configured to automatically start
  sessions (lets not rely on this for now).
• If global variables are registered, you may use
  session_register function. Those who are
  interested may self-study.

26
Finishing a session

• unset() the variable that you use to recognize
  the session
• In other words, delete the session data
• The sessions also have a lifetime after which
  they expire.
• The PHP documentation contains user notes about
  this issue.
• If you have access to php.ini, you may set
  session.gc_maxlifetime
• Expiration means that the system will garbage
  collect the variables, which do not exist after
  that.
• Expire the cookie from the browser
• Particularly important, if other users have
  access in the same computer.

27
Sessions and/or cookies

• In principle, cookies could store all the data
  that we store in the sessions.
• In general, this is a bad idea. We do not want to
  send all that data nor do we want to store it in
  the client cache.
• The role of the cookie in sessions is to store
  the session id.
• Outside of sessions, the cookies are used e.g.
  for user preferences when there is no login.
• The session data may be used to store
  session-related information.
• If you want to authorize the user for a longer
  time, then you may store also that in a cookie.
• For long sessions, you may store session data in
  a database.

28
Session stealing

• Sessions can be stolen, if another
  person/computer gets the session ID
• For this it is important to close the sessions
  well.
• The users should also use the logout operation.
• There are also other means, consider the
  scenario
• You contact your bank. However, your contact goes
  to an ill-meaning server that wants to steal the
  session.
• The ill-meaning server sends your authentication
  data forward to the real server.
• When authentication has been made, the server
  informs you that the session was closed because
  of an error and uses the connection for other
  purposes.
• Notice the importance of one-time passwords!