Ghost: If possible : the admin path to be configurable through config

[bearnik]

If possible admin path ../ghost/ to be configurable through config.js, and if not set to be left as default /ghost

[manzoid]

Why?

[shoostar]

@manzoid Why not? It's never a bad idea to be able to change the URL of your website's admin area. This would help to obscure it from potential attackers that are simply trying to type in something like www.yoursite.com/wp-admin, which in turn can also help initially mask what software you're using to power your site. For people who have knowledge of how to hack into a specific CMS' admin area, this feature can also act as a deterrent. Obviously, it's not a fail-safe by any means whatsoever, but again - it's never a bad idea. I myself was actually just looking into this for Ghost yesterday evening.

[jgable]

Security by obscurity is not really a strong premise. And a vanity configuration of that particular level seems excessive.

I like to be in the mindset that any feature we add will have to maintained, and tested, and accounted for in other features, for ever and ever and ever. And ever.

Is it really really really worth it?

[manzoid]

@shoostar Because that's just "security through obscurity", which is known to be basically useless. Parameterizing this costs developer effort, and the cost/benefit isn't really there.

http://codex.wordpress.org/Hardening_WordPress#Security_through_obscurity

[jgable]

@manzoid jinx.

[manzoid]

hah. i owe you a soda.

[vbtechsupport]

why not incorporate something similar to wp limit login attempts plugin http://wordpress.org/plugins/limit-login-attempts/ against the admin login page ?

[gotdibbs]

@vbtechsupport We already throttle login requests :)

[vbtechsupport]

@gotdibbs awesome didn't know that !

[bearnik]

Think this is reasonable request because of two things :

• "security through obscurity" - which think is important
• second reason is - if you have configurable admin area, you can adjust it the way you needed. Maybe you will have multiuser blogging system and link to administration for your users will be blogsystem.org/some_user/login or something like that, or you are migrating your your users to ghost and they don't like the new ghost address because they bookmarked already http://some-site.com/blog/some-admin-area-page

Yes, this will be definitely extra work for the devs, but think this feature will be cool to have, and for now it is not the top priority :)

[BiosElement]

@bearnik Security through obscurity is not actually security and is thus, not important.

The only use-case there that hasn't already been debunked is the existing bookmark for admin pages.

Pre-existing would probably be wrong anyway since remapping the entire admin UI to a custom system isn't reasonable. What 'is' reasonable just making a nginx redirect to send folks to the new page or, better yet, having your writers update the link.

[bearnik]

@BiosElement you have a point for security through obscurity in a way (yes, it is not security issue ), but I won't argue about the pros and cons of one not knowing your actual administrative url.

Nevertheless, is it more reasonable as it is now - simple redirecting for some of the most common pages as admin, wp-admin (why wp admin ?), ghost-admin etc... or is it more reasonable to be in config, database and use some kind of routing system.

Indeed nginx configuration could do the trick, but must play a bit with it.
Cheerz

[ErisDS]

Nevertheless, is it more reasonable as it is now - simple redirecting for some of the most common pages as admin, wp-admin (why wp admin ?), ghost-admin etc... or is it more reasonable to be in config, database and use some kind of routing system.

We have these redirects to make it easy for people who might be used to something else like 'wp-admin', which I believe is your second point?

If you read our planned features listing, you'll note at the top the way to determine whether a feature should be in Ghost core or not. This is not something which will be required by the majority of our users the majority of the time, and as it doesn't add any benefit in terms of security, it is definitely plugin territory.

[baus]

I spent quite a bit of time looking into this yesterday, as a way to get more familiar with the codebase. This is not simple change because /ghost is hardcoded in quite a few places in the code on both the client and server side.

Changing the server side code is pretty straight forward, but the path also needs to be passed to the Handlebars templates when they are compiled and to the client side JS views. Passing to the client side JS is actually the most painful as it either requires generated JS on the server or somehow parsing the path on the client to figure out where the app is rooted. I'm leaning toward parsing the path.

If others are interested, I would still consider creating a patch that implements this, but I would appreciate some help reviewing the change before the pull request is submitted.

[ErisDS]

@baus as per the discussion above, I'm not aware of any good reason why this feature needs to exist? This issue is closed as it's certainly not something we want to support in core.

[baus]

You'd have to support it in core as far as I can tell, because it would be a pretty big change. I don't think it could be done as a plugin or with a reverse proxy because the path is hard coded in the client. The client would still be looking for /ghost even if it was proxied to something else.

I can see this being interesting for those who want to "white label" a ghost install. The security argument is mediocre, but there have been quite a few discussions on HN recently of "security by obscurity" as being one layer in a security strategy. You shouldn't depend on it, but it adds one layer to slow down attackers.

[baus]

@ErisDS Should I assume if I did put the patch together that it would be rejected? I don't want to finish the work if it won't make into the application.

[JohnONolan]

This is not something we're looking to implement for the reasons outlined above, as well as the biggest one that wasn't mentioned: consistency.

A user should have the same experience across multiple installs of Ghost.

[baus]

For anyone interested in this feature, I've implemented it in this fork: https://github.com/baus/WhiteboxGhost

