1

When installing software on a remote server: Is it possible to let the admin (i.e. the user that installs the software) define admin username and password via a HTML page, in a secure manner?

Clarification: When one installs e.g. WordPress, parts of the installation scripts accept input via a web page see this example — and notice the password input fields (the image is from this WordPress page).

However, if the installation is done remotely (for example, if you install WordPress on an AWS EC2 virtual host), then I think that by default anyone would be able to access the installation script web page. An evil user could access it before the actual admin, and define username + password and thus hijack the remote server for a short while. (The evil user could be a bot that scans the internet for half-finished WordPress installations.)

Accepting input via a HTML page, when remote-installing software, seems inherently unsafe. But it's fairly user friendly. Is there no way to do it in a secure manner?

Some unconclusive thoughts on the question:

One workaround would be to block the HTTP(S) port in the firewall (on the remote server), and access the installation web page via a SSH tunnel. However this seems like an almost user-hostile installation requirement.

Another workaround would be to have any shell script parts of the installation script print a randomly generated password that the person that accesses the installation web page would have to specify. This seems somewhat more user friendly.

Perhaps the best solution is to have the admin define his/her username and password via the Bash shell? (I.e. over SSH, not via a web page). However then what if the admin wants to login as admin via OpenID, e.g. Gmail? (Gmail is very secure if you enable 2-step verification.) That cannot easily be handled via a Bash script...

Perhaps the best method would be to let any shell script part of the installation print a URL that includes the server address, plus a magic one-time password — then the-person-that-does-the-installation would only need to copy the URL and paste it into a browser. And then the installation could proceed from within the browser.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
KajMagnus
  • 687
  • 1
  • 5
  • 10
  • And your question is? – Adi May 07 '13 at 05:53
  • @Adnan "Is it possible to let the admin (i.e. the user that installs the software) define admin username and password via a HTML page, in a secure manner?", + how – KajMagnus May 07 '13 at 05:57
  • Yes it's possible. As for how, that's outside the scope of this site. Besides, you've already written many solutions. – Adi May 07 '13 at 06:02
  • @Adnan You think it rather belongs to StackOverflow or some other site? – KajMagnus May 07 '13 at 06:03
  • @Adnan I've suggested some solutions, and actually I was wondering if I had suggested all "good" solutions and if this question was unnecessary. Still Iseri posted a different solution (below) that I had not thought about. – KajMagnus May 07 '13 at 06:14
  • 1
    I think that the "goodness" of a solution would depend on the deployment scenario. In most cases your bash solution would be enough and the SSH one even better. If one purchased a CMS, then it could even be preinstalled (or partly so), and the initial password generated at random and sent through email upon purchase. What with different CMSs and deploy scenarios, I don't think there can even *be* a good one-size-fits-all solution. Your OpenID idea intrigues me no end, though. It seems feasible (together with an email validation via shell, FTP or upon purchase), and is *very* elegant. – LSerni May 07 '13 at 06:55

1 Answers1

2

Many such apps do not have a shell script part, and do everything through a PHP/Perl script instead.

I think we must consider what information does the installation have about who its master is. Certainly not "anyone who can connect through HTTP", since as you say, a bot might just scan for half-baked installation.

The simplest thing would be to require the same password used for FTP in order to proceed with the installation. This could be done by generating a random name such as .htABCDEFGH.txt and reading a cleartext password from it. In most installations the creation of such a file is only allowed for the FTP user, and the file itself cannot be read except through FTP.

A variation could be to let the installer choose a password, display its MD5 salted hash on screen, and require the hash itself to be saved server side, e.g.

To begin installation, you need to save the password you've
just chosen in a text file called password.php containing the
following lines:

<?php
    $INSTALLPWD='65cb963e760378ab0ee97e50ca70084f9555adb9';
?>

You need to do this via FTP, to prove you own the FTP account
used to deploy this installation.

Here again, unless one had the FTP password, one could neither write nor read the hash (even if the hash could be read, it could not be inverted).

For those installations that come pre-packaged with no FTP account (a popular choice in CMS web space providers), the password.php also could easily be generated by the CMS allocation script. After purchasing the CMS installation, you would be supplied not only with the link to the install and admin panel but also with the installation password matching the newly created password.php file.

Installation username would be possible in the same way, but it seems overkill. The installation password would only need to be used once, and briefly at that, to establish a chain of trust and let installation proceed. Once that's secured, you could define any user and password you wished (and delete the password.php and any setup directory/script, too).

For added security, the password.php script should not be used unless the installation is yet to begin. A fully installed system ought to ignore that file, to avoid anyone with a small exploit capable of creating one short arbitrary file to leverage this into the capability of restarting the whole installation.

LSerni
  • 22,521
  • 4
  • 51
  • 60
  • Thanks! I'll probably take the automatically generated `password.php` approach, i.e. generated via the allocation/installation script. (Although it's Scala not PHP in my case). And then have the user include the password via a magic URL (which would be valid only before the installation). – KajMagnus May 07 '13 at 07:27