Note that crypt and getpw* won't
work because some systems store passwords in
/etc/shadow, and/or use MD5 to
encrypt them (and the crypt
function doesn't behave accordingly). Sometimes passwords might be
managed off machine.
You'll find the Authen::PAM module helpful if
your system supports PAM (Pluggable Authentication
Modules). Otherwise, Crypt::PasswdMD5
might be useful, as well as looking up the documentation
for what fields are in /etc/shadow.
If your system uses shadow passwords it is likely that
your script will need to have root access.
Regardless, you have a serious security issue if
people can try to brute-force passwords on your
system through your script.
| [reply]
[d/l]
[select] |
Update: On rereading, I've decided that mine isn't a very useful reply. /:
Actually, even on many systems with shadowed passwords, either the C library's getpw*() or Perl's wrapper will grab the shadow encrypted password when the routine is called by a process with effective user ID of 0 (root).
-
tye
(but my friends call me "Tye")
| [reply] |
When I submitted a patch for Apache's auth module to make it work
with /etc/passwd, they politely declined it. Apparently, they
had received dozens of submissions like this, but were against
it in principle. Using "system" passwords for Web-based
management is a capital-B Bad Idea, for security reasons, and
many others.
Now, this was some time ago, back when /etc/passwd actually
had "passwords" in it. Most systems now use /etc/shadow
to store the encrypted passwords, which means that the
CGI user cannot actually read this information. Otherwise,
you would have to run your CGI as root, which is an
Exceptionally Bad Idea.
As wog was kind enough to mention, PAM might give you the
access you require, and I would certainly look into using
this.
Remember, though, that disclosing your system password is
highly dangerous. If, for some reason, a user's password
were captured, and this user happened to have "sudo" access
(a utility to run root-level commands and/or a root shell),
then you are exposing yourself to a world of hurt. All it
would take is one of your admins to log in to your Web page
from a cable modem connection which happened to have a
"sniffer" on it, and your system would be, as
they say, chown'd. As in, no longer yours.
Perhaps if you could describe the nature of your application,
some ways of addressing this particular requirement could be
investigated. | [reply] |
It's generally considered a Bad Idea to do this. You'll have Unix passwords flying over the wire in the clear, making them easy to sniff. Of course, if you allow telnet or unencrypted FTP to the box, there's probably
no greater threat anyway, but if you have telnet turned off and ssh turned on
for security purposes (like most people do these days), then you've just reintroduced
a hole.
-- Randal L. Schwartz, Perl hacker | [reply] |
Assuming your machine is using crypt: yes, it's easy though on most systems you'd need /etc/shadow, which usually is readable only by root.
Anyway, the code:
#!/usr/bin/perl -w
use strict;
my $crypted_passwd = 'SqL9sEYFbjX0U';
my $clear_passwd = 'blah';
my $seed = substr( $crypted_passwd, 0, 2 );
print "It's correct\n" if crypt( $clear_passwd, $seed ) eq $crypted_pa
+sswd;
Update: Oops, misunderstood your question. Seems like serious caffeine shortage.
The proper answer would probably be: use Authen::PAM ;-)
-mk | [reply]
[d/l] |
If you are using Apache then the htCheckPassword command in the htpasswd module at CPAN enables you to check whether an Apache password is correct. In general, however, the Apache password and the Unix password will not be the same.
It is possible to configure Apache so that it uses Unix Ids and passwords for authentication, but most experts strongly recommend against doing so.
So the answer is yes, it is at least possible.
# Check that a password is correct
$pwdFile->htCheckPassword("zog", "password");
| [reply] |
"Writing Apache Modules with Perl and C" covers this.
Authored by Lincoln Stein and Doug Maceachern.
| [reply] |