There are many authentication systems around. These authentication systems are dependent on either traditional password based authentication or a third party’s approval ie. OAuth. This article aims to idealize the authentication systems and provide a more secure alternative to the traditional authentication systems.

Present solutions

With several ways of signing in, the obvious question is why do we need another authentication system? To answer this, we need to look at the failures of the present systems at their best case scenario. The cons listed below will exist in all situations for the concerned authentication system as we are only considering the ideal implementation.

1. Basic Authentication

The default HTTP based basic authentication.


  1. Simple and easy to implement.


  1. Least configurable.
  2. No encryption.
  3. Password is required.
  4. Prone to bruteforce.
  5. Username and password is sent in base64 to the server with every request.
  6. Credentials are stored in browser until the browser is closed (session ends).

2. Username/email-password combination

The most common way of signing in is the traditional username/email and password combination.


  1. Most familiar method to users.
  2. Easy to implement.


  1. Prone to phishing and social engineering.
  2. Depends on user’s discretion.
  3. Can be compromised if user’s same credentials used on some other compromised website is leaked.
  4. Can be compromised if somehow password is leaked on user’s behalf.

3. Digest Authentication

Similar to basic authentication, a username and password is sent to the server but after hashing the credentials on the client.


  1. Better than basic authentication.


  1. All the cons of username-password combination.
  2. Client side encryption cannot be trusted.

4. OAuth and OAuth 2

OAuth is another common way of signing in often implemented along with the username/email-password combination. The difference between OAuth and OAuth 2 is nil from a user’s perspective.


  1. Password is not required.
  2. Very familiar to users.
  3. User authenticity is proven.
  4. Quite easy to login.


  1. More of an authorization than authentication.
  2. Depends on third party’s approval.
  3. Promotes data sharing.
  4. Limited by and to third party’s api.
  5. Can be compromised if third party is compromised.
  6. Prone to phishing and social engineering.

5. Single Sign On

Single Sign On is often seen same as OAuth/2, but the concept is a little different. Unlike OAuth/2, SSO is indeed an authentication system.


  1. All the pros of OAuth/2.
  2. Less prone to social engineering and phishing.
  3. Minimum data sharing.
  4. One or two click login.
  5. Easiest for users.


  1. Depends on third party.
  2. Can be compromised if third party is compromised.

6. OTP based authentication

In this system, a uniquely generated passcode is sent to the user via email or sms for the verification of login request. Another variation of this system is to send a one time visitable url to sign in user directly.


  1. All the pros of OAuth/2.
  2. Easier for users.


  1. Depends on the availibility of communication system ie. access to email account or phone number.
  2. Prone to intercepting, phishing and social engineering.

7. Two-factor authentication

In this system, a user needs to authenticate two times. First with some default login system, later with OTP based authentication system. Secure implementation of this system often uses some application installed on user’s trusted device which generates the OTP on the device timely. Since the OTP is not sent by the server, it cannot be intercepted.


  1. All the pros of OTP based authentication.
  2. Safe to intercepting.


  1. Depends on the availability of trusted device.
  2. Prone to phishing and social engineering.

The problem

It is quite clear that SSO and OTP based authentication (and two-factor authentication) are pretty strong and hereby I will refer them as strong systems. One can argue that these systems are foolproof and best for authentication. But I say otherwise.

  1. Strong systems depend on third party or device.
  2. Vast majority of the web does not use these strong systems.
  3. Phishing and social engineering is still possible in these systems.
  4. Sign in process is long.

The solution

I propose a simple and secure browser based solution to the above mentioned problems.

PGP based authentication system.

The authentication can be better understood with the workflow:

  1. Browser allows user to manage PGP keys.
  2. As the user clicks on Sign in, the website asks the permission to access public key from the browser.
  3. As the permission is granted, the website generates a passcode or a unique one time visitable url to login.
  4. The generated passcode/url is encrypted on the server with the public key and sent to the browser.
  5. The passcode/url is decrypted by the browser after the user allows it.
  6. The decrypted passcode/url is then sent to the server to authenticate the user.

This authentication method solves the above mentioned problems and many others as well.

  1. PGP based system is dependent on the browser itself.
  2. As the browsers will start promoting this authentication model, majority of web will start using this system as well.
  3. Since there is no credential, phishing and social engineering attacks will be focused on catching private keys and passwords. Both can be secured by browsers by hiding the private keys.
  4. Since everything is on the browser, the process is short and easy.
  5. Websites won’t need to store sensitive data.


So far, I have only imagined what can be the best possible solution to authentication system. The idea of PGP based authentication system is still under brainstorming phase and I would love to be criticized.