Re: Hiding the password
Can you tell us what could be the security problem if Apache is set to run as each user's accounts? Is it a problem if you also allow SSH or Telnet access to users' accounts? Thank you. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "William R. Mussatto" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]> Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Thursday, January 09, 2003 8:56 PM Subject: Re: Hiding the password On Thu, 9 Jan 2003, Octavian Rasnita wrote: > Date: Thu, 9 Jan 2003 07:56:20 +0200 > From: Octavian Rasnita <[EMAIL PROTECTED]> > To: "William R. Mussatto" <[EMAIL PROTECTED]> > Cc: Larry Brown <[EMAIL PROTECTED]>, > MySQL List <[EMAIL PROTECTED]> > Subject: Re: Hiding the password > > Yes I know that Apache can be set to run using your own account, but most > hosts don't do that because I heard that this can create other security > problems. We screen the users we allow to do this. It isolates them, but does allow that apache child to have more rights than 'nobody'. these users already have ftp access, but they are chrooted to their own area. Part of the protection would have to be ensuring the files are not world readable. > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > - Original Message - > From: "William R. Mussatto" <[EMAIL PROTECTED]> > > > Its possible to configure a single virtual host to run as a different > user and group. It still won't protect you from people at the hosting > company, but other hosting clients should be isolated. > Sincerely, William Mussatto, Senior Systems Engineer CyberStrategies, Inc ph. 909-920-9154 ext. 27 - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
If you have a CGI script with 700 permissions, that script cannot be accessed by the Apache server unless that server is running Apache SUID, meaning that your own account runs the web server. In most cases Apache is run by its own account. In this case, if you will set the permissions for the file to 755, the file can be viewed by other accounts from that server. This is because 755 means read and execute permissions for the group and for everyone. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Matthew Baranowski" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]>; "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Monday, January 06, 2003 8:10 PM Subject: Re: Hiding the password Hello Teddy: Could you please be a bit more demonstrative? If I have a module in at Web address on a Apache server with permissions 700, (Warren said he has his scipt to 755, I think) how exactly do you believe a site visitor can access the text of the script? Or how do you think another system user could access the text of the script? I am beginning to think that you operate in a strange, unsecured Web environment. Please lay out a general set of steps by which someone could gain access to the text of a Perl script on a Web server with 700 or 755 permissions. Thanks, Matt Baranowski - Original Message - From: "Octavian Rasnita" <[EMAIL PROTECTED]> To: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Sunday, January 05, 2003 10:33 PM Subject: Re: Hiding the password > No, we are not talking about the staff of the hosting company. > > The hosting company runs a single Apache server on a single account on that > server for all sites that are sitting on that computer. > If the user that runs the web server has access to your files, this means > that everyone has access. > > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > ----- Original Message ----- > From: "Larry Brown" <[EMAIL PROTECTED]> > To: "MySQL List" <[EMAIL PROTECTED]> > Sent: Saturday, January 04, 2003 9:50 PM > Subject: RE: Hiding the password > > > First, why are we conceding that "everyone can find out your id and > password"? Your hosting company has your site separated from other > customers' sites right? So we are just talking about the development team > for your site being privy to this information. > > Second, if you are referring to the staff of the hosting company, you can't > avoid their ability to access data via your login scripts period. As far as > I know they can view all of your communication with the MySQL database and > can get that information. If you want tight security hosting it yourself is > a must in my view. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > > -Original Message- > From: wcb [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 04, 2003 1:51 PM > To: Mark; MySQL > Subject: Re: Hiding the password > > It isn't at all difficult to grasp. Please carefully (and exercising a > certain amount of patience) read my post and the previous post upon which my > post was based. We are acknowledging that EVERYONE can find out your id and > password. The question reformulated is: > > "Given that one's MySql environment may not be accessible in terms of privs > (which is the case for a lot of people, who are paying for hosting by a > third party) and given that we CAN'T hide the id/password combination, is > the standard arrangement that hosts use (which is to ensure that only > localhost can access the database) adequate to prevent people from doing > unwanted things in your database? NOTE that I'm assuming that one has a > script on localhost, and all users are from another domain, and also > assuming that the script is properly set up to constrain the activities of > users, does it even matter that people can determine the id/password > combination??" > > Thanks for patient responses. > > Cheers! > > -warren > > > > > > > > Perhaps gurus can comment on what I'm suggesting here - if the database > is > > > set up so that only "localhost" can access it, then you can use a php or > > > PERL script to allow people from elsewhere to cruise in and make queries > > > as your script allows. > > > > Why is this so difficult to grasp? As I, and many others, have pointed > out, > > repeatedly, it does not matter how many layers you wrap around your > > password-retrieval cod
Re: Hiding the password
I've read more messages from Apache users list and the Apache experts say that if the web server is run by your own account this can create more security problems. I don't know what problems and I would also like to know but if someone wants to know, you can subscribe to that list. ... or if someone knows, please tell us. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Larry Brown" <[EMAIL PROTECTED]> To: "MySQL List" <[EMAIL PROTECTED]> Sent: Monday, January 06, 2003 8:23 PM Subject: RE: Hiding the password This is your problem. Change hosting companies. There should be multiple accounts. At least one for each site and nobody from any other site should be able to log in and view your files. It's called chroot and is the most common method of separating customers of a hosting company. If your description is correct and there is only one account that all of the customers use you will have no security what so ever. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: Octavian Rasnita [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 1:34 AM To: Larry Brown; MySQL List Subject: Re: Hiding the password No, we are not talking about the staff of the hosting company. The hosting company runs a single Apache server on a single account on that server for all sites that are sitting on that computer. If the user that runs the web server has access to your files, this means that everyone has access. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Larry Brown" <[EMAIL PROTECTED]> To: "MySQL List" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 9:50 PM Subject: RE: Hiding the password First, why are we conceding that "everyone can find out your id and password"? Your hosting company has your site separated from other customers' sites right? So we are just talking about the development team for your site being privy to this information. Second, if you are referring to the staff of the hosting company, you can't avoid their ability to access data via your login scripts period. As far as I know they can view all of your communication with the MySQL database and can get that information. If you want tight security hosting it yourself is a must in my view. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message----- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 1:51 PM To: Mark; MySQL Subject: Re: Hiding the password It isn't at all difficult to grasp. Please carefully (and exercising a certain amount of patience) read my post and the previous post upon which my post was based. We are acknowledging that EVERYONE can find out your id and password. The question reformulated is: "Given that one's MySql environment may not be accessible in terms of privs (which is the case for a lot of people, who are paying for hosting by a third party) and given that we CAN'T hide the id/password combination, is the standard arrangement that hosts use (which is to ensure that only localhost can access the database) adequate to prevent people from doing unwanted things in your database? NOTE that I'm assuming that one has a script on localhost, and all users are from another domain, and also assuming that the script is properly set up to constrain the activities of users, does it even matter that people can determine the id/password combination??" Thanks for patient responses. Cheers! -warren > > > Perhaps gurus can comment on what I'm suggesting here - if the database is > > set up so that only "localhost" can access it, then you can use a php or > > PERL script to allow people from elsewhere to cruise in and make queries > > as your script allows. > > Why is this so difficult to grasp? As I, and many others, have pointed out, > repeatedly, it does not matter how many layers you wrap around your > password-retrieval code, as soon as you make the end-result > accessible/readable by your web-CGI, you have done just that: made the > user/password accessible by your web-daemon -- hence, made it accessible to > everyone with access to your web-server. > > And no, adding some sort of access-control within your CGI is equally > useless: as a user being hosted on your web-server I would not bother to run > your CGI, but simply copy it for ocular inspection. :) > > > Certainly I'd appreciate comments on this by people in the know, because > > it is an issue that so many people face... > > Perhaps those people should do what I do: create special MySQL users > (@localhost), unprivileged to the max, with only very narrow SELECT > privileges to the databases they are suppos
Re: Hiding the password
Yes I know that Apache can be set to run using your own account, but most hosts don't do that because I heard that this can create other security problems. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "William R. Mussatto" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]> Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Monday, January 06, 2003 8:07 PM Subject: Re: Hiding the password On Mon, 6 Jan 2003, Octavian Rasnita wrote: > Date: Mon, 6 Jan 2003 08:33:48 +0200 > From: Octavian Rasnita <[EMAIL PROTECTED]> > To: Larry Brown <[EMAIL PROTECTED]>, > MySQL List <[EMAIL PROTECTED]> > Subject: Re: Hiding the password > > No, we are not talking about the staff of the hosting company. > > The hosting company runs a single Apache server on a single account on that > server for all sites that are sitting on that computer. > If the user that runs the web server has access to your files, this means > that everyone has access. > Its possible to configure a single virtual host to run as a different user and group. It still won't protect you from people at the hosting company, but other hosting clients should be isolated. > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > - Original Message - > From: "Larry Brown" <[EMAIL PROTECTED]> > To: "MySQL List" <[EMAIL PROTECTED]> > Sent: Saturday, January 04, 2003 9:50 PM > Subject: RE: Hiding the password > > > First, why are we conceding that "everyone can find out your id and > password"? Your hosting company has your site separated from other > customers' sites right? So we are just talking about the development team > for your site being privy to this information. > > Second, if you are referring to the staff of the hosting company, you can't > avoid their ability to access data via your login scripts period. As far as > I know they can view all of your communication with the MySQL database and > can get that information. If you want tight security hosting it yourself is > a must in my view. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > > -Original Message- > From: wcb [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 04, 2003 1:51 PM > To: Mark; MySQL > Subject: Re: Hiding the password > > It isn't at all difficult to grasp. Please carefully (and exercising a > certain amount of patience) read my post and the previous post upon which my > post was based. We are acknowledging that EVERYONE can find out your id and > password. The question reformulated is: > > "Given that one's MySql environment may not be accessible in terms of privs > (which is the case for a lot of people, who are paying for hosting by a > third party) and given that we CAN'T hide the id/password combination, is > the standard arrangement that hosts use (which is to ensure that only > localhost can access the database) adequate to prevent people from doing > unwanted things in your database? NOTE that I'm assuming that one has a > script on localhost, and all users are from another domain, and also > assuming that the script is properly set up to constrain the activities of > users, does it even matter that people can determine the id/password > combination??" > > Thanks for patient responses. > > Cheers! > > -warren > > > > > > > > Perhaps gurus can comment on what I'm suggesting here - if the database > is > > > set up so that only "localhost" can access it, then you can use a php or > > > PERL script to allow people from elsewhere to cruise in and make queries > > > as your script allows. > > > > Why is this so difficult to grasp? As I, and many others, have pointed > out, > > repeatedly, it does not matter how many layers you wrap around your > > password-retrieval code, as soon as you make the end-result > > accessible/readable by your web-CGI, you have done just that: made the > > user/password accessible by your web-daemon -- hence, made it accessible > to > > everyone with access to your web-server. > > > > And no, adding some sort of access-control within your CGI is equally > > useless: as a user being hosted on your web-server I would not bother to > run > > your CGI, but simply copy it for ocular inspection. :) > > > > > Certainly I'd appreciate comments on this by people in the know, because > > > it is an issue that so many people face... > > >
Re: Hiding the password
I think we must be at cross-purposes. I thought you were talking about
individual sections. That would have been a
wonderful thing. Feasible too, perhaps. The Apache parent ("root"), could
prefork its children, one for each running as
its own user (to which all requests for that vhost are handled).
It would certainly take care of a whole lot of security issues.
- Mark
- Original Message -
From: "Larry Brown" <[EMAIL PROTECTED]>
To: "MySQL List" <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 11:07 PM
Subject: RE: Hiding the password
> Check out the explination of chroot from the following url..
>
> http://www.tcu-inc.com/Articles/23/chroot.html
>
> This is an article about doing more than an apache solution but it
> explains chroot. This is the best model I know of. I read that it is being
> used less often than in the past so there may be some other methods
> that are more prevalent now but this is one definite working solution.
>
> Larry S. Brown
> Dimension Networks, Inc.
> (727) 723-8388
>
> -Original Message-
> From: Mark [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 4:48 PM
> To: William R. Mussatto; Octavian Rasnita
> Cc: Larry Brown; MySQL List
> Subject: Re: Hiding the password
>
> - Original Message -
> From: "William R. Mussatto" <[EMAIL PROTECTED]>
> To: "Octavian Rasnita" <[EMAIL PROTECTED]>
> Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List"
> <[EMAIL PROTECTED]>
> Sent: Monday, January 06, 2003 7:07 PM
> Subject: Re: Hiding the password
>
>
> > Its possible to configure a single virtual host to run as a
> > different user and group.
>
> Oh?? This is entirely new to me. :) Please, enlighten me.
>
> - Mark
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Hiding the password
Mangled from our httpd.conf
User clientsite
Group clientsite
AddHandler cgi-script cgi pl
Options +ExecCGI
ScriptAlias /cgi-bin/ /home/client/clientsite/clientsite/cgi-bin/
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /home/client/clientsite/clientsite
ServerName www.clientsite.com
On Mon, 6 Jan 2003, Larry Brown wrote:
> Date: Mon, 6 Jan 2003 17:44:45 -0500
> From: Larry Brown <[EMAIL PROTECTED]>
> To: MySQL List <[EMAIL PROTECTED]>
> Subject: RE: Hiding the password
>
> It's not as easy as that unless there is something I'm unfamiliar with.
> There are scripts that will help chroot but it isn't just making an entry in
> httpd.conf. It does keep everyone totally separate though. As a shell user
> your / is actually some subfolder on the server. Your folders under / are
> yours and only yours. The sys admin can give or take away ls from your bin
> and so on.
>
> Larry S. Brown
> Dimension Networks, Inc.
> (727) 723-8388
>
> -Original Message-
> From: Mark [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 5:39 PM
> To: Larry Brown; MySQL List
> Subject: Re: Hiding the password
>
> I think we must be at cross-purposes. I thought you were talking about
> individual sections. That would have been a
> wonderful thing. Feasible too, perhaps. The Apache parent ("root"), could
> prefork its children, one for each running as
> its own user (to which all requests for that vhost are handled).
>
> It would certainly take care of a whole lot of security issues.
>
> - Mark
>
>
> - Original Message -----
> From: "Larry Brown" <[EMAIL PROTECTED]>
> To: "MySQL List" <[EMAIL PROTECTED]>
> Sent: Monday, January 06, 2003 11:07 PM
> Subject: RE: Hiding the password
>
>
> > Check out the explination of chroot from the following url..
> >
> > http://www.tcu-inc.com/Articles/23/chroot.html
> >
> > This is an article about doing more than an apache solution but it
> > explains chroot. This is the best model I know of. I read that it is being
> > used less often than in the past so there may be some other methods
> > that are more prevalent now but this is one definite working solution.
> >
> > Larry S. Brown
> > Dimension Networks, Inc.
> > (727) 723-8388
> >
> > -Original Message-
> > From: Mark [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 06, 2003 4:48 PM
> > To: William R. Mussatto; Octavian Rasnita
> > Cc: Larry Brown; MySQL List
> > Subject: Re: Hiding the password
> >
> > - Original Message -
> > From: "William R. Mussatto" <[EMAIL PROTECTED]>
> > To: "Octavian Rasnita" <[EMAIL PROTECTED]>
> > Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List"
> > <[EMAIL PROTECTED]>
> > Sent: Monday, January 06, 2003 7:07 PM
> > Subject: Re: Hiding the password
> >
> >
> > > Its possible to configure a single virtual host to run as a
> > > different user and group.
> >
> > Oh?? This is entirely new to me. :) Please, enlighten me.
> >
> > - Mark
>
>
>
> -
> Before posting, please check:
>http://www.mysql.com/manual.php (the manual)
>http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail <[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
>
Sincerely,
William Mussatto, Senior Systems Engineer
CyberStrategies, Inc
ph. 909-920-9154 ext. 27
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
On Mon, 6 Jan 2003, Mark wrote: > Date: Mon, 6 Jan 2003 22:48:06 +0100 > From: Mark <[EMAIL PROTECTED]> > To: "William R. Mussatto" <[EMAIL PROTECTED]>, > Octavian Rasnita <[EMAIL PROTECTED]> > Cc: Larry Brown <[EMAIL PROTECTED]>, > MySQL List <[EMAIL PROTECTED]> > Subject: Re: Hiding the password > > - Original Message - > From: "William R. Mussatto" <[EMAIL PROTECTED]> > To: "Octavian Rasnita" <[EMAIL PROTECTED]> > Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" > <[EMAIL PROTECTED]> > Sent: Monday, January 06, 2003 7:07 PM > Subject: Re: Hiding the password > > > > Its possible to configure a single virtual host to run as a > > different user and group. > > Oh?? This is entirely new to me. :) Please, enlighten me. > > - Mark We are a hosting company You should be able to request that your virtual host be run with a unique username and group. The apache web server, in our case, normally starts up as 'root' and then changes to a low privege user (e.g., 'nobody'). However, the hosting company can set it up so that the user and group is someone different (e.g., your ftp username). You would also have a separate cgi-bin directory rather than a common one. For your scripts to run only your username could have write permissions on both the files and the directory containing the files. If you didn't set both to 0700 the web serve would refuse to run the script. The downside is you wouldn't be able to use any of the hosting company's standard scripts. Because of past bad experiences we don't normally let users run anything other than perl or php (where we can inspect the source). You can similarly setup php to run in a cgi (vs. a module mode) so that those scripts will also run as a separate user (slower, but safer for everyone). I believe someone else recommended you look at changing your hosting company. Some are more flexible than others. Sincerely, William Mussatto, Senior Systems Engineer CyberStrategies, Inc ph. 909-920-9154 ext. 27 - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Hiding the password
It's not as easy as that unless there is something I'm unfamiliar with.
There are scripts that will help chroot but it isn't just making an entry in
httpd.conf. It does keep everyone totally separate though. As a shell user
your / is actually some subfolder on the server. Your folders under / are
yours and only yours. The sys admin can give or take away ls from your bin
and so on.
Larry S. Brown
Dimension Networks, Inc.
(727) 723-8388
-Original Message-
From: Mark [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 06, 2003 5:39 PM
To: Larry Brown; MySQL List
Subject: Re: Hiding the password
I think we must be at cross-purposes. I thought you were talking about
individual sections. That would have been a
wonderful thing. Feasible too, perhaps. The Apache parent ("root"), could
prefork its children, one for each running as
its own user (to which all requests for that vhost are handled).
It would certainly take care of a whole lot of security issues.
- Mark
- Original Message -
From: "Larry Brown" <[EMAIL PROTECTED]>
To: "MySQL List" <[EMAIL PROTECTED]>
Sent: Monday, January 06, 2003 11:07 PM
Subject: RE: Hiding the password
> Check out the explination of chroot from the following url..
>
> http://www.tcu-inc.com/Articles/23/chroot.html
>
> This is an article about doing more than an apache solution but it
> explains chroot. This is the best model I know of. I read that it is being
> used less often than in the past so there may be some other methods
> that are more prevalent now but this is one definite working solution.
>
> Larry S. Brown
> Dimension Networks, Inc.
> (727) 723-8388
>
> -Original Message-
> From: Mark [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 06, 2003 4:48 PM
> To: William R. Mussatto; Octavian Rasnita
> Cc: Larry Brown; MySQL List
> Subject: Re: Hiding the password
>
> - Original Message -
> From: "William R. Mussatto" <[EMAIL PROTECTED]>
> To: "Octavian Rasnita" <[EMAIL PROTECTED]>
> Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List"
> <[EMAIL PROTECTED]>
> Sent: Monday, January 06, 2003 7:07 PM
> Subject: Re: Hiding the password
>
>
> > Its possible to configure a single virtual host to run as a
> > different user and group.
>
> Oh?? This is entirely new to me. :) Please, enlighten me.
>
> - Mark
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
One other thing about that is that on the section it describes apache it is chrooting the web server separate from other processes on the server. You can chroot the sites handled by apache as well, I just don't have a good example link to offer you. MySQL Larry S. Brown Dimension Networks, Inc. (727) 723-8388 - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
- Original Message - From: "William R. Mussatto" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]> Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Monday, January 06, 2003 7:07 PM Subject: Re: Hiding the password > Its possible to configure a single virtual host to run as a > different user and group. Oh?? This is entirely new to me. :) Please, enlighten me. - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Hiding the password
Check out the explination of chroot from the following url.. http://www.tcu-inc.com/Articles/23/chroot.html This is an article about doing more than an apache solution but it explains chroot. This is the best model I know of. I read that it is being used less often than in the past so there may be some other methods that are more prevalent now but this is one definite working solution. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: Mark [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 4:48 PM To: William R. Mussatto; Octavian Rasnita Cc: Larry Brown; MySQL List Subject: Re: Hiding the password - Original Message - From: "William R. Mussatto" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]> Cc: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Monday, January 06, 2003 7:07 PM Subject: Re: Hiding the password > Its possible to configure a single virtual host to run as a > different user and group. Oh?? This is entirely new to me. :) Please, enlighten me. - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Hiding the password
This is your problem. Change hosting companies. There should be multiple accounts. At least one for each site and nobody from any other site should be able to log in and view your files. It's called chroot and is the most common method of separating customers of a hosting company. If your description is correct and there is only one account that all of the customers use you will have no security what so ever. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: Octavian Rasnita [mailto:[EMAIL PROTECTED]] Sent: Monday, January 06, 2003 1:34 AM To: Larry Brown; MySQL List Subject: Re: Hiding the password No, we are not talking about the staff of the hosting company. The hosting company runs a single Apache server on a single account on that server for all sites that are sitting on that computer. If the user that runs the web server has access to your files, this means that everyone has access. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Larry Brown" <[EMAIL PROTECTED]> To: "MySQL List" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 9:50 PM Subject: RE: Hiding the password First, why are we conceding that "everyone can find out your id and password"? Your hosting company has your site separated from other customers' sites right? So we are just talking about the development team for your site being privy to this information. Second, if you are referring to the staff of the hosting company, you can't avoid their ability to access data via your login scripts period. As far as I know they can view all of your communication with the MySQL database and can get that information. If you want tight security hosting it yourself is a must in my view. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 1:51 PM To: Mark; MySQL Subject: Re: Hiding the password It isn't at all difficult to grasp. Please carefully (and exercising a certain amount of patience) read my post and the previous post upon which my post was based. We are acknowledging that EVERYONE can find out your id and password. The question reformulated is: "Given that one's MySql environment may not be accessible in terms of privs (which is the case for a lot of people, who are paying for hosting by a third party) and given that we CAN'T hide the id/password combination, is the standard arrangement that hosts use (which is to ensure that only localhost can access the database) adequate to prevent people from doing unwanted things in your database? NOTE that I'm assuming that one has a script on localhost, and all users are from another domain, and also assuming that the script is properly set up to constrain the activities of users, does it even matter that people can determine the id/password combination??" Thanks for patient responses. Cheers! -warren > > > Perhaps gurus can comment on what I'm suggesting here - if the database is > > set up so that only "localhost" can access it, then you can use a php or > > PERL script to allow people from elsewhere to cruise in and make queries > > as your script allows. > > Why is this so difficult to grasp? As I, and many others, have pointed out, > repeatedly, it does not matter how many layers you wrap around your > password-retrieval code, as soon as you make the end-result > accessible/readable by your web-CGI, you have done just that: made the > user/password accessible by your web-daemon -- hence, made it accessible to > everyone with access to your web-server. > > And no, adding some sort of access-control within your CGI is equally > useless: as a user being hosted on your web-server I would not bother to run > your CGI, but simply copy it for ocular inspection. :) > > > Certainly I'd appreciate comments on this by people in the know, because > > it is an issue that so many people face... > > Perhaps those people should do what I do: create special MySQL users > (@localhost), unprivileged to the max, with only very narrow SELECT > privileges to the databases they are supposed to read data from, and use > those users to access the MySQL server in your CGI. > > - Mark > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Befo
Re: Hiding the password
Hello Teddy: Could you please be a bit more demonstrative? If I have a module in at Web address on a Apache server with permissions 700, (Warren said he has his scipt to 755, I think) how exactly do you believe a site visitor can access the text of the script? Or how do you think another system user could access the text of the script? I am beginning to think that you operate in a strange, unsecured Web environment. Please lay out a general set of steps by which someone could gain access to the text of a Perl script on a Web server with 700 or 755 permissions. Thanks, Matt Baranowski - Original Message - From: "Octavian Rasnita" <[EMAIL PROTECTED]> To: "Larry Brown" <[EMAIL PROTECTED]>; "MySQL List" <[EMAIL PROTECTED]> Sent: Sunday, January 05, 2003 10:33 PM Subject: Re: Hiding the password > No, we are not talking about the staff of the hosting company. > > The hosting company runs a single Apache server on a single account on that > server for all sites that are sitting on that computer. > If the user that runs the web server has access to your files, this means > that everyone has access. > > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > - Original Message - > From: "Larry Brown" <[EMAIL PROTECTED]> > To: "MySQL List" <[EMAIL PROTECTED]> > Sent: Saturday, January 04, 2003 9:50 PM > Subject: RE: Hiding the password > > > First, why are we conceding that "everyone can find out your id and > password"? Your hosting company has your site separated from other > customers' sites right? So we are just talking about the development team > for your site being privy to this information. > > Second, if you are referring to the staff of the hosting company, you can't > avoid their ability to access data via your login scripts period. As far as > I know they can view all of your communication with the MySQL database and > can get that information. If you want tight security hosting it yourself is > a must in my view. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > > -Original Message- > From: wcb [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 04, 2003 1:51 PM > To: Mark; MySQL > Subject: Re: Hiding the password > > It isn't at all difficult to grasp. Please carefully (and exercising a > certain amount of patience) read my post and the previous post upon which my > post was based. We are acknowledging that EVERYONE can find out your id and > password. The question reformulated is: > > "Given that one's MySql environment may not be accessible in terms of privs > (which is the case for a lot of people, who are paying for hosting by a > third party) and given that we CAN'T hide the id/password combination, is > the standard arrangement that hosts use (which is to ensure that only > localhost can access the database) adequate to prevent people from doing > unwanted things in your database? NOTE that I'm assuming that one has a > script on localhost, and all users are from another domain, and also > assuming that the script is properly set up to constrain the activities of > users, does it even matter that people can determine the id/password > combination??" > > Thanks for patient responses. > > Cheers! > > -warren > > > > > > > > Perhaps gurus can comment on what I'm suggesting here - if the database > is > > > set up so that only "localhost" can access it, then you can use a php or > > > PERL script to allow people from elsewhere to cruise in and make queries > > > as your script allows. > > > > Why is this so difficult to grasp? As I, and many others, have pointed > out, > > repeatedly, it does not matter how many layers you wrap around your > > password-retrieval code, as soon as you make the end-result > > accessible/readable by your web-CGI, you have done just that: made the > > user/password accessible by your web-daemon -- hence, made it accessible > to > > everyone with access to your web-server. > > > > And no, adding some sort of access-control within your CGI is equally > > useless: as a user being hosted on your web-server I would not bother to > run > > your CGI, but simply copy it for ocular inspection. :) > > > > > Certainly I'd appreciate comments on this by people in the know, because > > > it is an issue that so many people face... > > > > Perhaps those people should do what I do: create special MySQL users > > (@localhost), unprivileged to the max, with only very narrow SELECT > > privileges to the d
Re: Hiding the password
On Mon, 6 Jan 2003, Octavian Rasnita wrote: > Date: Mon, 6 Jan 2003 08:33:48 +0200 > From: Octavian Rasnita <[EMAIL PROTECTED]> > To: Larry Brown <[EMAIL PROTECTED]>, > MySQL List <[EMAIL PROTECTED]> > Subject: Re: Hiding the password > > No, we are not talking about the staff of the hosting company. > > The hosting company runs a single Apache server on a single account on that > server for all sites that are sitting on that computer. > If the user that runs the web server has access to your files, this means > that everyone has access. > Its possible to configure a single virtual host to run as a different user and group. It still won't protect you from people at the hosting company, but other hosting clients should be isolated. > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > - Original Message - > From: "Larry Brown" <[EMAIL PROTECTED]> > To: "MySQL List" <[EMAIL PROTECTED]> > Sent: Saturday, January 04, 2003 9:50 PM > Subject: RE: Hiding the password > > > First, why are we conceding that "everyone can find out your id and > password"? Your hosting company has your site separated from other > customers' sites right? So we are just talking about the development team > for your site being privy to this information. > > Second, if you are referring to the staff of the hosting company, you can't > avoid their ability to access data via your login scripts period. As far as > I know they can view all of your communication with the MySQL database and > can get that information. If you want tight security hosting it yourself is > a must in my view. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > > -Original Message- > From: wcb [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 04, 2003 1:51 PM > To: Mark; MySQL > Subject: Re: Hiding the password > > It isn't at all difficult to grasp. Please carefully (and exercising a > certain amount of patience) read my post and the previous post upon which my > post was based. We are acknowledging that EVERYONE can find out your id and > password. The question reformulated is: > > "Given that one's MySql environment may not be accessible in terms of privs > (which is the case for a lot of people, who are paying for hosting by a > third party) and given that we CAN'T hide the id/password combination, is > the standard arrangement that hosts use (which is to ensure that only > localhost can access the database) adequate to prevent people from doing > unwanted things in your database? NOTE that I'm assuming that one has a > script on localhost, and all users are from another domain, and also > assuming that the script is properly set up to constrain the activities of > users, does it even matter that people can determine the id/password > combination??" > > Thanks for patient responses. > > Cheers! > > -warren > > > > > > > > Perhaps gurus can comment on what I'm suggesting here - if the database > is > > > set up so that only "localhost" can access it, then you can use a php or > > > PERL script to allow people from elsewhere to cruise in and make queries > > > as your script allows. > > > > Why is this so difficult to grasp? As I, and many others, have pointed > out, > > repeatedly, it does not matter how many layers you wrap around your > > password-retrieval code, as soon as you make the end-result > > accessible/readable by your web-CGI, you have done just that: made the > > user/password accessible by your web-daemon -- hence, made it accessible > to > > everyone with access to your web-server. > > > > And no, adding some sort of access-control within your CGI is equally > > useless: as a user being hosted on your web-server I would not bother to > run > > your CGI, but simply copy it for ocular inspection. :) > > > > > Certainly I'd appreciate comments on this by people in the know, because > > > it is an issue that so many people face... > > > > Perhaps those people should do what I do: create special MySQL users > > (@localhost), unprivileged to the max, with only very narrow SELECT > > privileges to the databases they are supposed to read data from, and use > > those users to access the MySQL server in your CGI. > > > > - Mark > > > > > > - > > Before posting, please check: > >http://www.mysql.com/manual.php (the manual) > >http://l
Re: Hiding the password
Oh yes this is the problem. If they are logged on the server. More hosting companies offer SSH access or telnet access for their customers and they can see the original Perl or PHP files, not the result processed by the web server. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Larry Brown" <[EMAIL PROTECTED]> To: "MySQL List" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 10:36 PM Subject: RE: Hiding the password When someone hits a php page the server runs the script executing the login and password and just sends results to the users. (unless I'm mistaken) So the user can't see that login name and password. If they view the source it just shows the html the script generated. So is the application you are giving them access to one that allows them to view and modify scripts on that site? Let's say to access the database the script logs in with user "root" pass "password". The script would log into the db with those credentials and then prompt the user for their login and password. Their login and password would be stored on a table within the database that is open. Their response would be checked and they would be granted access to the next page. The next page would the log back into the database still not viewed by the client and then pull data as your script executes or publish data all in the background while the client is just seeing the html that the script generates. I don't see how they could see what is written on the script unless they are logged in to the server or the application you are talking about them accessing is one that allows them to view scripts etc. If I'm wrong or if there is something I'm missing here please let me know. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 2:55 PM To: Larry Brown Subject: Re: Hiding the password Hi! I may be misunderstanding some things. However, as best I can here is what I am thinking. I believe that people can find out my id and password because I use scripts to permit people to enter information or delete information. I have been setting up a little housing registry and also a learning/testing site for example. So I have (in these cases) php scripts allowing people to log in and then allowing them to access the applications. The scripts always have to be the "localhost" connection to the database, so they have to log in and all users have access to my scripts. So (as I see it) everyone could potentially see the id and password.On the other hand that doesn't seem to be a huge worry because unless they can connect as localhost using their own scripts or application, then they have to use my scripts and they can't do anything especially evil (not that they want to . . .). I would definitely agree that if you want airtight security you have to do your own hosting. . . However, at the moment I'm busy with other things so that just isn't a possibility. I'd love to have full access to the user privileges, etc. but that will be maybe a year from now. . . Thanks! -warren > First, why are we conceding that "everyone can find out your id and > password"? Your hosting company has your site separated from other > customers' sites right? So we are just talking about the development team > for your site being privy to this information. > > Second, if you are referring to the staff of the hosting company, you can't > avoid their ability to access data via your login scripts period. As far as > I know they can view all of your communication with the MySQL database and > can get that information. If you want tight security hosting it yourself is > a must in my view. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
I have another suggestion, ... a little bit more complicated. It could be made an executable (binary) file that are returning the password and the username. That executable will return a different username and password if it is run in another path or on another server. So it should be run from its location to be able to return the real password and username. Somehow (I don't know how) that executable should return a bad username and password if it is not run by the script1.pl, or script2.pl, or other defined scripts from some locations. Every time that executable will return a bad password it should send you an email warning that someone tries to get into your database, and you can report it to your hosting company. I guess this may be hacked by a good programmer, but at least it might warn you and you could change your password, etc. I don't know how to verify that a program is run by another, however, and this is important. Too bad that Unix has a so big security hole. It would be wonderfull if the perlcc compiler would be working better. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "wcb" <[EMAIL PROTECTED]> To: "MySQL" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 7:41 PM Subject: Re: Hiding the password Hi! Perhaps gurus can comment on what I'm suggesting here - if the database is set up so that only "localhost" can access it, then you can use a php or PERL script to allow people from elsewhere to cruise in and make queries as your script allows. As long as your script is set up to be secure (for example, not to allow special characters like ~ or &^$, etc.) then unless they break into your server they can't do anything you don't want them to. In other words, it doesn't matter if the id and password for the database are known (and you can't really hide it on the Internet) because as long as the server's identity is different from the domains cruising in, they are constrained by your php script (or PERL script). It may be helpful to do something like this: include($DOCUMENT_ROOT.'/include/database.php'); so that the id and password are stored in another folder. However, sophisticated users will still be able to track the id and password down. . . Certainly I'd appreciate comments on this by people in the know, because it is an issue that so many people face . . . Cheers! -warren - Original Message - From: "Octavian Rasnita" <[EMAIL PROTECTED]> To: "Benjamin Pflugmann" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 8:47 AM Subject: Re: Hiding the password > Well, I guess the best solution would be to use a Windows server. > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > - Original Message - > From: "Benjamin Pflugmann" <[EMAIL PROTECTED]> > To: "Octavian Rasnita" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, December 25, 2002 8:39 PM > Subject: Re: Hiding the password > > > Hello. > > On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote: > > Hi all, > > > > I want to make a CGI program in Perl that queries a MySQL database, and > the > > problem is that I need to write the password for the database in the > program > > and this password can be seen by any user that has an account on that > > server. > > > > I need to gave 755 permissions to CGI scripts because they need to be > > executed by the web server account, and not by my account. > > > > Do you have any tips for hiding the password, > > Not really. Whereever you put it, the web server account has be able > to access it, so the problem stays. Even if you could arrange that > only the web server account can read it (e.g. by changing the owner of > a file containing the password), every user with permission to create > CGI scripts can still write a script to read the data. > > > or accessing MySQL from CGI scripts is not secure at all? > > Well, it is as secure as the server is set up. E.g. one can set up > Apache so that it executes CGIs as the user to whom the script > belongs. I know this has its own problems... it was only intended as > example that it is a question of the server configuration. > > The "best" way is always a compromise and depends on how the server is > used. If the server configuration is not in your hands, I don't there > is much you can do, except asking the admin which way she suggests. > > HTH, > > Benjamin. > > -- > [EMAIL PROTECTED] > > > > - >
Re: Hiding the password
No, we are not talking about the staff of the hosting company. The hosting company runs a single Apache server on a single account on that server for all sites that are sitting on that computer. If the user that runs the web server has access to your files, this means that everyone has access. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Larry Brown" <[EMAIL PROTECTED]> To: "MySQL List" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 9:50 PM Subject: RE: Hiding the password First, why are we conceding that "everyone can find out your id and password"? Your hosting company has your site separated from other customers' sites right? So we are just talking about the development team for your site being privy to this information. Second, if you are referring to the staff of the hosting company, you can't avoid their ability to access data via your login scripts period. As far as I know they can view all of your communication with the MySQL database and can get that information. If you want tight security hosting it yourself is a must in my view. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 1:51 PM To: Mark; MySQL Subject: Re: Hiding the password It isn't at all difficult to grasp. Please carefully (and exercising a certain amount of patience) read my post and the previous post upon which my post was based. We are acknowledging that EVERYONE can find out your id and password. The question reformulated is: "Given that one's MySql environment may not be accessible in terms of privs (which is the case for a lot of people, who are paying for hosting by a third party) and given that we CAN'T hide the id/password combination, is the standard arrangement that hosts use (which is to ensure that only localhost can access the database) adequate to prevent people from doing unwanted things in your database? NOTE that I'm assuming that one has a script on localhost, and all users are from another domain, and also assuming that the script is properly set up to constrain the activities of users, does it even matter that people can determine the id/password combination??" Thanks for patient responses. Cheers! -warren > > > Perhaps gurus can comment on what I'm suggesting here - if the database is > > set up so that only "localhost" can access it, then you can use a php or > > PERL script to allow people from elsewhere to cruise in and make queries > > as your script allows. > > Why is this so difficult to grasp? As I, and many others, have pointed out, > repeatedly, it does not matter how many layers you wrap around your > password-retrieval code, as soon as you make the end-result > accessible/readable by your web-CGI, you have done just that: made the > user/password accessible by your web-daemon -- hence, made it accessible to > everyone with access to your web-server. > > And no, adding some sort of access-control within your CGI is equally > useless: as a user being hosted on your web-server I would not bother to run > your CGI, but simply copy it for ocular inspection. :) > > > Certainly I'd appreciate comments on this by people in the know, because > > it is an issue that so many people face... > > Perhaps those people should do what I do: create special MySQL users > (@localhost), unprivileged to the max, with only very narrow SELECT > privileges to the databases they are supposed to read data from, and use > those users to access the MySQL server in your CGI. > > - Mark > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://
Re: Hiding the password
If you will put the password in the .pm module, that module must be viewed
by everyone because it must be viewed by the user that runs the Apache
server.
In this case, someone could take a look what is in that module.
Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]
- Original Message -
From: "JamesD" <[EMAIL PROTECTED]>
To: "wcb" <[EMAIL PROTECTED]>; "MySQL" <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 9:29 PM
Subject: RE: Hiding the password
In perl,
a. setup dsn in a separate module (sep.pm) with a method "connect(parameters
to setup db...)"
make sure the directory is not under the webserver doc path
sub connect {
return (DBI->connect ($dsn, "$user","$pass",
{PrintError => 0, RaiseError => 1}));
}
b. in the main script add the non-standard library to @INC with
"use lib qw(path-to-sep.pm);"
c. bring the package in to main script with
"use sep;"
d. connect to db with
"my $dbh = sep::connect();"
e. continue...
sep.pm holds user name and password and only returns the database handle to
main script'
this ensures username password is secure. the connect in sep.pm can
use a username that has been granted limited privileges, etc...
script a can call connect() with user x,
script b can call connect1() with user y, etc.
if you have access to apache webserver, you can put step b in an apache
startup script
so your scripts dont even have to add the nonstandard lib location
i would expect there are even more security enhancements that can be done...
hope that helps
Jim
-Original Message-
From: wcb [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 04, 2003 9:42 AM
To: MySQL
Subject: Re: Hiding the password
Hi!
Perhaps gurus can comment on what I'm suggesting here - if the database is
set up so that only "localhost" can access it, then you can use a php or
PERL script to allow people from elsewhere to cruise in and make queries as
your script allows. As long as your script is set up to be secure (for
example, not to allow special characters like ~ or &^$, etc.) then unless
they break into your server they can't do anything you don't want them to.
In other words, it doesn't matter if the id and password for the database
are known (and you can't really hide it on the Internet) because as long as
the server's identity is different from the domains cruising in, they are
constrained by your php script (or PERL script).
It may be helpful to do something like this:
include($DOCUMENT_ROOT.'/include/database.php');
so that the id and password are stored in another folder. However,
sophisticated users will still be able to track the id and password down. .
.
Certainly I'd appreciate comments on this by people in the know, because it
is an issue that so many people face . . .
Cheers!
-warren
- Original Message -
From: "Octavian Rasnita" <[EMAIL PROTECTED]>
To: "Benjamin Pflugmann" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 8:47 AM
Subject: Re: Hiding the password
> Well, I guess the best solution would be to use a Windows server.
>
> Teddy,
> Teddy's Center: http://teddy.fcc.ro/
> Email: [EMAIL PROTECTED]
>
> - Original Message -
> From: "Benjamin Pflugmann" <[EMAIL PROTECTED]>
> To: "Octavian Rasnita" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, December 25, 2002 8:39 PM
> Subject: Re: Hiding the password
>
>
> Hello.
>
> On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > I want to make a CGI program in Perl that queries a MySQL database, and
> the
> > problem is that I need to write the password for the database in the
> program
> > and this password can be seen by any user that has an account on that
> > server.
> >
> > I need to gave 755 permissions to CGI scripts because they need to be
> > executed by the web server account, and not by my account.
> >
> > Do you have any tips for hiding the password,
>
> Not really. Whereever you put it, the web server account has be able
> to access it, so the problem stays. Even if you could arrange that
> only the web server account can read it (e.g. by changing the owner of
> a file containing the password), every user with permission to create
> CGI scripts can still write a script to read the data.
>
> > or accessing MySQL from CGI scripts is not secure at all?
>
> Well, it is as secure as the server is set up. E.g. one can set up
> Apache so that it executes CGIs as the user to whom the script
> belongs. I know this has its own problems... it was only intended as
> ex
RE: Hiding the password
Unless someone else knows differently I don't think any amount of know-how from a visitor to the site will allow them to view the script itself unless some mishap happened to the web server and it stopped parsing the script and just diplayed the contents or if it didn't recognize the tags for some reason. If someone knows differently please let me know. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 3:52 PM To: Larry Brown Subject: Re: Hiding the password Hi! Oh no, the people who log in cannot modify scripts. That would be suicide. . . They log via something I made that maintains an md5 hash (quite a long one) which is their "log-in flag" maintained via a cookie while they are logged in. It also requires the user's personal password (which has nothing to do with the database). Then they can access the database via scripts. The database id and password are buried in an "include" script. The scripts just do some inserting and updating on tables that "belong" to the person in question, so they can (in the case of the learning/testing application for instance) enter test questions and post tests that their students can access. I'm hoping that people can't get access to the id and password but I have always assumed that someone with ability may be able to extract the script itself and examine it. However, since they can't log in to the server (but only to my "log in" facility, which allows them access to a folder containing a script which they cannot modify) they are not "localhost" users or visitors. The scripts they can access reside on localhost, but nobody can touch the scripts. . . Thanks again! I'm feeling somewhat better! Cheers! -warren - Original Message - From: "Larry Brown" <[EMAIL PROTECTED]> To: "wcb" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 12:33 PM Subject: RE: Hiding the password > When someone hits a php page the server runs the script executing the login > and password and just sends results to the users. (unless I'm mistaken) So > the user can't see that login name and password. If they view the source it > just shows the html the script generated. So is the application you are > giving them access to one that allows them to view and modify scripts on > that site? Let's say to access the database the script logs in with user > "root" pass "password". The script would log into the db with those > credentials and then prompt the user for their login and password. Their > login and password would be stored on a table within the database that is > open. Their response would be checked and they would be granted access to > the next page. The next page would the log back into the database still not > viewed by the client and then pull data as your script executes or publish > data all in the background while the client is just seeing the html that the > script generates. I don't see how they could see what is written on the > script unless they are logged in to the server or the application you are > talking about them accessing is one that allows them to view scripts etc. > If I'm wrong or if there is something I'm missing here please let me know. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > > -Original Message- > From: wcb [mailto:[EMAIL PROTECTED]] > Sent: Saturday, January 04, 2003 2:55 PM > To: Larry Brown > Subject: Re: Hiding the password > > Hi! > > I may be misunderstanding some things. However, as best I can here is what > I am thinking. > > I believe that people can find out my id and password because I use scripts > to permit people to enter information or delete information. I have been > setting up a little housing registry and also a learning/testing site for > example. So I have (in these cases) php scripts allowing people to log in > and then allowing them to access the applications. The scripts always have > to be the "localhost" connection to the database, so they have to log in and > all users have access to my scripts. So (as I see it) everyone could > potentially see the id and password.On the other hand that doesn't seem > to be a huge worry because unless they can connect as localhost using their > own scripts or application, then they have to use my scripts and they can't > do anything especially evil (not that they want to . . .). > > I would definitely agree that if you want airtight security you have to do > your own hosting. . . However, at the moment I'm busy with other things so > that just isn't a possibility. I'd love to have ful
RE: Hiding the password
When someone hits a php page the server runs the script executing the login and password and just sends results to the users. (unless I'm mistaken) So the user can't see that login name and password. If they view the source it just shows the html the script generated. So is the application you are giving them access to one that allows them to view and modify scripts on that site? Let's say to access the database the script logs in with user "root" pass "password". The script would log into the db with those credentials and then prompt the user for their login and password. Their login and password would be stored on a table within the database that is open. Their response would be checked and they would be granted access to the next page. The next page would the log back into the database still not viewed by the client and then pull data as your script executes or publish data all in the background while the client is just seeing the html that the script generates. I don't see how they could see what is written on the script unless they are logged in to the server or the application you are talking about them accessing is one that allows them to view scripts etc. If I'm wrong or if there is something I'm missing here please let me know. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 2:55 PM To: Larry Brown Subject: Re: Hiding the password Hi! I may be misunderstanding some things. However, as best I can here is what I am thinking. I believe that people can find out my id and password because I use scripts to permit people to enter information or delete information. I have been setting up a little housing registry and also a learning/testing site for example. So I have (in these cases) php scripts allowing people to log in and then allowing them to access the applications. The scripts always have to be the "localhost" connection to the database, so they have to log in and all users have access to my scripts. So (as I see it) everyone could potentially see the id and password.On the other hand that doesn't seem to be a huge worry because unless they can connect as localhost using their own scripts or application, then they have to use my scripts and they can't do anything especially evil (not that they want to . . .). I would definitely agree that if you want airtight security you have to do your own hosting. . . However, at the moment I'm busy with other things so that just isn't a possibility. I'd love to have full access to the user privileges, etc. but that will be maybe a year from now. . . Thanks! -warren > First, why are we conceding that "everyone can find out your id and > password"? Your hosting company has your site separated from other > customers' sites right? So we are just talking about the development team > for your site being privy to this information. > > Second, if you are referring to the staff of the hosting company, you can't > avoid their ability to access data via your login scripts period. As far as > I know they can view all of your communication with the MySQL database and > can get that information. If you want tight security hosting it yourself is > a must in my view. > > Larry S. Brown > Dimension Networks, Inc. > (727) 723-8388 > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Hiding the password
First, why are we conceding that "everyone can find out your id and password"? Your hosting company has your site separated from other customers' sites right? So we are just talking about the development team for your site being privy to this information. Second, if you are referring to the staff of the hosting company, you can't avoid their ability to access data via your login scripts period. As far as I know they can view all of your communication with the MySQL database and can get that information. If you want tight security hosting it yourself is a must in my view. Larry S. Brown Dimension Networks, Inc. (727) 723-8388 -Original Message- From: wcb [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 04, 2003 1:51 PM To: Mark; MySQL Subject: Re: Hiding the password It isn't at all difficult to grasp. Please carefully (and exercising a certain amount of patience) read my post and the previous post upon which my post was based. We are acknowledging that EVERYONE can find out your id and password. The question reformulated is: "Given that one's MySql environment may not be accessible in terms of privs (which is the case for a lot of people, who are paying for hosting by a third party) and given that we CAN'T hide the id/password combination, is the standard arrangement that hosts use (which is to ensure that only localhost can access the database) adequate to prevent people from doing unwanted things in your database? NOTE that I'm assuming that one has a script on localhost, and all users are from another domain, and also assuming that the script is properly set up to constrain the activities of users, does it even matter that people can determine the id/password combination??" Thanks for patient responses. Cheers! -warren > > > Perhaps gurus can comment on what I'm suggesting here - if the database is > > set up so that only "localhost" can access it, then you can use a php or > > PERL script to allow people from elsewhere to cruise in and make queries > > as your script allows. > > Why is this so difficult to grasp? As I, and many others, have pointed out, > repeatedly, it does not matter how many layers you wrap around your > password-retrieval code, as soon as you make the end-result > accessible/readable by your web-CGI, you have done just that: made the > user/password accessible by your web-daemon -- hence, made it accessible to > everyone with access to your web-server. > > And no, adding some sort of access-control within your CGI is equally > useless: as a user being hosted on your web-server I would not bother to run > your CGI, but simply copy it for ocular inspection. :) > > > Certainly I'd appreciate comments on this by people in the know, because > > it is an issue that so many people face... > > Perhaps those people should do what I do: create special MySQL users > (@localhost), unprivileged to the max, with only very narrow SELECT > privileges to the databases they are supposed to read data from, and use > those users to access the MySQL server in your CGI. > > - Mark > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
- Original Message - From: "wcb" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]>; "MySQL" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 7:51 PM Subject: Re: Hiding the password > It isn't at all difficult to grasp. Please carefully (and exercising a > certain amount of patience) read my post and the previous post upon which > my post was based. We are acknowledging that EVERYONE can find out your id > and password. The question reformulated is: > > "Given that one's MySql environment may not be accessible in terms of > privs (which is the case for a lot of people, who are paying for hosting > by a third party) and given that we CAN'T hide the id/password > combination, is the standard arrangement that hosts use (which is to > ensure that only localhost can access the database) adequate to prevent > people from doing unwanted things in your database? After having read your reply very carefully, really, I still found problems with your setup: Assuming that your ISP creates user(s) for you, and has them default to localhost only, then your problem still remains, and is perhaps even larger. Because when the entire localhost can access your database, then every user with shell access on your box (or with web-pages on your system!) has access to your databases. > NOTE that I'm assuming that one has a script on localhost, and all users > are from another domain ... If you are really the ONLY user on your system, and you have not given web-access to anyone else, and you trust your DNS, then I suppose you are safe. > and also > assuming that the script is properly set up to constrain the activities > of users... Of users? Earlier you had written, "As long as your script is set up to be secure (for example, not to allow special characters like ~ or &^$, etc.)," the ~ character you mentioned (see how carefully I read your post?) seemed to indicate you were protecting your script from misusing users' home directories. If you only have "visitors" on your system, and not users, then, and only then, you are safe. Otherwise all other users on your system will share your localhost privileges. - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
RE: Hiding the password
In perl,
a. setup dsn in a separate module (sep.pm) with a method "connect(parameters
to setup db...)"
make sure the directory is not under the webserver doc path
sub connect {
return (DBI->connect ($dsn, "$user","$pass",
{PrintError => 0, RaiseError => 1}));
}
b. in the main script add the non-standard library to @INC with
"use lib qw(path-to-sep.pm);"
c. bring the package in to main script with
"use sep;"
d. connect to db with
"my $dbh = sep::connect();"
e. continue...
sep.pm holds user name and password and only returns the database handle to
main script'
this ensures username password is secure. the connect in sep.pm can
use a username that has been granted limited privileges, etc...
script a can call connect() with user x,
script b can call connect1() with user y, etc.
if you have access to apache webserver, you can put step b in an apache
startup script
so your scripts dont even have to add the nonstandard lib location
i would expect there are even more security enhancements that can be done...
hope that helps
Jim
-Original Message-
From: wcb [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 04, 2003 9:42 AM
To: MySQL
Subject: Re: Hiding the password
Hi!
Perhaps gurus can comment on what I'm suggesting here - if the database is
set up so that only "localhost" can access it, then you can use a php or
PERL script to allow people from elsewhere to cruise in and make queries as
your script allows. As long as your script is set up to be secure (for
example, not to allow special characters like ~ or &^$, etc.) then unless
they break into your server they can't do anything you don't want them to.
In other words, it doesn't matter if the id and password for the database
are known (and you can't really hide it on the Internet) because as long as
the server's identity is different from the domains cruising in, they are
constrained by your php script (or PERL script).
It may be helpful to do something like this:
include($DOCUMENT_ROOT.'/include/database.php');
so that the id and password are stored in another folder. However,
sophisticated users will still be able to track the id and password down. .
.
Certainly I'd appreciate comments on this by people in the know, because it
is an issue that so many people face . . .
Cheers!
-warren
- Original Message -
From: "Octavian Rasnita" <[EMAIL PROTECTED]>
To: "Benjamin Pflugmann" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 8:47 AM
Subject: Re: Hiding the password
> Well, I guess the best solution would be to use a Windows server.
>
> Teddy,
> Teddy's Center: http://teddy.fcc.ro/
> Email: [EMAIL PROTECTED]
>
> - Original Message -
> From: "Benjamin Pflugmann" <[EMAIL PROTECTED]>
> To: "Octavian Rasnita" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Wednesday, December 25, 2002 8:39 PM
> Subject: Re: Hiding the password
>
>
> Hello.
>
> On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > I want to make a CGI program in Perl that queries a MySQL database, and
> the
> > problem is that I need to write the password for the database in the
> program
> > and this password can be seen by any user that has an account on that
> > server.
> >
> > I need to gave 755 permissions to CGI scripts because they need to be
> > executed by the web server account, and not by my account.
> >
> > Do you have any tips for hiding the password,
>
> Not really. Whereever you put it, the web server account has be able
> to access it, so the problem stays. Even if you could arrange that
> only the web server account can read it (e.g. by changing the owner of
> a file containing the password), every user with permission to create
> CGI scripts can still write a script to read the data.
>
> > or accessing MySQL from CGI scripts is not secure at all?
>
> Well, it is as secure as the server is set up. E.g. one can set up
> Apache so that it executes CGIs as the user to whom the script
> belongs. I know this has its own problems... it was only intended as
> example that it is a question of the server configuration.
>
> The "best" way is always a compromise and depends on how the server is
> used. If the server configuration is not in your hands, I don't there
> is much you can do, except asking the admin which way she suggests.
>
> HTH,
>
> Benjamin.
>
> --
> [EMAIL PROTECTED]
>
>
>
>
Re: Hiding the password
It isn't at all difficult to grasp. Please carefully (and exercising a certain amount of patience) read my post and the previous post upon which my post was based. We are acknowledging that EVERYONE can find out your id and password. The question reformulated is: "Given that one's MySql environment may not be accessible in terms of privs (which is the case for a lot of people, who are paying for hosting by a third party) and given that we CAN'T hide the id/password combination, is the standard arrangement that hosts use (which is to ensure that only localhost can access the database) adequate to prevent people from doing unwanted things in your database? NOTE that I'm assuming that one has a script on localhost, and all users are from another domain, and also assuming that the script is properly set up to constrain the activities of users, does it even matter that people can determine the id/password combination??" Thanks for patient responses. Cheers! -warren > > > Perhaps gurus can comment on what I'm suggesting here - if the database is > > set up so that only "localhost" can access it, then you can use a php or > > PERL script to allow people from elsewhere to cruise in and make queries > > as your script allows. > > Why is this so difficult to grasp? As I, and many others, have pointed out, > repeatedly, it does not matter how many layers you wrap around your > password-retrieval code, as soon as you make the end-result > accessible/readable by your web-CGI, you have done just that: made the > user/password accessible by your web-daemon -- hence, made it accessible to > everyone with access to your web-server. > > And no, adding some sort of access-control within your CGI is equally > useless: as a user being hosted on your web-server I would not bother to run > your CGI, but simply copy it for ocular inspection. :) > > > Certainly I'd appreciate comments on this by people in the know, because > > it is an issue that so many people face... > > Perhaps those people should do what I do: create special MySQL users > (@localhost), unprivileged to the max, with only very narrow SELECT > privileges to the databases they are supposed to read data from, and use > those users to access the MySQL server in your CGI. > > - Mark > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
- Original Message - From: "wcb" <[EMAIL PROTECTED]> To: "MySQL" <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 6:41 PM Subject: Re: Hiding the password > Perhaps gurus can comment on what I'm suggesting here - if the database is > set up so that only "localhost" can access it, then you can use a php or > PERL script to allow people from elsewhere to cruise in and make queries > as your script allows. Why is this so difficult to grasp? As I, and many others, have pointed out, repeatedly, it does not matter how many layers you wrap around your password-retrieval code, as soon as you make the end-result accessible/readable by your web-CGI, you have done just that: made the user/password accessible by your web-daemon -- hence, made it accessible to everyone with access to your web-server. And no, adding some sort of access-control within your CGI is equally useless: as a user being hosted on your web-server I would not bother to run your CGI, but simply copy it for ocular inspection. :) > Certainly I'd appreciate comments on this by people in the know, because > it is an issue that so many people face... Perhaps those people should do what I do: create special MySQL users (@localhost), unprivileged to the max, with only very narrow SELECT privileges to the databases they are supposed to read data from, and use those users to access the MySQL server in your CGI. - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
Hi! Perhaps gurus can comment on what I'm suggesting here - if the database is set up so that only "localhost" can access it, then you can use a php or PERL script to allow people from elsewhere to cruise in and make queries as your script allows. As long as your script is set up to be secure (for example, not to allow special characters like ~ or &^$, etc.) then unless they break into your server they can't do anything you don't want them to. In other words, it doesn't matter if the id and password for the database are known (and you can't really hide it on the Internet) because as long as the server's identity is different from the domains cruising in, they are constrained by your php script (or PERL script). It may be helpful to do something like this: include($DOCUMENT_ROOT.'/include/database.php'); so that the id and password are stored in another folder. However, sophisticated users will still be able to track the id and password down. . . Certainly I'd appreciate comments on this by people in the know, because it is an issue that so many people face . . . Cheers! -warren - Original Message - From: "Octavian Rasnita" <[EMAIL PROTECTED]> To: "Benjamin Pflugmann" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, January 04, 2003 8:47 AM Subject: Re: Hiding the password > Well, I guess the best solution would be to use a Windows server. > > Teddy, > Teddy's Center: http://teddy.fcc.ro/ > Email: [EMAIL PROTECTED] > > - Original Message - > From: "Benjamin Pflugmann" <[EMAIL PROTECTED]> > To: "Octavian Rasnita" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, December 25, 2002 8:39 PM > Subject: Re: Hiding the password > > > Hello. > > On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote: > > Hi all, > > > > I want to make a CGI program in Perl that queries a MySQL database, and > the > > problem is that I need to write the password for the database in the > program > > and this password can be seen by any user that has an account on that > > server. > > > > I need to gave 755 permissions to CGI scripts because they need to be > > executed by the web server account, and not by my account. > > > > Do you have any tips for hiding the password, > > Not really. Whereever you put it, the web server account has be able > to access it, so the problem stays. Even if you could arrange that > only the web server account can read it (e.g. by changing the owner of > a file containing the password), every user with permission to create > CGI scripts can still write a script to read the data. > > > or accessing MySQL from CGI scripts is not secure at all? > > Well, it is as secure as the server is set up. E.g. one can set up > Apache so that it executes CGIs as the user to whom the script > belongs. I know this has its own problems... it was only intended as > example that it is a question of the server configuration. > > The "best" way is always a compromise and depends on how the server is > used. If the server configuration is not in your hands, I don't there > is much you can do, except asking the admin which way she suggests. > > HTH, > > Benjamin. > > -- > [EMAIL PROTECTED] > > > > - > Before posting, please check: >http://www.mysql.com/manual.php (the manual) >http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
It is exactly the same thing with a PHP script.
If someone has and account on that server, they can login and read the php
file.
Teddy,
Teddy's Center: http://teddy.fcc.ro/
Email: [EMAIL PROTECTED]
- Original Message -
From: "Brent Bailey" <[EMAIL PROTECTED]>
To: "Benjamin Pflugmann" <[EMAIL PROTECTED]>
Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, December 26, 2002 4:26 PM
Subject: Re: Hiding the password
i would try using php to have you page connect to the mysql database.. The
code gets parsed
first then is loaded into the browser...so the user & pass for the database
is never seen.. i
would use something like:
$db = mysql_connect("localhost", "mysql-user", "mysql-user-password");
mysql_select_db("whatever-database-name",$db);
Brent
Benjamin Pflugmann wrote:
> Hello.
>
> On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > I want to make a CGI program in Perl that queries a MySQL database, and
the
> > problem is that I need to write the password for the database in the
program
> > and this password can be seen by any user that has an account on that
> > server.
> >
> > I need to gave 755 permissions to CGI scripts because they need to be
> > executed by the web server account, and not by my account.
> >
> > Do you have any tips for hiding the password,
>
> Not really. Whereever you put it, the web server account has be able
> to access it, so the problem stays. Even if you could arrange that
> only the web server account can read it (e.g. by changing the owner of
> a file containing the password), every user with permission to create
> CGI scripts can still write a script to read the data.
>
> > or accessing MySQL from CGI scripts is not secure at all?
>
> Well, it is as secure as the server is set up. E.g. one can set up
> Apache so that it executes CGIs as the user to whom the script
> belongs. I know this has its own problems... it was only intended as
> example that it is a question of the server configuration.
>
> The "best" way is always a compromise and depends on how the server is
> used. If the server configuration is not in your hands, I don't there
> is much you can do, except asking the admin which way she suggests.
>
> HTH,
>
> Benjamin.
>
> --
> [EMAIL PROTECTED]
>
> -
> Before posting, please check:
>http://www.mysql.com/manual.php (the manual)
>http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
<[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
--
Brent Bailey CCNA
High Speed Data Services
MetroCast Cablevision
603-332-8629 ext:242
[EMAIL PROTECTED]
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
Well, I guess the best solution would be to use a Windows server. Teddy, Teddy's Center: http://teddy.fcc.ro/ Email: [EMAIL PROTECTED] - Original Message - From: "Benjamin Pflugmann" <[EMAIL PROTECTED]> To: "Octavian Rasnita" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, December 25, 2002 8:39 PM Subject: Re: Hiding the password Hello. On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote: > Hi all, > > I want to make a CGI program in Perl that queries a MySQL database, and the > problem is that I need to write the password for the database in the program > and this password can be seen by any user that has an account on that > server. > > I need to gave 755 permissions to CGI scripts because they need to be > executed by the web server account, and not by my account. > > Do you have any tips for hiding the password, Not really. Whereever you put it, the web server account has be able to access it, so the problem stays. Even if you could arrange that only the web server account can read it (e.g. by changing the owner of a file containing the password), every user with permission to create CGI scripts can still write a script to read the data. > or accessing MySQL from CGI scripts is not secure at all? Well, it is as secure as the server is set up. E.g. one can set up Apache so that it executes CGIs as the user to whom the script belongs. I know this has its own problems... it was only intended as example that it is a question of the server configuration. The "best" way is always a compromise and depends on how the server is used. If the server configuration is not in your hands, I don't there is much you can do, except asking the admin which way she suggests. HTH, Benjamin. -- [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
Yup, so, I guess my setup is a little off-key. *Engage sheepish mode* Turns out the admins for my system have apache in a development group, which all my files belong to, with 751 permissions. So, yeah, other users can't read the password per se but its obviously not what I thought it was. Ah well. I figured that out right after I sent out my last email... turns out 511 didn't work (551 did, of course). Sorry! =] Nick Elliott - Original Message - From: "Mark" <[EMAIL PROTECTED]> To: "Nicholas Elliott" <[EMAIL PROTECTED]> Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 26, 2002 11:26 AM Subject: Re: Hiding the password > > - Original Message - > From: "Nicholas Elliott" <[EMAIL PROTECTED]> > To: "Mark" <[EMAIL PROTECTED]> > Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, December 26, 2002 5:09 PM > Subject: Re: Hiding the password > > > > I chmod 511, on a CGI script owned by me. My username has access to > > read the source code, and apache can run the cgi script, but other users > > on the server cannot read the source themselves (minus root, etc). > > I am getting more curious by the minute. :) > > Assuming, for the argument, your username is "me", and your web-daemon is > not running as "me", then how will your web-daemon read from the CGI to > extract the shebang line? I do not see how this can be done. > > And, like I said, if your web-daemon can read from the CGI, so can everyone > else who can "run" web-pages on your server. > > - Mark mysql, query - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
- Original Message - From: "Nicholas Elliott" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 26, 2002 5:09 PM Subject: Re: Hiding the password > I chmod 511, on a CGI script owned by me. My username has access to > read the source code, and apache can run the cgi script, but other users > on the server cannot read the source themselves (minus root, etc). I am getting more curious by the minute. :) Assuming, for the argument, your username is "me", and your web-daemon is not running as "me", then how will your web-daemon read from the CGI to extract the shebang line? I do not see how this can be done (unless you had your web-daemon running as root, but I doubt you did that.) And, like I said, if your web-daemon can read from the CGI, so can everyone else who can "run" web-pages on your server. Or, as someone just brought to my attention, did you "compile" your Perl script somehow? If so, I'd be interested to know what you used. - Mark mysql,query - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
I chmod 511, on a CGI script owned by me. My username has access to read the source code, and apache can run the cgi script, but other users on the server cannot read the source themselves (minus root, etc). The original question was, > I want to make a CGI program in Perl that queries a MySQL database, and the > problem is that I need to write the password for the database in the program > and this password can be seen by any user that has an account on that > server. > > I need to gave 755 permissions to CGI scripts because they need to be > executed by the web server account, and not by my account. Maybe I do have a strange setup on my server, but I don't need to set my permissions to 755 to allow apache to excecute a file owned by me. 711/511 will work, while preventing "any user that has an account on that server" from seeing the password. Nick Elliott - Original Message - From: "Mark" <[EMAIL PROTECTED]> To: "Nicholas Elliott" <[EMAIL PROTECTED]>; "Benjamin Pflugmann" <[EMAIL PROTECTED]>; "Brent Bailey" <[EMAIL PROTECTED]> Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 26, 2002 10:56 AM Subject: Re: Hiding the password > - Original Message - > From: "Nicholas Elliott" <[EMAIL PROTECTED]> > To: "Benjamin Pflugmann" <[EMAIL PROTECTED]>; "Brent Bailey" > <[EMAIL PROTECTED]> > Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Thursday, December 26, 2002 4:17 PM > Subject: Re: Hiding the password > > > > Does the CGI-script need to be world-readable, or just world- > > executable? All my perl CGI scripts are set up that way, so while > > anyone can run it, only I can read the source code > > > What manner of http daemon do you have running that allows "chmod 111" Perl > CGI scripts to run? At the very least, the shebang-line needs to be read > from the CGI. I tested it, and my test-CGI, according to my expectation, > gives a "Permission denied" on a chmod 111 script. And I would be more > worried if it behaved differently. > > And if you set ownership to the the Perl scripts to the "nobody" user (and > run "chmod 551", for instance), then still everyone with access to running > pages on your web-daemon, will also have read-access to your Perl CGI > scripts. > > Or am I missing something? > > - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
- Original Message - From: "Nicholas Elliott" <[EMAIL PROTECTED]> To: "Benjamin Pflugmann" <[EMAIL PROTECTED]>; "Brent Bailey" <[EMAIL PROTECTED]> Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, December 26, 2002 4:17 PM Subject: Re: Hiding the password > Does the CGI-script need to be world-readable, or just world- > executable? All my perl CGI scripts are set up that way, so while > anyone can run it, only I can read the source code What manner of http daemon do you have running that allows "chmod 111" Perl CGI scripts to run? At the very least, the shebang-line needs to be read from the CGI. I tested it, and my test-CGI, according to my expectation, gives a "Permission denied" on a chmod 111 script. And I would be more worried if it behaved differently. And if you set ownership to the the Perl scripts to the "nobody" user (and run "chmod 551", for instance), then still everyone with access to running pages on your web-daemon, will also have read-access to your Perl CGI scripts. Or am I missing something? - Mark - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
Does the CGI-script need to be world-readable, or just world-executable?
All my perl CGI scripts are set up that way, so while anyone can run it,
only I can read the source code
- Original Message -
From: "Benjamin Pflugmann" <[EMAIL PROTECTED]>
To: "Brent Bailey" <[EMAIL PROTECTED]>
Cc: "Octavian Rasnita" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, December 26, 2002 9:38 AM
Subject: Re: Hiding the password
> Hello.
>
> On Thu 2002-12-26 at 09:26:09 -0500, [EMAIL PROTECTED]
wrote:
> > i would try using php to have you page connect to the mysql database..
The code gets parsed
> > first then is loaded into the browser...so the user & pass for the
database is never seen.. i
> > would use something like:
> >
> > $db = mysql_connect("localhost", "mysql-user", "mysql-user-password");
> > mysql_select_db("whatever-database-name",$db);
>
> Huh? How does this differ from the original problem with Perl? The
> script has to be world-readable in order to allow the web server
> account to read it in[1] and therefore anyone with shell access or access
> to write CGI scripts can read it.
>
> Bye,
>
> Benjamin
>
>
> [1] in the scenary presented by the original poster.
>
>
> [...]
> > > On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote:
> > > > Hi all,
> > > >
> > > > I want to make a CGI program in Perl that queries a MySQL database,
and the
> > > > problem is that I need to write the password for the database in the
program
> > > > and this password can be seen by any user that has an account on
that
> > > > server.
> > > >
> > > > I need to gave 755 permissions to CGI scripts because they need to
be
> > > > executed by the web server account, and not by my account.
> > > >
> > > > Do you have any tips for hiding the password,
> > >
> > > Not really. Whereever you put it, the web server account has be able
> > > to access it, so the problem stays. Even if you could arrange that
> > > only the web server account can read it (e.g. by changing the owner of
> > > a file containing the password), every user with permission to create
> > > CGI scripts can still write a script to read the data.
> [...]
>
> --
> [EMAIL PROTECTED]
>
> -
> Before posting, please check:
>http://www.mysql.com/manual.php (the manual)
>http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
<[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
Hello.
On Thu 2002-12-26 at 09:26:09 -0500, [EMAIL PROTECTED] wrote:
> i would try using php to have you page connect to the mysql database.. The code gets
>parsed
> first then is loaded into the browser...so the user & pass for the database is never
>seen.. i
> would use something like:
>
> $db = mysql_connect("localhost", "mysql-user", "mysql-user-password");
> mysql_select_db("whatever-database-name",$db);
Huh? How does this differ from the original problem with Perl? The
script has to be world-readable in order to allow the web server
account to read it in[1] and therefore anyone with shell access or access
to write CGI scripts can read it.
Bye,
Benjamin
[1] in the scenary presented by the original poster.
[...]
> > On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote:
> > > Hi all,
> > >
> > > I want to make a CGI program in Perl that queries a MySQL database, and the
> > > problem is that I need to write the password for the database in the program
> > > and this password can be seen by any user that has an account on that
> > > server.
> > >
> > > I need to gave 755 permissions to CGI scripts because they need to be
> > > executed by the web server account, and not by my account.
> > >
> > > Do you have any tips for hiding the password,
> >
> > Not really. Whereever you put it, the web server account has be able
> > to access it, so the problem stays. Even if you could arrange that
> > only the web server account can read it (e.g. by changing the owner of
> > a file containing the password), every user with permission to create
> > CGI scripts can still write a script to read the data.
[...]
--
[EMAIL PROTECTED]
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
i would try using php to have you page connect to the mysql database.. The code gets
parsed
first then is loaded into the browser...so the user & pass for the database is never
seen.. i
would use something like:
$db = mysql_connect("localhost", "mysql-user", "mysql-user-password");
mysql_select_db("whatever-database-name",$db);
Brent
Benjamin Pflugmann wrote:
> Hello.
>
> On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote:
> > Hi all,
> >
> > I want to make a CGI program in Perl that queries a MySQL database, and the
> > problem is that I need to write the password for the database in the program
> > and this password can be seen by any user that has an account on that
> > server.
> >
> > I need to gave 755 permissions to CGI scripts because they need to be
> > executed by the web server account, and not by my account.
> >
> > Do you have any tips for hiding the password,
>
> Not really. Whereever you put it, the web server account has be able
> to access it, so the problem stays. Even if you could arrange that
> only the web server account can read it (e.g. by changing the owner of
> a file containing the password), every user with permission to create
> CGI scripts can still write a script to read the data.
>
> > or accessing MySQL from CGI scripts is not secure at all?
>
> Well, it is as secure as the server is set up. E.g. one can set up
> Apache so that it executes CGIs as the user to whom the script
> belongs. I know this has its own problems... it was only intended as
> example that it is a question of the server configuration.
>
> The "best" way is always a compromise and depends on how the server is
> used. If the server configuration is not in your hands, I don't there
> is much you can do, except asking the admin which way she suggests.
>
> HTH,
>
> Benjamin.
>
> --
> [EMAIL PROTECTED]
>
> -
> Before posting, please check:
>http://www.mysql.com/manual.php (the manual)
>http://lists.mysql.com/ (the list archive)
>
> To request this thread, e-mail <[EMAIL PROTECTED]>
> To unsubscribe, e-mail
><[EMAIL PROTECTED]>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
--
Brent Bailey CCNA
High Speed Data Services
MetroCast Cablevision
603-332-8629 ext:242
[EMAIL PROTECTED]
-
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
Re: Hiding the password
Hello. On Wed 2002-12-25 at 13:15:58 +0200, [EMAIL PROTECTED] wrote: > Hi all, > > I want to make a CGI program in Perl that queries a MySQL database, and the > problem is that I need to write the password for the database in the program > and this password can be seen by any user that has an account on that > server. > > I need to gave 755 permissions to CGI scripts because they need to be > executed by the web server account, and not by my account. > > Do you have any tips for hiding the password, Not really. Whereever you put it, the web server account has be able to access it, so the problem stays. Even if you could arrange that only the web server account can read it (e.g. by changing the owner of a file containing the password), every user with permission to create CGI scripts can still write a script to read the data. > or accessing MySQL from CGI scripts is not secure at all? Well, it is as secure as the server is set up. E.g. one can set up Apache so that it executes CGIs as the user to whom the script belongs. I know this has its own problems... it was only intended as example that it is a question of the server configuration. The "best" way is always a compromise and depends on how the server is used. If the server configuration is not in your hands, I don't there is much you can do, except asking the admin which way she suggests. HTH, Benjamin. -- [EMAIL PROTECTED] - Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
