Security through obscurity - double login protection made easy...

Security through obscurity - double login protection made easy...

Security Published on 3 mins Last updated

Security through obscurity is not a great idea when it is your ONLY protection technique. For example moving your SSH port from 22 -> 23 won't fool any hackers for long! However, I've always liked putting a 'double login' in front of important web sites to frustrate simple automated hacking tools.

We've recently added a simple feature to our WAF where you can add either a static username/password double login OR you can integrate an OpenAuth platform such as Google for the double login.

"However, this may not be the technique you are looking for..."

Have you first thought about a better way to protect the admin section of your web site?

  • Maybe you should consider not putting it on the public internet at all?
  • Perhaps you should only allow access via a VPN?
  • Use an ACL on a load balancer to block ANY request NOT via the VPN?
  • Install two factor authentication?
  • Use client side certificates?

However as we all know, sometimes you are in a hurry, sometimes you just need the existing web site better protected and fast...

So, yes, this is just obfuscation i.e. not really solving the security problem BUT I've always found it incredibly effective at confusing hacker bots!

In order to activate double login protection you will need to add a WAF gateway in front of your cluster. Our WAF options are pretty simple - rule blocking is disabled by default - but the double login feature is always active if enabled.


Simply hit update and you will see that a WAF gateway has been added in front of your cluster in the System Overview:


NB. Usually we recommend that you leave the WAF in logging mode to start with. When you have checked the logs to ensure you are not going to block any legitimate traffic - then you can go ahead and enable tick the box next to 'Rule Engine Traffic Blocking'.

Now, lets see what happens when we open a web browser and try to access the protected folder.


How simple is that?

When you login as loadbalancer/loadbalancer you will then be presented with you normal application login screen (kayako in my case):


So, how do we do the same thing with the Google Authentication API?

Assuming that you allready use Google for your domain authention i.e. for email, then you just need to go into the open auth API console and sut up a new Client ID for Web application (under credentials):


Then go back to edit the WAF on the load balancer and copy these credentials to across as follows:


NB. It is important that the Google API Redirect URI is JUST the domain i.e. Don't put the /redirecturi on the end

Now when you try and access the web site you get your Google domain login:


How do you think we should improve this feature?

At the moment we only support a static user or Google authentication. But please let us know if you find this feature useful, and which authentication mechanisms you would like added to it.

Active Directory & RADIUS are the obvious authentication methods we will add next.

Feel free to leave your comments below - it's quick and easy to do so!