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 :-)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.