This chapter involves a high level overview to round up the complete authentication process.
We have now successfully learned how to secure our users' passwords using hashes; however, we should take a look at the big picture, just in case. The following figure shows what a very basic web application looks like:
Note the https transmission tag: HTTPS is a secure transfer protocol, which allows us to transport information in a secure way. When we transport sensitive data such as passwords in a Web Application, anyone who intercepts the connection can easily get the password in plain text, and our users' data would be compromised. We will cover SSL, HTTPS, and TLS in detail at the end of this chapter.
In order to avoid this, we should always use HTTPS when there's sensitive data involved. HTTPS is fairly easy to setup, you just need to buy an SSL certificate and configure it with your hosting provider. Configuration varies depending on the provider, but usually they provide an easy way to do it.
It is strongly suggested to use HTTPS for authentication, sign up, sign in, and other sensitive data processes. As a general rule, most (if not all) of the data exchange that requires the user to be logged in should be protected. Keep in mind that HTTPS comes at a cost, so try to avoid using HTTPS on static pages that have public information.
Always keep in mind that to protect the password, we need ensure secure transport (with HTTPS) and secure storage (with strong hashes) as well. Both are critical phases and we need to be very careful with them.
Now that our passwords and other sensitive data are being transferred in a secure way, we can get into the application workflow. Consider the following steps for an authentication process:
The application receives an Authentication Request.
The Web Layer takes care of it as it gets the parameters (username and password), and passes them to the Authentication Service.
The Authentication Service calls the Database Access Layer to retrieve the user from the database.
The Database Access Layer queries the database, gets the user, and returns it to the Authentication Service.
The Authentication Service gets the stored hash from the users' data retrieved from the database, extracts the salt and the amount of iterations, and calls the Hashing Utility passing the password from the authentication request, the salt, and the iterations.
The Hashing Utility generates the hash and returns it to the Authentication Service.
The Authentication Service performs a constant-time comparison between the stored hash and the generated hash, and we inform the Web Layer if the user is authenticated or not.
The Web Layer returns the corresponding view to the user depending on whether they are authenticated or not.
The following figure can help us understand how this works, please consider that flows 1, 2, 3, and 4 are bidirectional:
The Authentication Service and the Hashing Utility components are the ones we have been working with so far. We already know how to create hashes, this workflow is an example to understand when we should it.
The HTTPS is a communication protocol that is used for secure communication. Technically, it is the result of layering the HTTP on top of the SSL/TLS protocol. It uses symmetric keys to encrypt the data flow between client and server. The symmetric keys are exchanged using X.509 certificates and hence asymmetric cryptography is used during the initial communication. It requires an SSL certificate, which contains the necessary public key and the identity of the owner. The matching private key is not available publicly. Anyone can generate an SSL certificate; however, with self-generated certificates, the relation between the owner of the certificate and the certificate itself can't be verified. Self-generated certificates are used for development/testing purposes. In order to validate the relation between the owner of the certificate and the certificate, there are certificate authorities who provide reliable digital certificates.
A Certificate Authority (also known as CA) is an entity that provides digital certificates. The CA is trusted by the owner of the certificate and those relying upon the certificate. There are commercial CAs that sell certificates, and some providers issue them for free. Large institutions and government entities may have their own CAs. Getting a certificate involves creating a Certificate Signing Request (CSR) for your server. You need a CA to sign it; the CA will need to validate that you are indeed the owner of the domain. To authenticate the owner of the certificate, most CAs perform a Domain Validation. It involves sending an e-mail to validate the recipient, or logging in with your domain name provider. The process varies according to the CA and the level of security of the certificate. Higher levels of security involve a more extensive validation process.
When the process is finished, the certificate is a digital proof that the web domain is authentic, and that it has been validated by a trusted third party. There are three versions of the SSL protocol. The Version 1.0 was never released to the public; on the other hand, Version 2.0 was released to the public but it had some critical flaws and was replaced by Version 3.0 shortly after.
Transport Layer Security (TLS) had three versions at that time; Version 1.0 is an upgrade to SSL 3.0 and includes TLS/SSL interoperability. This means that a TLS implementation can be downgraded to SSL 3.0 if the browser does not support TLS. TLS 1.1 is an update, which includes, among other minor improvements, a protection against Cipher Block Chaining (CBC) attacks and supports Internet Assigned Numbers Authority (IANA) registration parameters. TLS 1.2 includes some major improvements over the TLS 1.1, including stronger hashes that improve security, enhancements in server-client communication, and better support for different ciphers.
Basically, this is how SSL/TLS works:
A Client sends a "Hello!" message along with the necessary information and data to begin the secure communication.
The Server responds with a "Hello!" message, specifying the chosen protocol, some other necessary information, and the certificate (the last one depends on the cipher suite).
The Client responds with a Key Exchange message. It may contain a master secret key, a public key, or nothing (again, this depends on the cipher suite). If there's no master secret key, then the Client and the Server generate a common secret key.
The Client sends a record to the Server, informing him that everything it sends from now on will be encrypted.
The Server confirms that everything he sends from now on will also be encrypted.
Now the Client and Server can exchange data in a secure way.
The following figure illustrates this interaction:
Thus, we have gone through the process of authentication.