Website login protection with chrome extension

Question

Right so I'm developing very private systems recently, and I'm looking into admin login protection. I'm a PHP dev with essential knowledge of js/jq. While I handled most of the stuff so far, I'm looking to protect the login process itself. Now, from what I understand, only internet explorer is allowed to hook into a device (say a CD or a thumb drive) and check for file, only to allow login afterwards, so I'm looking into something that I can actually use. So my idea was a chrome extension, developed internally and unpublished, that would perform something rather complex and thus protect the login page. So I could have a blank login page, or one filled with spammy adds with no login form anywhere, yet by clicking the extension, I'd be able to login.

Also, I'm looking for ideas, not necessarily code, and while I understand it's a generic question, I haven't been able to gather much data on this as the search for "chrome extension protected login" and similar can be quite misleading.

One other thing I found to be cool, but unsure if it's usable, is an NFC tag. In theory, you'd have the website check NFC receiver connected to the PC, if it finds a specific device on top of it, lets you login, otherwise, it doesn't. Just an idea. Considering the environment from which you login is pretty controlled (it's always a PC, always windows, always Chrome, always same country), feel free to hit me with any ideas how would you solve this. Without investing a whole lot of money if possible.

Answer 1

After read all the comments of this post (so far), there is no much I can contribute, but thank for sharing. Having said that, here are my opinion about some comments written above.

About the bookmark solution, the problem arise when someone has access to sniffers, proxy or http logs, even browser history of the machine.

I like the idea of @samfisher, use a dynamic token (like the "authenticator" of Google). If you want to submit the secret-value in background (more user friendly) you have to keep the extension away from unwanted people, once the extension is install it on a specific browser, the code is avaliable to that person. Just to use as a reference[1]

Restrict by IP address is always a good idea (work mostly in intranet's or using VPN's

The SSL/TLS solution is what I think you need, in a way, it works as a key, by other, it encrypt the channel. Install once, work everytime (till it expires)

In the majority of the cases, the user machine have to be secure.

PS: You can always accept a specific user-agent http header defined by you to allow incoming connections, some mayor companies had done this in the past[2] ;)

[1] http://blog.valverde.me/2014/01/03/reverse-engineering-my-bank's-security-token/#.U5CvIM9dW24

[2] http://tools.cisco.com/security/center/viewAlert.x?alertId=31348

Answer 2

It sounds like you are potentially looking for a physical form of two factor authentication. You may want to look into the YubiKey. It's an easy to add two factor auth to a PHP web app (they even have PHP libraries for you). The keys themselves are very affordable (although I don't know your budget)

If you don't really need a physical device, then definately go with what itscooper suggested. Certificates are totally free, and require pretty much no user interaction (although that can be a downside if the users system isn't secure).

I would have added this as a comment, but I don't have enough 'points'. So silly.

---

Answer 3

As I understand it, an ideal solution would achieve the following:

• Protect your application login process by requiring an additional stage of authentication before granting access to the login page (i.e. reducing the likelihood of a brute-force attempt on the username/password etc).
• Provide an additional factor of authentication (whilst you have not specifically mentioned multifactor, the examples of NFC, USB drives etc pertain to this).

I do not doubt that a well written Chrome extension or similar could potentially achieve this. In order to be an effective form of authentication, it should really be checking for a secret that would only be possessed by a valid admin (I say possessed since we would ideally check for something the user has - we know that the other factor of authentication is a password, something the user knows). There are a number of inherent challenges, including:

• the generation of a secure key (e.g. a certificate) that is difficult to forge.
• key management (how will the secret be stored securely?).
• secure communication with the server (i.e. would it send the whole key or leverage challenge-response? Via what protocol?).
• the server-side endpoint - if HTTP is used for communication with the server, presumably the server would at some point, or multiple points, need to receive values via parameters. The server-side code here would need to be implemented securely just like the login page itself.

In terms of practicality, a Chrome extension could potentially read a file from disk, although the user would need to select it themselves. http://developer.chrome.com/apps/fileSystem.html

Given the difficulties presented above with regards to implementing this kind of system, I would recommend the age-old and reasonably well-established alternative of SSL/TLS Client Certificates. These would provide an additional factor of authentication (the admin must have a valid certificate) and would otherwise prevent access to the login page entirely (or any HTTP communication for that matter). Furthermore, key generation, management, transport etc are all implemented within the SSL/TLS clients/server, and are comparatively trustworthy given heavy scrutiny from the industry.

An example implementation just to give an idea of what's involved: http://krolm.blogspot.co.uk/2012/09/2-factor-authentication-ssl-client.html