Support

As it is implemented, yes, it's not great because the code can be reused, not because it's not locked to an IP list (more on that below). Proper implementation required modifying Joomla!'s user manager. Guess what? I did that, donated that code and Joomla! 3.2 will include it. For more information: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=31704&start=0 and https://groups.google.com/forum/#!topic/joomla-dev-cms/7TqLwlJju4g The concept of the emergency code is implemented in my Joomla! 3.2 patch in the same way as Google applies it.

Do note that locking it against a whitelist of IPs is a MAJOR FAIL OF EPIC PROPORTIONS and implies that the developer who implements it this way doesn't understand what he's doing. The chances are that you'll be needing the emergency code when your IT gear is stolen or when you're hundreds of miles away from your home. But if it's not locked to an IP is it secure?

Well, it's two factor authentication. In order for someone to log in to your site they will need to know a. your username b. your password and c. the security code. The security code is six digit, giving a total of 1,000,000 (10^6) permutations. The emergency code is 16 digits long, giving 10,000,000,000,000,000 (10^16). The emergency code is, therefore, 10^10 (ten BILLION) times LESS LIKELY to be guessed correctly than the security code. Then again the security code changes every 30 seconds, the emergency code is static. This means that even if an adversary is capable of permuting one million numbers in 30 seconds (the security code) they'd still need an average of 30 * 10^10 = 3 * 10^11 (THREE HUNDRED BILLION) seconds to crack the emergency code, or 9512.9 years.

Since the adversary cannot permute one million numbers in 30 seconds (they would be able to beat the two factor authentication in that case) we can safely say that they need an average of more than FIVE MILLENIA to crack the security code. That's the age of the Great Pyramid in Egypt.

More practically, an adversary cannot try more than 10 security codes per second without bringing your server down. This means that on average they would need 5 * 10 ^ 14 seconds to crack the emergency code (15,854,896 years). If you are concerned that your site will be cracked in about sixteen MILLION YEARS then yes, the implementation is a big failure. But I would strongly doubt that anyone would like to spend about 250 times the span of the entire history of civilisation on this planet to crack your site. If someone would be so interested in your site's content –perhaps the friendly neighboorhood spook (hi NSA guys, glad to see you picking up this conversation, I hope you enjoy it)– it'd be much easier to just send a strike team to kick down your door, put a black bag on your head and spirit you away in an... um... "secure facility" where they could "convince" you to "voluntarily disclose" the code to your site. Or, more realistically, just raid the data centre and take the server's hard disk.

As you see it all comes down to cold, hard numbers. Lest a major breakthrough in quantum computing and networking occurs I would insist that the two factor authentication, as it is implemented, is rather secure – especially if you follow our advice and regenerate your emergency code once you use it as, when used, we cannot guarantee that there is no man in the middle attack, keylogger or NSA spook listening in and copying it. Of course, if you were to access your site from a compromised computer, you'd be screwed anyway but that's another story.

I hope you enjoyed reading this post. It is 100% true and accurate – just a little bit humorously rendered, as a defence to the inevitable fatigue of a very long day. Rest assured, I take your security very seriously and do my due diligence (mathematics!) before releasing a new feature ;)

Re #1, FTP security: Use SFTP which is file transfer over SSH. As such you can secure the SSH client by requiring a valid certificate (I'd suggest 4096 bit strength) and disabling interactive login (login with a username/password). Then secure your crypto certificate with a very strong passphrase.

The 10 attempts/second limit I don't really agree on. Unless of course there is a hard limit in the login code. That, btw, would be great without easing a DOS during login.

This comes from experience. A high-end server can't serve more than these many requests per second. Please note that we're talking about requests that cannot be handled by a CDN / reverse proxy / you name it. We're talking about requests that have to go to the web server and be handled by PHP code which is doing a database lookup. This incurs a performance penalty. At a sustained 10 req/sec most shared hosting, VPS and cheap dedicated servers will go belly up in 10 minutes. A very high end, grossly oversized server might be able to handle 50 concurrent requests at its finest day. Even as such, we're still talking about 300,000 years or so. The span of human civilisation is roughly 60,000 years. I think it's safe to say that a machine running at over 100% load will somehow raise a red flag before 300,000 years elapse. Right? ;)

But I would still enjoy to see a config option to disable the secure key (as a FEATURE).

Disabling the emergency code is not an option. You will only need it once in 3 years but when you do you'll come back here and thank me for the provision.