boylesg

If the company got signficantly larger and the database requirements more complex and demdanding then we would have no choice but to pay the extra for https capabilities. At this stage it is a bit of a trial to see if people are willing to use it to enter daily work details and for hand over purposes. And to see if it save us office time over our existing spreadsheet based systems - I am confident it will.

The company involved is very small and is unlikely to be attractive or all that noticeable to hackers. But one can't discount the possibility entirely. The worst of the sensitive data would be bank bsb and account number (if we end up using those fields). They are not all that useful without signatures and pins etc but could conceivably be used for identity theft purposes. But even residential addresses in association with phone numbers and email addresses probably should be encrpyted as a precaution even though they are generally available in phone books and facebook etc. I suppse the risk is similar to the average person who often store such details on their PCs. But if you encrypt thm some how then you make it that much harder for hackers and they will probably choose an easier target where such details are not encrypted.

As an alternative to https for data that would be better to be kept private though not credit card numbers and such like. Don't laugh at me if this is idiotic because I am rather new to web security and just feeling my way. But I would welcome any suggestions. I was thinking along these lines.... The 'submit' button does not have the 'submit' property and instead calls a javascript function on the client. This javascript function opens a file on the client, obtains a key and encrypts all the input fields that contain sensitive data using that key. That file containing the key would be manually installed on the hard disks (client computers) of all folks using the website. Once all the sensitive edit fields are encrypted, the javascript function does a POST on the form. The php code receives the POST data on the webserver and uses the same key value to unencrypt the sensitive data and saves it to the database. The costs of doing https is a little steep for us at this stage. So it is case of finding some middle ground that gives adequate security for low level sensitive data or else just not puting any sensitive data the website database at all.

How practical, or not, would it be to encrypt post data manually. Previously I have removed the 'submit' property for buttons, added an onclick event handler and then posted the form via a javascript function call when that event handler was executed. I could conceivably go through all the form fields, or at least the ones that contain any sensitive data, and encypt them before doing the submit. But perhaps there is a more efficient and/or better way to do so?

I think I can forget the idea of field validation in javascript altogether. It appears to be impossibly cumbersome. I think I will just stick with field validation in php.

<script> function doOnKeyPrerss(Event) { alert(Event.charCode); alert(Event.keyIdentifier); } </script> Neither of these work - I just get 'undefined'. So how do you obtain the key value?

If you use this type for one of the columns in a table, what exactly do you get back for that column when you do a query. Is it a string of the format yyyy/mm/dd....... or does the column data get mapped into some sort of data structure that you then interrogate in php code? Also what sort of collation, if any, should you have afor a date column? ascii_bin?