in reply to How do I encrypt an Unix password?

Here is some code you could use to take a plain text password, and encrypt it using a string. All/much of this code was taken from the first camel book: 
   # Generate a Salt
   $fullname = "Users Name";
   $now = time;
   ($pert1, $pert2) = unpack("C2", "$fullname");
   $week = $now / (60*60*24*7) + $pert1 + $pert2;
   $salt = ($week % 64) + ($now % 64);
   $salt = sprintf("%lx", $salt);

   # Use crypt to encrypt our password
   $passwd = crypt($password, $salt);

[download]
This works, however, I don't believe it to be incredibly secure. It first creates what's called a salt, and uses feeds that into the crypt function. Also, since this came from camel 1, be sure to add in the "my" statements where appropriate :-)

Hopefully, that will get you started. However, you should look into a better way then this to do it, I just happened to have this code laying around :-)
-Eric

Update: Camel 3 suggests another way to generate a salt -- simply do this: 
my $salt = join '', ('.', '/', 0..9, 'A'..'Z', 'a'..'z')[rand 64, rand
+ 64];
my $passwd = crypt($password, $salt);

[download]
I think that looks much nicer :-) That'll give you the encrypted password in a string. All you need to do then is figure out how to do the actual password update. Perhaps there is a system call for this? If not, you could always pipe it into the UNIX passwd command :-) HTH

Replies are listed 'Best First'.
Re: How do I encrypt an Unix password?
by Abigail (Deacon) on Jun 27, 2001 at 03:18 UTC
    Eh, no, you cannot pipe into the UNIX passwd command.

    See, when UNIX, and its standard toolset was developed, people still had a notition of security. At a time when "shoulder surfing" was the most dangerous way of getting your account compromised. No script kiddies with rootkits, or a big bad Internet with network sniffers around then. Not even heard of.

    The passwd commands reads its input from /dev/tty.

    The notion of allowing people to change their password using a web interface seems to absurd to consider for real. Why? For a brief moment, ignore the horrible security problems it causes. Why would you want to change your password over the web? Either you plan to log in to the system, or you don't. In the latter case, you don't need a password, let alone a new one. In the former case, well, once you are logged in, you can always run the passwd command. Hopefully, you are logged in using a secure channel.

    I'm not going to dwell on every script kiddies wet dream - sites allowing users to change passwords over the web. Just this: if you have to ask how to change a password using a (CGI) program, you shouldn't be doing it in the first place. Would you answer a 16 year old intern asking how to perform brain surgery, knowing that (s)he plans to use such information on live patients?

    -- Abigail

[reply]
      Well, consider this scenerio. At our company, we have several Linux boxes set up. They act as both email and web servers, amongst other things. No person except admin staff is allowed shell access to the Linux boxes, but everyone uses them to get email. Email is accessed via POP, which does not require them to have a shell... in fact, all users shells are set to /bin/false.

      In this case, why not offer a method to change the email password via a website, particularly is SSL is being employed? As a web email interface is used for employees on the road already, adding the ability to change the password seems to fit right in. In fact, it would seem there is no other simple method of changing the email password ATM, although perhaps LDAP could fix that.

      Now, assume that the login mechanism to the website in our case uses PAM.. and we use SSL to access the website. To me, this actually seems as if it may introduce fewer security problems then allowing somebody to log into a shell via ssh, as they don't even need a shell. Sure, you have to mind security when developing the site itself, and taint mode may help here -- but with that in mind, I don't really see why security has to be all that much worse.

      Part of the difference of these two methods is state. Obviously, having a stateful connection via the web would be nice (and in fact, there are some "true" stateful web apps that are being developed, but thats another story). However, with a good random character generator for a session key, and having the app track the IP address it gave a session key to, I see the possibility for a very secure web app. As we've already seen with sourceforge, simply using a stateful, encrypted connection (ie, ssh) will not solve the problem in all cases, as there are plenty of other factors that are still present that a cracker can take advantage of to break into a system. Even sourceforge (I think!) uses /etc/passwd for web logins -- and definitely allows you to change your shell password via the web, but it was via ssh that it was first cracked. My point isn't that ssh is less secure, but instead that each method of security has it's own problems. Properly done, I think they can both be "reasonably" secure, if anything is really secure.

      (For those not watching the news, sourceforge was broken into recently due to a cracker hacking a sourceforge admin's ISP. The admin first logged into the ISP, and then over to sourceforge. However, a trojan version of ssh was put on the ISP, so the crackers got his password that way. They then used that account to get into sourceforge, where they managed to snag more accounts and passwords, including those for apache.org. Ugh.).

      As far as passwd grabbing it's input from /dev/tty, the version packaged as 0.64 (comes with RedHat 7.1) can accept input from STDIN, as provided by the --stdin option.

      You indeed have a valid point with your brain surgery analogy. I agree, for something capable of causing problems like this, I think I should be more careful with my response, and qualify it with some of the points I made above. Thanks,
      -Eric

      Update: At 23:30 EST, I updated some text to make some of my points more clear. If you read this before then, please feel free to reread :-)
[reply]
        How about changing the shell of those accounts to /bin/passwd? Why throw away a ressource you can use?
[reply]

In Section Seekers of Perl Wisdom