Even using GRANT to set up a userid with limited privileges, you are still vunerable to people setting values manually rather than those your script derives.

I was going to suggest having a server application running on your Debian box that receives the values from the script on the client and have it make the updates to the database, but the unscrupulous people you fear could still send bad data.

The only reasonably secure way I can think of is to have the client script only send the inputs gathered at the client and the have the server do whatever process your client script currently does to derive the values for update and then make them.

This way, all the important information, userid/password, database, tables, and field names are all kept private in a script that the user should never be able to see.

Personally, rather than writing a full client-server, two-way traffic application which can be hard--especially the culling of CLOSE-WAIT bound child processes at the server end--I'd have two userids.

One with read-only privileges would be used by your client application--with userid/password embedded as now--to request data as needed and let the DBM take care of the multi-user aspects of things.

The second would have the write privileges and be used by a server app, that listens on a single port and only allows a single connection at a time. It would sit blocking until it received a packet of input, do what ever manipulation and validation that part of your current client uses and then perform the update, and go back to waiting.

Where your existing client code currently connects to MySQl, it would connect to the server port, fire the data in a UDP packet and close the port. If it couldn't connect because the server was busy, just sleep rand*5; and try again.

You should still do the validation of the data at the client end so that it doesn't need to get confirmation from the server, but you should send the raw input to the server and have it revalidate to make it harder for people to send spurious values into the DBM.

It's not a bulletproof solution, but I think will prevent anything other than the most determined attempts to supply fraudulent data and it should be relatively simple to implement as it would just reuse most of the code you already have.

Sending a UDP packet with LWP is very easy, and writing a wait-read-validate-update-loop server it not much harder.

Thanks for the reply. I may investigate this in the future. Right now I'm going to check out the Filter modules as suggested below...

scratch

You can do some simple username and password obscuring, but anyone who reverse engineers the script will get the username and password.

Consider a different approach. Use MySQL's GRANT to give that username INSERT and UPDATE privs on one table, and no privs to anything else (see GRANT and RESTRICT in the MySQL docs). That way, a malicious user can do nothing beyond making spurious updates to that one table. They won't have visibility to do other tinkering.

Well... there isn't any secure way to keep your secrets private. You should also be aware that even if you somehow keep your secret away from your possibly-tinkering co-workers that the rest of the script is still open to modifications. In fact, while you could do all sorts of crazy things to obfuscate your secret (since it's impossible to hide) your tinkerer's could just modify the script to print the decoded secret just before it goes into DBI.

I think you have two problems - keeping your login secrets and keeping your code from being altered. You've only brought up the one so try to spend some time thinking on the second as well. I don't know what options you have in DOS for this but if you were on a Win32 I'd suggest you check out ActiveState's compiler and use a plain executable.

All I can think of is that you can use a source filter to encrypt or obfuscate your perl script and keep it from prying eyes. It's not perfect but it's about the only thing you can do. I suggest you read the perlfilter man page and then consider using something decent from CPAN like one of the Filter modules. The unfortunate part here is that now you've only abstracted your problem away one level. Instead of having readable source code including a secret you have encrypted source code and a very visible secret. The difference is that it's going to more difficult for someone who isn't already a perl hacker to do something useful with that.

It all comes down to how much effort you want to put into the problem and how much skill and effort your tinkerer's will be able to use.

No code example? Right. This is non-trivial and you'll have to find your own balancing point. If you just need something really trivial then why not just hex (ex: "password" eq "\160\141\163\163\167\157\162\162")encode the password or something. It's entirely obvious to any competent programmer what's going on but might appear magical to someone who isn't.

Thanks. This is very helpful. Thinking about the code and not just the username & password is definitely worth doing.

I am running this under DOS on Win98, so I'll take a look at the ActiveState compiler. The executable idea would probably work. I'll also take a look at the Filter modules. Hey, I could even bleach the source!

Think of what you would to secure a web based application. .oO(Store the information server side)

Why do you store information server side for CGI apps? because you cant trust your users to enter the correct information. A web app is client server right? Is there anything majorly different between this what you're proposing?

IMHO, stick a server client side to interact with your database. Use -T, check your input, and wuh-lah, there you have it, an inherrently more secure application. If you use CGI as your gateway, then you have a more extensible interface into your database, as well as have all the support you could ever want with perl CGI stuff right here...

Remember, the more layers of abstraction from the target, the more steps an attacker has to go to...