|
|
I have been reading up via Wikipedia and HTML books but ended up very confused.
On the face of it what I want to do is simple.
I intend to have a database on a webite such as robertos.me.uk below, (but not that one), with visitors able to register on the site then log in to update the database.
I therefore need to have a secure method of handling the registration and login.
If I merely put the relevant pages in my hosts httpsdocs folder, does that cause the host's system to handle all the TLS encryption stuff, so I can ignore the problem, or does it just signify to the user that encryption is in force and I have to code it all?
|
|
|
|
Why do you want it to run through HTTPS? You would only need that when handling secure information such as transactions or or bank details - unless that is what you want to do...
What you want to do can be done with PHP and sessions...
|
|
|
Do you offer SSL?
You can host files using https - simply place the files in the httpsdocs directory instead of the standard httpdocs. However, because we operate a shared hosting platform, the SSL certificate used will not match your domain name. This means that most browsers will display a trust warning to people visiting your secured site, even though the communication is secured.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
Do you offer SSL?
You can host files using https - simply place the files in the httpsdocs directory instead of the standard httpdocs. However, because we operate a shared hosting platform, the SSL certificate used will not match your domain name. This means that most browsers will display a trust warning to people visiting your secured site, even though the communication is secured.
Yes, I read that a while ago and it just added to my confusion.
I think it says that it is all handled for me, as per my question, but as I don't have my own certificate it would issue the warning - similar to what I get when I go to look at the webstats for robertos.me.uk.
That would be a pain!
|
|
|
Why do you want it to run through HTTPS? Because I haven't a clue about the security measures I need to take. I assumed that was the correct way. You would only need that when handling secure information such as transactions or or bank details - unless that is what you want to do...
What you want to do can be done with PHP and sessions... I am using PHP at an introductory/non-expert level. I shall read up Sessions - thanks for the pointer.
All I'm trying to do is make the username and password non-sniffable. The data itself is not likely to be critical, though it would be highly awkward if someone easily picked up the name and password then logged in and altered the data.
As BatBoy says, Purple Cloud seem to handle it, but not in a satisfactory manner without hassle re certificates.
|
|
|
|
SSL certificates are a rip-off. I used to use self-signed certificates just to make sure data transfer to/from a site was secure and wasn't at all interested in proving the authenticity of the site. Then Microsoft came along with their stupid browser updates and show the site as insecure because the certificate is self signed.
In your situation I'd use the httpsdocs solution and train your users.
|
|
|
|
Yeah, that's how I read it too.
|
|
|
Don't use a self-signed certificate. Use a proper one.
|
|
|
|
If it's non-critical data, you definitely don't need to go down the SSL route.
If you get it right with PHP Sessions, your site will be secure. Passwords can be set using an md5 hash so it's encrypted when put into the database. Are you creating logins for people to actually modify a database, or are you looking at a user logs in and gets a user area?
|
|
|
One database with info from many users. Each will be able to update his own data and no-one else's, but I may want them to be able to allow viewing by others. Possibly also allowing viewers to copy from it into their own as well.
At the moment I envisage one set of files with a user ID on the data rows, but might change my mind to ID-identified clones for performance. I don't think that affects this issue - it will be just a case of how I handle things internally.
Basically I'm OK with programming and databases, but C++/SQLServer on LANs before the days of Intranets, not HTML/PHP/MySQL on websites.
At the moment I can manage an unsecured login and update/display a database. I just want to sort this out before going into the main development rather than bolt it on later. Post-fitting security can be hell.
Thanks to all so far  .
|
|
|
I have done the same myself. As far as username and password are concerned you either use SSL to secure the transport of them to the server or you can send them encrypted by using a little local javascript. Here is a snippet from a form that gets the password and encypts it:
<input name="passinput" type="password" maxlength="20" size="20" tabindex="2"><
<input type="submit" value="Login" onClick="form.pass.value = hex_sha1(form.passinput.value); form.passinput.value='';" />
This way the password is always sent one way encypted (so you store the pasword encrypted as well and compare the 2 encrypted passwords). You could do a similar thing with usernames but store them unencrypted and just compare the encrytped versions.
|
|
|
That looks the sort of thing Ian, thanks.
I had a try sticking the login page into httpsdocs and it doesn't want to play. Error 404 even though the URL that appears is correct. Looking deeper into their help there are all sorts of server-side setup questions, I didn't have time to see if I could access those.
I was going to contact PC support about it today but might not bother, as I'm sure the certificate problem will arise.
|
|
|
|
The certificate problem will definitely arise - I use httpsdocs myself and get the same thing. But if it is only username and password then client side hashing as per my example should be good enough.
Not sure why your httpsdocs is not working though - mine is fine (I assume you are changing the http at the start of the url to https?).
|
|
|
I was using relative addressing in the link, as per the PC help files, as I'm starting from a sub-directory in the httpdocs of an existing domain and targeting the httpsdocs in that domain, not the ultimate domain. I did wonder if that may be the issue, so a good idea to try absolute addressing just for the links each way with that page. (And the registration one).
|
|
|
|
I have never tried doing relative addressing from an http to https page. At least trying an adsolute address would tell you whether the web hosting is working.
|
|
|
|
Just realised you will also need the sha1.js javascript file.
I will PM you with a link to the file on my private web space.
|
|
|
That's great Ian, I have downloaded it thanks.
I thought there had to be something needed but expected to have to hunt it down  .
|
|
|
|
It entirely depends on what data is being stored/transferred, if you are based in the UK even then you really should be encrypting more than just financial info, any personal details, logins and password etc should be too, as with the new large data protection fines coming in if you got hacked you would have to show you made every reasonable precaution to avoid getting fined.
|
|
|
|
No problem. I'd forgotten I'd used it.
|
|
|
Good advice thanks, which I shall bear in mind. However I have no current intention of knowingly storing personal information other than the login username and password.
I used to be registered under the DPA and would re-register if I found it necessary.
|
|
|
|
If your users can store anything they like including personal data whether you intend it or not you will be liable, unless you write it into your contracts appropriately to ensure you are covered in that they are defined as the data controller in data protection terms, and even then you could probably still be considered liable if they saw that you hadn't provided reasonable protections like encryption.
If your system can contain data covered by the DPA you probably will be required to register, I would suggest contacting the ICO who will be able to tell you for sure.
|