Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Hiding DBI MySQL username and password values from win98 users

by scratch (Sexton)
on Sep 29, 2002 at 02:42 UTC ( #201514=perlquestion: print w/replies, xml ) Need Help??

scratch has asked for the wisdom of the Perl Monks concerning the following question:

Ok, so I've got a similar, but slightly different question to Protecting your DBI user/password in scripts?.

I've got a bunch of users running a DOS app on win98 pcs and I'd like to add and modify entries in some MySQL tables on a Debian box under my control each time a user opens and closes a certain file. (The DOS app lets me call out to the shell and run perl and the desired times.) The users' pcs all have Perl installed, along with the DBI and other modules.

Right now the script that connects to MySQL passes the username and password value in plain text and they're hardcoded in the script itself. I'd like to be able to hide these values from the users on the off chance that someone gets curious enough to use them to connect and tinker with the values in the tables.

Any suggestions on where I can stash the username and password values so they won't be visible to the users?



Homer: And how is education suppose to make me feel smarter? Besides, everytime I learn something new it pushes some old stuff out of my brain. Remember when I took that home wine making course, and I forgot how to drive?

  • Comment on Hiding DBI MySQL username and password values from win98 users

Replies are listed 'Best First'.
Re: Hiding DBI MySQL username and password values from win98 users
by BrowserUk (Patriarch) on Sep 29, 2002 at 04:18 UTC

    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.

    Cor! Like yer ring! ... HALO dammit! ... 'Ave it yer way! Hal-lo, Mister la-de-da. ... Like yer ring!
      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...


Re: Hiding DBI MySQL username and password values from win98 users
by dws (Chancellor) on Sep 29, 2002 at 03:26 UTC
    Any suggestions on where I can stash the username and password values so they won't be visible to the users?

    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.

Re: Hiding DBI MySQL username and password values from win98 users
by diotalevi (Canon) on Sep 29, 2002 at 04:19 UTC

    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!

Re: Hiding DBI MySQL username and password values from win98 users
by Ryszard (Priest) on Sep 29, 2002 at 19:38 UTC
    BrowserUk has a good point. There is really no security save for the server end.

    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...

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://201514]
Approved by footpad
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (4)
As of 2023-03-23 11:30 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (60 votes). Check out past polls.