Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Perl Misc (http://www.velocityreviews.com/forums/f67-perl-misc.html)
-   -   Re: CGI Question (http://www.velocityreviews.com/forums/t956014-re-cgi-question.html)

Scott Bryce 12-31-2012 09:34 PM

Re: CGI Question
 
This is a little OT here, but since you haven't had a good answer to
your question....


On 12/29/2012 9:55 AM, E.D.G. wrote:
> What permissions should the password and Perl language files have?


Perl script: 755. Password file: I believe 666 will work.

But more important than that...

> Also in that directory will be the password file that will have a
> .txt extension.


Don't do that. Move the password file to a directory above the document
root where it cannot be accessed via the internet. (The passwords are
encrypted, aren't they?)



Rainer Weikusat 01-01-2013 04:21 PM

Re: CGI Question
 
Scott Bryce <sbryce@scottbryce.com> writes:
> This is a little OT here, but since you haven't had a good answer to
> your question....
>
>
> On 12/29/2012 9:55 AM, E.D.G. wrote:
>> What permissions should the password and Perl language files have?

>
> Perl script: 755. Password file: I believe 666 will work.


Unfortunately, this doesn't qualify as 'a good answer' since both
reading from and writing to the password file is allowed for everyone
....

[...]

>> Also in that directory will be the password file that will have a
>> .txt extension.

>
> Don't do that. Move the password file to a directory above the document
> root where it cannot be accessed via the internet. (The passwords are
> encrypted, aren't they?)


.... and encrypting them doesn't help. That's a design mistake dating
back to the original UNIX(*) authentication system: Someone who has
access to a file containing the encrypted passwords can grab it and
run an offline dictionary/ brute force attack against it using
whatever computing resources are available to him.

If the web server doesn't need to write to the password file, it
showned be owned by root, the group should be set to some group the
web server user is member of and the permissions should be 0640[*] (read
and write access for the owner, read access for he group, no access
for anyone else). If the code is supposed to update the password file,
the permissions should be 0660 (same as before, except that group
write access is also enabled). The reason for 'owned by root' is that
this restricts the web server to modifying the contents of the file
but not the associated meta-information (such as the permissions).
[*] Short and incomplete explanation of the numbers: 1 - execute
permission, 2 - write permission, 4 - read permission. Rightmost digit
- permissions for 'world', middle digit - group permissions, leftmost
digit - owner permissions (the leading 0 marks this as an octal [base
8] number).

Scott Bryce 01-01-2013 04:40 PM

Re: CGI Question
 
On 1/1/2013 9:21 AM, Rainer Weikusat wrote:
> Scott Bryce <sbryce@scottbryce.com> writes:
>> This is a little OT here, but since you haven't had a good answer
>> to your question....
>>
>>
>> On 12/29/2012 9:55 AM, E.D.G. wrote:
>>> What permissions should the password and Perl language files
>>> have?

>>
>> Perl script: 755. Password file: I believe 666 will work.

>
> Unfortunately, this doesn't qualify as 'a good answer' since both
> reading from and writing to the password file is allowed for
> everyone



Thank you for the correction.


Scott Bryce 01-01-2013 04:42 PM

Re: CGI Question
 
On 1/1/2013 9:37 AM, E.D.G. wrote:
> It is still somewhat surprising to me that the technical people
> associated with my Internet Server did not have that information
> readily available.


It is not their job to write your code for you.


Peter J. Holzer 01-01-2013 08:31 PM

Re: CGI Question
 
On 2013-01-01 16:21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
> Scott Bryce <sbryce@scottbryce.com> writes:
>>> Also in that directory will be the password file that will have a
>>> .txt extension.

>>
>> Don't do that. Move the password file to a directory above the document
>> root where it cannot be accessed via the internet. (The passwords are
>> encrypted, aren't they?)

>
> ... and encrypting them doesn't help.


It actually helps rather a lot.

> That's a design mistake dating back to the original UNIX(*)
> authentication system: Someone who has access to a file containing the
> encrypted passwords can grab it and run an offline dictionary/ brute
> force attack against it using whatever computing resources are
> available to him.


And without "encryption" (nitpick: Passwords are usually hashed, not
encrypted) "someone who has access to a file containing the
cleartext passwords" has immediate access to the passwords without
having to run any further attacks. With a properly salted hash function
of sufficient length a brute force attack is infeasible and good
passwords should resist any dictionary attack.


> If the web server doesn't need to write to the password file, it
> showned be owned by root, the group should be set to some group the
> web server user is member of and the permissions should be 0640[*] (read
> and write access for the owner, read access for he group, no access
> for anyone else).


I would change "should be chowned by root" to "should be chowned to the
uid which is supposed to change the passwords". There is little reason
why this should be root.

Making the file readable by the web server of course means that the
web server and hence any attacker exploiting a flaw in the web server
can read the password file, which implies that storing cleartext passwords
there is not such a bright idea.

(If you are really serious about protecting your passwords, don't give
them to the webserver, but provide another service which the webserver
can use to check one logname/password combination at a time. If you are
really really serious, use something other than passwords: Public keys,
one time passwords, ...)

hp

--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

Rainer Weikusat 01-01-2013 09:24 PM

Re: CGI Question
 
"Peter J. Holzer" <hjp-usenet2@hjp.at> writes:
> On 2013-01-01 16:21, Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>> Scott Bryce <sbryce@scottbryce.com> writes:
>>>> Also in that directory will be the password file that will have a
>>>> .txt extension.
>>>
>>> Don't do that. Move the password file to a directory above the document
>>> root where it cannot be accessed via the internet. (The passwords are
>>> encrypted, aren't they?)

>>
>> ... and encrypting them doesn't help.

>
> It actually helps rather a lot.


As 'piece of mind' feature possibly (it also avoids the need to
repeatedly explain this).

Paraphrasing from Wikipedia:

,----
| In 1987 the author of the original Shadow Password Suite, Julie Haugh,
| experienced a computer break-in and wrote the initial release of the
| Shadow Suite containing the login, passwd and su commands. The
| original release, written for the SCO Xenix operating system, quickly
| got ported to other platforms.
|
| [...]
|
| Password shadowing first appeared in UNIX systems with the development
| of System V Release 3.2 in 1988 and BSD4.3 Reno in 1990.
`----

http://en.wikipedia.org/wiki/Shadow_%28file%29

NB: I already wrote a much longer reply, but I have no interested in
discussing anything with the author of the previous posting.

Scott Bryce 01-02-2013 06:55 AM

Re: CGI Question
 
On 1/1/2013 9:05 PM, E.D.G. wrote:
> "Scott Bryce" <sbryce@scottbryce.com> wrote in message
> news:kbv3lc$p41$2@dont-email.me...
>
>> It is not their job to write your code for you.

>
> The problem was that they could not explain how the file permissions
> need to be set for any CGI program or password file.


Right. Because these are not server configuration issues.

> In any case, it looks like the matter will have been possible to
> resolve through these Newsgroup discussions.


Or not. The questions you are asking are not really Perl questions.
Perhaps they should be asked in a more appropriate newsgroup.


Dave Saville 01-02-2013 10:12 AM

Re: CGI Question
 
On Wed, 2 Jan 2013 07:55:34 UTC, "E.D.G." <edgrsprj@ix.netcom.com>
wrote:

> "Scott Bryce" <sbryce@scottbryce.com> wrote in message
> news:kbt0dl$pq3$1@dont-email.me...
>
> > Don't do that. Move the password file to a directory above the document
> > root where it cannot be accessed via the internet.

>
> Question: If the directory where the Perl program is www/cgi-bin and the
> password.txt file is stored in a directory that is above that one, say it is
> named "passwords", what address would the Perl program use to open the
> password.txt file?
>
> open file, '< ???/passwords.txt';
>
> What would the ???/ be, root/ or something like that?
>
> or
>
> usr/local/password/
>
> I tried a few names like that and couldn't get any of them to work.
>


Ye gods! - Been following this thread with growing disbelief. Go and
learn about the unix file system, its permissions and structure.

Assuming:

www
cgi-bin
passwords

And you are in cgi-bin then ../passwords/passwords.txt

--
Regards
Dave Saville

Dave Saville 01-02-2013 10:47 AM

Re: CGI Question
 
On Wed, 2 Jan 2013 10:37:05 UTC, "E.D.G." <edgrsprj@ix.netcom.com>
wrote:

> "Dave Saville" <dave@invalid.invalid> wrote in message
> news:fV45K0OBJxbE-pn2-o3ok84FQdYDY@localhost...
>
> > And you are in cgi-bin then ../passwords/passwords.txt

>
> That was one of the first things that I tried. It works on my PC with Xampp
> but not on my Internet Server. However, I might have just not gotten the
> address in there correctly and will try it again.
>


Is it possible that the server is stopping you essentially "CDing out
of your assigned file system"? You do own www and have write
permissions?
--
Regards
Dave Saville

Scott Bryce 01-02-2013 03:40 PM

Re: CGI Question
 
On 1/2/2013 8:25 AM, E.D.G. wrote:
> There shouldn't be any problems with www ownership.


OK, but the password file should be in a directory outside of the www
directory, not below it.



All times are GMT. The time now is 04:44 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.