2

I've been building a website from scratch, and while I have some background in coding (particularly Python and various flavors of C) I am teaching myself html, php, sql and so on as I go.

I would very much like to be able to add an 'admin view' to my website, so that I can add and modify content more easily. I've spent a good amount of time searching for a way to do this securely, hidden behind a password, but it seems as though this is extremely difficult, or even impossible, to do.

With my incomplete understanding of how internet security works, the only way to do this is to have the login php file include a php file from outside the public_html folder which contains the actual password entry, which itself must contain a randomly generated way to modify the password-entering instructions to prevent anyone who intercepts the password I enter from being able to use it later, and which then decrypts the entered password and sends it to other php files outside the public_html folder that contain the infrastructure for the admin view.

Given that I've used several websites that require entering a username/password that use a much less convoluted scheme for securing them, I'm assuming a better system exists. But the main problem of all information from the client being visible to any sufficiently determined attacker seems to render this impossible. What am I missing?

P...
  • 655
  • 2
  • 6
  • 14
  • 1
    use `password_hash` to create a hash of your password, then store it somewhere. On login compare the submitted password string with the stored hash using `password_verify`. That way you don't store any passwords and you should be "safe". You should never store passwords in plain text anywhere, what if someone gains access to your database, or can read the password file because of some misconfiguration/exploit? – JimL Jan 03 '16 at 20:00
  • 1
    Make sure that your password form is submitted over https – Mark Baker Jan 03 '16 at 20:00
  • Storing isn't the issue, transmission is. I'm under the impression that anyone monitoring the website could just steal the hash value, spoof the login page and gain access that way if that was all I did. – P... Jan 03 '16 at 20:01
  • 1
    There is where/when the SSL comes into play. – frz3993 Jan 03 '16 at 20:02
  • @P... if you're worried about the transport then HTTPS/TLS takes care of that. If you're worried about the web host/web server then you're nearing a point where you have to trust something. – JimL Jan 03 '16 at 20:04
  • People are mentioning HTTPS/TLS/SSL, and while I see these referenced, I am completely unable to find information on how to use them. Are they at the level of the web page? .htaccess? server configuration? – P... Jan 03 '16 at 20:06
  • Take a look at, http://security.stackexchange.com/questions/20803/how-does-ssl-tls-work – chris85 Jan 03 '16 at 20:07
  • 1
    @P...: The "secure" process you're describing doesn't really make any sense, and doesn't do anything to secure the website. All you really need to do is use an encrypted channel (SSL) and never store reversible passwords. – David Jan 03 '16 at 20:07
  • You can get a certificate here for free: https://letsencrypt.org/ - it really is the way to go for sending sencitive data over the net. You can read a nice comment here about client side encryption: http://stackoverflow.com/questions/4121629/password-encryption-at-client-side - so before you send anything you encrypt it. So not only will the connection be encrypted but also the data. – stubben Jan 03 '16 at 20:11
  • People seem to be assuming a level of understanding that I do not have. I'm easily finding a lot of information about how these various things work, but not any about how to actually use them, which is what I actually need. – P... Jan 03 '16 at 20:13
  • @P... just follow the instructions for letsencrypt on your server. it will prompt you some questions, but figures out the most on its own. It will set up certificates for your website so it uses https, when users visit a site through https the connection is encrypted so people can't "monitor" it :) – JimL Jan 03 '16 at 20:21
  • I should probably mention that I am not hosting the site myself, I am using a hosting service (EHost, if it matters). letsencrypt does not seem to have instructions on how to actually use it, just on how to run it once it is already installed, which only helps if I have control of the server in question, which I do not. – P... Jan 03 '16 at 20:29
  • @P... yeah they assume you have shell access. If not then you probably have a web ui control panel from your web host where you can activate HTTPS. Please contact them for help to set this up. If they don't offer it I'd consider changing host. – JimL Jan 03 '16 at 20:32
  • @JimL Thank you, so this is something I have to ask them directly. They've been pretty good about support in the past, so hopefully I can clear this up quickly. – P... Jan 03 '16 at 20:34

2 Answers2

2

  1. This is the most important bit: Use HTTPS.

  2. You should use a hash on the password in javascript, before it is send to the server, and only use the hashed value. That way the actual password is not easy to get at. Remember to salt the hash. The point of hashing on the client side is that that it obscures the original password. (Many users use the same password on multiple sites. this way the original password is very hard to get at)

Here is a good implementation of SHA-256: http://www.movable-type.co.uk/scripts/sha256.html

  1. Hash it again at the server side, before you store it, in case someone gain access to your data. Don't forget the salt.

  2. Remember that security is only a matter of degrees :c)

Where you store the hash is less important. Just make sure it's unavailable to the outside. Use .httpaccess files to restrict access. here are some examples: http://blog.dreamhosters.com/kbase/index.cgi?area=3083

Simon Rigét
  • 2,757
  • 5
  • 30
  • 33
  • How do I use HTTPS? I've been searching the internet for days now and have found no useful answers. I am not hosting on my own server, but using a web hosting service (eHost, if it matters) and do not have direct access to the server. – P... Jan 03 '16 at 20:31
  • 1
    I've noticed hashing/encryption in javascript is a topic that has been discussed a bit lately. I'm not sure it really brings much to the table. If you're trying to mitigate someone owning the web server to get the plain text - they can just swap out the javascript. Also hashing server side definitely should use `password_hash`, it seems like it's going to be a safe bet as they intend to update it as technology changes/improves. – JimL Jan 03 '16 at 20:31
  • 1
    `"You should use a hash on the password in javascript, before it is send to the server"` - So everybody has access to the salt? Doesn't client-side hashing just turn the hash *into* its own plain-text password? – David Jan 03 '16 at 20:34
  • 1
    Surely if you only hash client side then the hash is as valuable as the password on your website - if an attacker gets your password hash they can directly login as you with it? Though I'm of the understanding that hashing a hash reduces the total number of possible outputs and increases risk of hash collision. Not such an issue I suppose with the larger bit-depths. Truthfully I've always seen securing it at the server end more important. – Brizee Jan 03 '16 at 20:34
  • Using HTTPS is a server setup issue. – Simon Rigét Jan 03 '16 at 20:38
  • The point of hashing on the client side is that its too much bother to regain the original password, when you can use the hash alone. (Many users use the same password on multiple sites. So if you get at it, you get them all) If you gain access to the server side data, you probably also gain access to the code. – Simon Rigét Jan 03 '16 at 20:42
  • There is surely a comprehensive post on this alread? Truthfully clientside hashing, serverside hashing and SSL are all doing very different things it doesn't seem worth comparing them when all should be covered. Without a clientside hash a MITM will compromise one password for multiple sites, without a serverside hash a compromised server will compromise all accounts on one site. Without either you compromise all accounts on all sites. Before you even get on to the benefits of salting, random salts etc.. – Brizee Jan 03 '16 at 20:51
2

You are right so far, that it is impossible to protect the transportation of the password between client and server, by your own application. If an attacker can do a ManInTheMiddle attack, (s)he could do exactly the same as your client does, or could just strip away a JavaScript which tries to encrypt or hash the user password before sending it.

So the only thing you can do is using an encrypted SSL/HTTPS connection. Most providers offer to install a SSL certificate, but often this is a bit expensive, and sometimes only available in the professional bundle. There are also hosters which offer it for free though.

The encryption of an SSL connection works, because there is already a shared secret. Browsers will install a list of root certificates, and those certificates can be used to set up an encrypted connection.

martinstoeckli
  • 23,430
  • 6
  • 56
  • 87