[baus]

I've updated my fork which implements this feature to track some of the recent changes to routing on master.

You should be able to merge this branch fairly easily if you are interested in this feature:

https://github.com/baus/WhiteboxGhost/tree/adminroot

I'd welcome feedback on this patch, specifically on setting the path on the client.

[jtzero]

For what its worth, I see a reason for this feature. The same reason one doesn't leave ssh on port 22, bots. Yeah a human attacker can find it, any server log will get a ton of attempts on /wp-login.php, or /blog/wp-login.php, w/e (the ssh analogy only goes so far here, because of port scans). Having the login url customizable makes it infinitely more difficult for the bot to automate the riping open a login from the login page. It's less security through obscurity, and more seperating the low hanging fruit from the more serious threats. (If I'm off base here, I'm sure someone will enlighten me, I'd rather be wrong and learn, than "right" and ignorant)
useful info

[jaswilli]

one doesn't leave ssh open on port 22

Moving services off their well-known ports is pretty much wasted effort if your goal is increased security.

Having the login url customizable makes it infinitely more difficult for the bot to automate

No, it makes it about 10 more minutes worth of work to make the bot handle it.

[themestechnology]

PCI / DSS compliance for one

[brian-avery]

A bit late to the game, but I, for one am in support of this feature. I used to run a web server, and looking through the access logs, you could always see at least a few entries each day for people trying to brute force their way into your systems by going to a default admin page. All software has flaws and it would be nice to be able to make them just a little bit harder to find. Yes, security by obscurity alone is not a good security system, but when combined with other security measures it's a good start. Thanks for the fork @baus

[az3]

Hello,

I am also new to Ghost and I was looking into this case; and I totally agree with @baus and @brian-avery.

I tried rewriting the sh*t out of nginx but finally gave up. It is not possible without an intelligent proxy that rewrites every javascript word coming out of the node backend server. If it was only css or js requested, that would be possible (a few regex would do the trick) but hardcoded redirections makes it impossible.

This change of /ghost endpoint is not REQUIRED[1] but it MAY[1] help.

Although you say "Security Through Obscurity" is bad, I don't agree with that opinion. Obscurity is a "nice to have" on top of real protective measures [2]. You can change SSH Server's listening ports [3] for example, and it may help for 0day exploits. So, if a 0day exploit is discovered on OpenSSH Server (or on SSL library or glibc or any other sub component I don't know) I will have more time to fix this issue than anyone else. Because probably automated bots will search through all IP v4 ip addresses and they will probably check for 22 only. I know, I am not perfectly safe by changing port; because if someone really wants me down, he/she can search all the ports on my server and will surely find ssh port in seconds. But, in a mass targeted assault, my server (non default port) is probably not in the "first to look for" list.

So, why not add this "admin panel endpoint configuration" to Ghost?

[1] Words are capitalized to be RFC2119 compliant.
[2] http://rainbow.chard.org/2011/09/14/security-through-obscurity-is-a-good-thing/
[3] https://danielmiessler.com/study/security-by-obscurity/

Thank you Ghost team for this lovely product and also big thanks to @baus for hard work.

[cookiejest]

It would be good if this was configurable when using ghost as an NPM module.

[1600]

@az3 exactly, security by obscurity is bad when it is the only mechanism designed to prevent exploitation. besides, a well thought custom admin URL is at least as effective as a password of same length to attacker who do not have network sniffing capability.

[kevinansfield]

besides, a well thought custom admin URL is at least as effective as a password of same length to attacker who do not have network sniffing capability.

For that to be true the admin redirects would also need to be removed otherwise any would-be attacker would visit https://yoursite.com/{slug}/edit and will be redirected to https://yoursite.com/{"strong"-admin-url}/edit/{slug}, you also wouldn't be able to enable the public API as that would also immediately expose the admin/api paths. Security through obfuscation doesn't really buy you anything except the illusion of security. If you really don't trust Ghost's admin interface and API to be secure then you can put another gateway in front such as only allowing access when a certain SSL certificate has been installed, or limiting access by IP address both of which are achievable now and don't require any special configuration to be built into Ghost itself.

[chrisdlangton]

This is NOT security through obscurity at all. It is in fact “Hardening”, period.

Hardening, defendably the most important Defense technique, is where you reduce the vulnerability surface so attackers have fewer ways to exploit. By removing software defaults you take away tools from attackers that perform scans that uncover defaults in software as potential targets.

The most common examples is changing default ports like has been mentioned already, and another that relates to this issue more directly is hiding WIFI SSID from being broadcasted. There’s no need for a business to broadcast the SSID when the only people who need it know it’s there already!
If you’re not already being targeted you’ve made your wifI safer from attackers who are scanning for potential targets and now they’ll not find you and focus on someone else they do find.

So this change request covers 2 of the core security practices;
1) Hardening
2) Remove software defaults

It is far from the blanket response Security through obscurity

[JohnONolan]

We've rethought this subject and it's probably something we're going to add support for in the near future - but not for security reasons and not in this dormant old issue. Keep an eye out for a new issue soon.