When the client sends a request to create a new user, our server already requires them to provide an email and password. Therefore, the simplest way for us to implement an authentication layer is to use the users' passwords.

In the most simplistic scheme, the user must send their email and password with every request. Upon receipt of the request, our API server can then compare these credentials with the ones stored in our database; if there's a match, then the user is authenticated, otherwise, they are not.

While the preceding process allows us to authenticate a user, it is not necessarily secure for the following reasons:

• The password is kept in plaintext. According to a report by Ofcom (ofcom.org.uk/about-ofcom/latest/media/media-releases/2013/uk-adults-taking-online-password-security-risks) the communications regulator in the UK, more than half of internet users reuse their passwords across multiple sites. Therefore, whoever has the user's plaintext password for one platform can potentially access the user's account on other platforms, such as social media and banking accounts. Therefore, having the password kept as plaintext means the following:
  • The client must trust our API server not to do anything erroneous with the password
  • If the server and/or database was ever compromised, the hacker would be able to read the plaintext passwords
  • Malicious third parties may eavesdrop on the communication between the client and the server using Man-in-the-Middle (MITM) attacks and be able to extract the user's plaintext password
• Passwords can be brute-forced: a malicious party can try out common passwords or even just attempt every combination of characters until one succeeds.

Therefore, we should enforce strong passwords to prevent brute-force attacks, and also cryptographically hash the password before sending it over the wire.