Security and Authentication

We will cover in this document:

Purpose of authentication

For services we need to control:

  • Who can access the system
    • While this can simply be a user id and password, we need to be careful in encrypting the credentials such that a malicious user doesn’t get access to the credentials and hence need to use encryption.
  • What level of permissions does the user have
    • The type of permissions that users have in the system vary. In layman terms, if we have a user who is an administrator and can edit data, while other users can only read the data, we need a way to distinguish administrator and read permissions between users.

Symmetric and Asymmetric Encryption

  • Symmetric Encryption
    • We have a key based on which we encrypt the data. And use the same key to decrypt the data. The common encryption algorithm for symmetric encryption is AES.
    • In network communication, such as a client communicating with a remote service via a browser, the problem with symmetric encryption is that the client can not send the key to the browser in an encrypted form. And hence, we can not use symmetric encryption for network communication.
  • Asymmetric Encryption
    • In asymmetric encryption we use two keys to encrypt and decrypt the data. Commonly used asymmetric encryption algorithm is RSA.
    • Hence services can publish their public keys to clients, and while communicating the client can encrypt the data via using the public key. However, the same encryption key cannot be used to decrypt the data. Hence, an eaves dropper in the middle who accesses the service’s public key can not use the same key to decrypt the data.
    • One problem with asymmetric encryption is that it is computationally quite slow.
    • Another possible problem is that there can be an imposter (man in the middle) acting as the server. We will cover more of this below in the section on Certification Authorities.

Data Integrity and message authentication codes

When transmitting data we need to add a signature in the message to ensure that the message is indeed consistent. The mechanism for adding the signature is:

  • Using the public key we will communicate another signature key to the server.
  • In addition to the message we will send a HMAC (hash based message authentication code) to the server, where the HMAC is generated via :
    • Create two subkeys (K1 & K2) from main key
    • Concatenating K1 with the message and hashing
    • Concatenate result of above with key K2 and hash one more time
    • The end result is the authentication tag
  • After the server decrypts the message, it regenerates the HMAC using the signature key and compares it against the HMAC which was sent as part of the message to ensure that the message data is from the right user.

How Https Encryption work

  • Https uses RSA asymmetric encryption to share the key between the client and server. And thereafter uses symmetric AES encryption combined with HMAC (hash based message authentication code) to ensure data consistency.
  • Https Runs on Port 443.

Man In the Middle And Certification Authority

  • Man in the middle
    • An issue with asymmetric encryption is that an imposter (man in the middle) can sit between the client and server and act to be the server. This imposter can publish its own public key to the client and decrypt the client data using its own private key. Similarly the imposter can communicate with the real server while pretending to be the client.
  • Certification Authorities
    • Certification authorities provide digitally signed certificates
      • Server encrypts the certification authority signature with its private key.
      • Clients decrypts the signature in the certificate via server’s public key which is included in the certificate
      • After decryption client gets certificate authority’s signature on the certificate, which it can compare against the published signature of the certification authority to validate the validity of the certificate.

Session based authentication

  • The idea here is that the client sends an encrypted user name and password to server which the server verifies and uses to generate a session. This session the server stores it in its database as valid with a time to live and returns the generated session id to the client. On following communication the server checks the session which the client sent. against the session id which it had saved in its database to verify that the client is indeed using a valid and active session.
  • Downside with this approach is that the server needs to check the client session against a data store on every request.

Client token based authentication

  • As an alternative to server storing the sessions in a database and validating client messages against the session, the server can generate a session and sending an encrypted token (JSON Web Token) back to the client.
  • The client can then use the same token to communicate with the server. The server will decrypt the token on every request before processing the client request.
  • This design is preferable since it is stateless – server doesn’t need to store the session in a data store.

OAuth based authentication

  • OAuth is a mechanism where we can utilize an OAuth authority such as Google or Facebook to authenticate the user and thereby don’t need to manage authentication for the user in a 3rd party application.
  • We redirect the client to login to the OAuth authority. Upon successful login into the authority, the client is redirected back to URI in our domain. The redirection returns a code which indicates that the client successfully logged in or otherwise.
  • The client can thus use the successful redirect (above) by the authentication service to determine that the client is indeed authenticated or otherwise.
  • If the client needed to obtain a resource which the OAuth authority controls (i.e. list of user’s contacts), the client can post to a URI at the authentication service to obtain an access token.
  • The access token granted by the authentication service will enable the client to communicate with the authentication service without need for reauthentication while the token is valid.

Identity and Access Management (IAM)

  • Once a client logs in to the server, we need to determine the type of access that the client has. This is done in an IAM system, which typically is composed as :
    • User is given one or more roles.
    • Roles are given one or more permissions.
    • Via running a union on the set of roles that the user has, a universe of permissions is constructed that specify a comprehensive set of permissions for the user.
  • IAM is generally managed via a service that has a front end where user roles can be configured.

References

Computer Networking

Has a section on networking security

OAuth2 in Action