Website Access Control and Security
Website security has become a hot bed over the past few years. More and more companies are joining the game in hopes of capitalizing on what they perceive to be huge opportunities. The one vector that seems to be all the rave is Access Control.
When I talk to access control, I specifically talk to mechanisms in place to restrict access to a resource. Think how you connect to your website. Are you using WordPress, Joomla, Magento or some vBulletin? Maybe it’s a custom PHP, HTML, ASP website?
Regardless of the platform, you have some form of access vector you employ daily.
If you’re a WordPress user, you’re likely leveraging /wp-admin. If you’re on Joomla, you’re using /administrator, and so on and so on — each platform providing its own means for connection. Access vectors don’t stop there. They extend well beyond the application itself. Think about things like File Transfer Protocol (FTP), Secure File Transfer Protocol (SFTP) and Secure Shell (SSH). These are transfer protocols that are still part of your website access vectors.
This can be extended further when you think about things like your hosting panels and database log in panels, additional forms of access vectors. But now we start diving into a very deep rabbit hole.
Today’s Access Control Solutions
2012 was perhaps the worst year for Access Control than any other year in the past. It saw some of the biggest password data breaches with companies like Yahoo and LinkedIn.
The Web needs a new password — as in an entirely new system for securing information.
Fast forward into 2013 and 2014 and we start seeing a lot of discussion and publicity around something called Brute Force attacks.
A brute force attack can manifest itself in many different ways, but primarily consists in an attacker configuring predetermined values, making requests to a server using those values, and then analyzing the response.
You’ve also likely heard the term used interchangeably with Denial of Service attacks, and while there are some similarities, there are differences.
These Brute Force attacks were easy to deploy against websites. They focused predominantly on penetrating and abusing access controls, specifically their URL based access vectors (e.g., /wp-admin, /administrator, /ghost/signin). The tools online were easy to find and configure. Never before had the user and password lists been so rich with new data sources.
To address this problem you’ve seen more innovation in the space than in many others, thankfully. You’ve seen the creation of solutions like Launchkey, GetClef, Rublon, Duo Security and many more.
You’ve also seen the introduction of a lot of solutions focused strictly on protecting websites against these Brute Force attacks — solutions like BruteProtect which was acquired by Automattic in August of 2014. Almost every other security extension and plugin has some form of Brute Force protection embedded within its architecture.
The problem with Access Controls however, always comes down to one undeniable fact — you can’t trust that the user is who they say they are. Is it the legitimate user, or someone acting like the user? Yet, they are a requirement for every website.
Passwords have been in place as a way to get around this. They put emphasis on who the user really is. Does the user know the password? Granted, we can go into a rabbit whole with this, which is the dilemma we are in today.
The first two solutions: Launchkey and GetClef try to use technical innovation to address the problem, while the last one looks to make better the existing workflow. The first two solutions however take the emphasis off the user, and place it instead on the mobile device. Launchkey does try to broach this challenge with their little lock bad device that you have to manipulate in some sequence. With GetClef however, own the phone, own the website — granted there is a little 4 pin pass to access the app.
Which one is right? It’s honestly hard to say. They all still have the same issue, the end-users. But specifically their adoption of the solution.
The problem I believe the first two are having is that end-users are stubborn than. As technical people, we like to think that things are perhaps easier than they probably are, but when it comes to security there is a very steep hill to climb to get over the hump with users — the point where they actually employ the solutions you put in place. Many however, will never see the value in doing something they can’t truly appreciate.
I’ve played with both products, and while I appreciate the innovativeness of LaunchKey and GetClef, I fear it’s biggest challenge will be adoption beyond the Oh, this is cool phase. I can appreciate functional ease of leveraging your mobile device to gain access. I’d say it definitely helps add an additional layer to your overall security posture, but it’s the implementation that worries me.
For instance, with GetClef, the premise of the device is no passwords at all. You simply sync the wave lengths, it does it’s magic and you’re in. That’s cool, but there is something about being in a coffee shop and having to hold my phone up to the screen for it to sync. That’s just odd. I think a lot of users will agree as well. It’s fun at first, but then gets very cumbersome. The same applies with Launchkey. Unlike GetClef, it’s not about syncing wave lengths, but leveraging this app that allows you create a code sequence with a cool little knob. It’s fun at first, but becomes annoying time and time again.
This might all be preference, but if I’m technical, mindful of security and still get annoyed, what does that say for wider adoption? Maybe it’s a matter of making it part of a routine, and I haven’t cross that bridge yet.
The two devices that I still enjoy however, and find highly effective are DuoSecurity and Rublon.
I think we often try to overcomplicate things with technology, fix it because we can, not because it needs to be. This is the issue I see with the previously mentioned solutions. You look at solutions like DuoSecurity and Rublon and they on the other hand, extend and improve what people are already using. More importantly, they are platform agnostic — something I really like.
It’s rare today to find any website owner/entity leveraging only one platform. If you really want to address the access control issue you need adoption, and you achieve that adoption by supporting as many platforms as possible. Then give it away for free, which many are already doing.
Access Control and Security
Access Control is but one aspect of security, one of many. There is nothing that annoys me more than overemphasis put on any one. In fact, Access Control is all the rave because of Brute Force attacks and their sexiness in terms of awe, but they’ve been going on for a long time now.
There are three things I always address when I give website security talks about issues that website owners are faced with:
- Access Control
- Software Vulnerabilities
- End-users
In my mind, those are the three critical elements that contributed to the various mass compromises we saw in 2014 and will see in 2015.
Because you implement an access control solution you should not be fooled into thinking you are more or less secure. Does it improve and reduce your overall risk, specific to the access control attack vector? Absolutely!!! That should not however be confused with, I’m now secure!!!
I was asked what my preference is when it comes to Access Control. It’s not any of these, I think some are more practical in terms of adoption like Rublon and DuoSecurity — but some of that might be personal preference.
When it comes to preference, I share the same belief as my business partner, Daniel Cid. We can get closest to the issue of authentication through the employment of a whitelist strategy, where you block everyone by default and allow only known goods. This is very applicable to website security access controls.
Case in point, try going to http://tonyonjiujitsu.com/wp-admin. You’ll immediately be blocked (I hope) at the edge from ever accessing the page.
This strategy suffers the same issue as some of the solutions proposed above, adoption. Yet, most don’t realize it’s actually easier. For instance, configuring one known access point that you can always use to access your access vectors is very easy to configure, and more secure than almost all the solutions combined.