Re: CGI Question

Discussion in 'Perl Misc' started by Scott Bryce, Dec 31, 2012.

  1. Scott Bryce

    Scott Bryce Guest

    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?)
    Scott Bryce, Dec 31, 2012
    #1
    1. Advertising

  2. Scott Bryce <> 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).
    Rainer Weikusat, Jan 1, 2013
    #2
    1. Advertising

  3. Scott Bryce

    Scott Bryce Guest

    On 1/1/2013 9:21 AM, Rainer Weikusat wrote:
    > Scott Bryce <> 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, Jan 1, 2013
    #3
  4. Scott Bryce

    Scott Bryce Guest

    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.
    Scott Bryce, Jan 1, 2013
    #4
  5. On 2013-01-01 16:21, Rainer Weikusat <> wrote:
    > Scott Bryce <> 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
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Jan 1, 2013
    #5
  6. "Peter J. Holzer" <> writes:
    > On 2013-01-01 16:21, Rainer Weikusat <> wrote:
    >> Scott Bryce <> 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_(file)

    NB: I already wrote a much longer reply, but I have no interested in
    discussing anything with the author of the previous posting.
    Rainer Weikusat, Jan 1, 2013
    #6
  7. Scott Bryce

    Scott Bryce Guest

    On 1/1/2013 9:05 PM, E.D.G. wrote:
    > "Scott Bryce" <> wrote in message
    > news:kbv3lc$p41$...
    >
    >> 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.
    Scott Bryce, Jan 2, 2013
    #7
  8. Scott Bryce

    Dave Saville Guest

    On Wed, 2 Jan 2013 07:55:34 UTC, "E.D.G." <>
    wrote:

    > "Scott Bryce" <> wrote in message
    > news:kbt0dl$pq3$...
    >
    > > 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, Jan 2, 2013
    #8
  9. Scott Bryce

    Dave Saville Guest

    On Wed, 2 Jan 2013 10:37:05 UTC, "E.D.G." <>
    wrote:

    > "Dave Saville" <> 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
    Dave Saville, Jan 2, 2013
    #9
  10. Scott Bryce

    Scott Bryce Guest

    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.
    Scott Bryce, Jan 2, 2013
    #10
  11. >>>>> "HL" == Henry Law <> writes:

    HL> Quite so. My theory is that E.D.G. (don't you love those dots)
    HL> is actually a highly sophisticated Turing-test bot.

    You say Turing; I say Dunning-Kruger. I believe Mr Occam votes with me.

    Charlton



    --
    Charlton Wilbur
    Charlton Wilbur, Jan 2, 2013
    #11
  12. Scott Bryce <> writes:
    > 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.


    I'd like to second that strongly: Unless the server was specifically
    configured to prohibit this, having the password file in the WWW tree
    very likely means anybody who knows the name of this file get download
    it by using a suitable URL, eg, https://your.server.org/passwords.txt.
    (and if the OP isn't using HTTPS, he would be very good advised to
    start doing so immediately --- nowadays, people access 'the internet'
    from their laptops/ smartphones etc while using 'open' WiFi hotspots
    in public locations and other people can and do exploit this to
    collect authentication information sent in clear).
    Rainer Weikusat, Jan 2, 2013
    #12
  13. On 2013-01-01 21:24, Rainer Weikusat <> wrote:
    > "Peter J. Holzer" <> writes:
    >> On 2013-01-01 16:21, Rainer Weikusat <> wrote:
    >>> Scott Bryce <> 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


    Neither "piece of mind" nor "peace of mind". It is a useful 2nd line of
    defense after the attacker has gotten hold of the password file. Of
    course it only helps those with reasonably complex passwords. "Rainer1"
    won't delay an attacker for long.

    > Paraphrasing from Wikipedia:
    >
    > ,----
    >| Password shadowing first appeared in UNIX systems with the development
    >| of System V Release 3.2 in 1988 and BSD4.3 Reno in 1990.
    > `----


    Old news. Not sure why you think you have to bring that up. Scott
    already advised to make the password file non-public and I suggested (in
    the part you snipped) a way to make the password file completely
    unaccessable by the web server. But I still think passwords should not
    be stored as plain text.

    hp


    --
    _ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
    |_|_) | Sysadmin WSR | Man feilt solange an seinen Text um, bis
    | | | | die Satzbestandteile des Satzes nicht mehr
    __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
    Peter J. Holzer, Jan 2, 2013
    #13
  14. "E.D.G." <> writes:
    > "Rainer Weikusat" <> wrote in message
    >> (and if the OP isn't using HTTPS, he would be very good advised to
    >> start doing so immediately --- nowadays, people access 'the internet'

    >
    > Thanks for the suggestion. As I stated in another post, there might
    > be only a half dozen researchers posting notes to the board. So, I
    > don't think that their losing track of their passwords will be a
    > problem.


    The problem is that _other people_ might be able to intercept the
    traffic and thus, gain access to the passwords. This used to be
    more-or-less a non-issue since shared-medium ethernets went out of
    use, however, nowadays, it is again an issue because of a new kind of
    'shared-medium ethernet' commonly known as WiFi. Especially since
    so-called 'open wireless hotspots' provided as a convenience to
    customers in public locations are not uncommon.
    Rainer Weikusat, Jan 3, 2013
    #14
  15. >>>>> "EDG" == E D G <> writes:

    EDG> As I stated in another post, there might be only a half dozen
    EDG> researchers posting notes to the board.

    As I have pointed out repeatedly: it's not the half dozen people who are
    authorized to use this software who are using it legitimately that you
    have to worry about. It's the several hundred thousand hackers,
    crackers, script kiddies, and wannabe mafiosi who are going to find and
    exploit the flaws in your code to make your computer do things you don't
    want it to do.

    There is a legitimate possibility that within 24 hours of you turning on
    this service, that your computer will be compromised and used as a
    kiddie porn distribution node.

    If you weren't aware that that could happen, let alone knowing how to
    prevent it or discover that it's going on and shut it down, you have no
    business telling us what you think will or will not be a problem.

    Charltobn


    --
    Charlton Wilbur
    Charlton Wilbur, Jan 3, 2013
    #15
  16. "E.D.G." <> writes:
    > "Charlton Wilbur" <> wrote in message
    > news:...
    >
    >> As I have pointed out repeatedly: it's not the half dozen people who are
    >> authorized to use this software who are using it legitimately that you
    >> have to worry about. It's the several hundred thousand hackers,

    >
    > With humor intended, one thing that helps here is that most of
    > my Web site work is highly technical and extremely boring.


    .... and the computer it runs on is 'highly technical and very
    useful'. Especially if someone else pays the bills and has to deal
    with the fallout.
    Rainer Weikusat, Jan 6, 2013
    #16
  17. >>>>> "EDG" == E D G <> writes:

    >> As I have pointed out repeatedly: it's not the half dozen people
    >> who are authorized to use this software who are using it
    >> legitimately that you have to worry about. It's the several
    >> hundred thousand hackers,


    EDG> With humor intended, one thing that helps here is that most of
    EDG> my Web site work is highly technical and extremely boring.

    Yes, well, most of your websites are full-on crackpottery; but the
    content is completely irrelevant. The people most likely to exploit
    your blisteringly obvious incompetence are not there for the content,
    but for the flaws in your security.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, Jan 6, 2013
    #17
  18. Scott Bryce

    Keith Keller Guest

    On 2013-01-05, E.D.G. <> wrote:
    >
    > With humor intended, one thing that helps here is that most of my Web
    > site work is highly technical and extremely boring.


    I think you should point your scientific collaborators to this thread,
    so they can see what other Perl programmers think of your ability to
    host their data safely.

    --keith

    --
    -francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://www.therockgarden.ca/aolsfaq.txt
    see X- headers for PGP signature information
    Keith Keller, Jan 6, 2013
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jürgen Exner

    Re: CGI Perl "use CGI" statement fail

    Jürgen Exner, Jul 31, 2003, in forum: Perl
    Replies:
    0
    Views:
    1,220
    Jürgen Exner
    Jul 31, 2003
  2. Shailan
    Replies:
    2
    Views:
    864
    Shailan
    Dec 15, 2003
  3. John Smith
    Replies:
    0
    Views:
    2,990
    John Smith
    May 15, 2006
  4. LarsenMTL
    Replies:
    4
    Views:
    649
    Eric Walstad
    Nov 4, 2004
  5. Ted Byers
    Replies:
    19
    Views:
    629
    Ilya Zakharevich
    Nov 30, 2009
Loading...

Share This Page