sculptex wrote: ↑Sat May 27, 2017 11:27 pm
There is far worse a developer could do than steal data. Unless you are a developer, you will probably not understand the dangers.
(To add to what Krotek said)
So if a customer clones a site and changes to customer data to avoid them finding it, so what. The developer could write backdoor scripts, whatever. In order for a user to obfuscate everything from the developer, they would need to alter so much, passwords, API keys etc. set it up on a completely different account/domain, setup a specific ftp account for that dev and remove it straight after. They then need to do a file-by-file comparison of all changes proposed by the developer and scrutinize mods etc. for malicious code before putting it onto their live store. If it didn't work on the live store, the developer would be within their rights to say, "well you didn't let me test it on your live store"
Basically all this is beyond the ability of someone typically seeking help! Also trying some of these techniques would give a false sense of security.
And as far as this particular problem is concerned, as it involved an SSL certificate, that would have also required an SSL certificate to be setup on the clone store, as merely putting it in a subfolder of the live store would be an open door for backdoor scripts to access the live store.
This is my plan for now to work LONGTERM with a developer. Security measures will loosen with further projects.
- Clone files to a new subdomain
- Clone database in new container and remove all customerdata
- Change all login information
- Create a new API.
- Setup new dev FTP user with only access rights to subdomain HTML folder
- Deny SSH access
- New SSL certificate for the subdomain but from the same SSL-company
- Screen files with app. for any other codechanges or new files injected into folder. List changes.
- Same for the database.
- Codechanges to be written in a .xt file which later gets reviewed by another developer / security specialist before implementing into the live store by myself.
- Require certain security measures on the developers system
- Consult with specialist to review security
- Sign NDA (for what it's worth) + ID verification.
- Finally hire a developer INHOUSE, fulltime. Next year.
This is pretty bulletproof and any change on the subdomain should also work on the live website. If the developer feels offended by my security measures, well then he can choose not to work for me, but in turn i pay very well and allow the developer to be creative.
