$PASSWD was available to everyone on the box anyway. You stick it in memory, it's readable. That's the way life works. You probably stuck it in a database too, right? Did you lock down the socket from local users? Probably not. Did you store the database password off-line? Probably not, because you wanted unattended startup to work.
The bottom line is that if you want to do password storage in your web app that is secure against local users, you have vastly more work to do than just finding a CPAN library somewhere.
Just because security by obscurity is not a barrier you should lean on doesn't mean that it lacks value in combination with other measures.
Script kiddies will struggle to isolate data from memory in order to get passwords, particularly if they can't get binaries on the machine and it has no compiler. On the other hand, they will have no trouble using a copy and paste ps usage.
And when I say script kiddies, I also mean the sort of 9-5 culture, corner-cutting production support teams that exist in some organisations and who might have accounts on shared hardware that your application runs on. Do you really want to make it easy for them to do favours for people on the business side who want passwords they shouldn't have?
> The bottom line is that if you want to do password
> storage in your web app that is secure against local
> users, you have vastly more work to do than just finding
> a CPAN library somewhere.
> Just because security by obscurity is not a barrier you should lean on doesn't mean that it lacks value in combination with other measures.
Damn straight. Check out the DNS spoofing defences - using random ports to issue requests on. There's a known limit to port numbers, and you could probably circumvent it with massive amounts of traffic, but using an unknown port number makes it hard enough that performing that kind of attack is significantly more difficult.
I think you mean you agree with me, no? Unless you're really arguing that simply using a CPAN library renders your application secure to all attackers? I think you're arguing against the converse of what I stated, not my actual point.
OK, just curious: how is the posting of judgemental one-liners unrelated to the subject at hand somehow less of an etiquette violation than a perfectly harmless (yet responsive and topical) rhetorical snipe? I mean, as flames go this was pretty mild sauce. Can't you spend your time policing some of the legitimate flame wars that pop up here instead?
Say UID 100 is running PID 200 which has "my password" in memory. How does UID 300 read the memory of PID 200?
If it requires a security flaw, I don't think it's fair to compare to the ease of using 'ps' ... if it doesn't, please explain so I can learn something today. :)
On a linux box, read /proc/200/mem. Or just allocate a bunch of memory and force it to swap out, then read the swapfile. Season liberally with local root exploits if needed (these come in bucketfuls on most unices). This is a classic attack: while it's not terribly practical, it's a whole lot easier than trying to brute force the password stream.
I'm not saying local-attacker password security can't be locked down securely. Simply that doing so is a much more complicated proposition than "use a library". In practice, most web applications are not secured against hostile local users. I'm not sure I've ever seen one that was. So to my mind, ruling out some of the most powerful tools you have (perl's IPC facilities) in a vain attempt to achieve a security level that the rest of your architecture doesn't support seemed silly.
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that?
I'm not sure where all these security discussions are going. My point was simply that taking the passwords out of the command line of gpg was woefully insufficient to secure them (note, again, that they're going to be stored in a database whose password is stored locally in a file), so using "security" as a reason to avoid perl's elaborate and very robust IPC facilities was a poorly grounded argument. Nitpicking about whether one (!) of my examples matches the original author's security assumptions is very much missing the point.
To get back to perl: note that you can feed the password to GPG via stdin if you want with just one extra byte to the open string, and a call to autoflush() and print().
Is your security analysis assuming that the attacker is running under a different uid than the web server?
Well, that's just what my example question above said.
Why on earth would you do that?
To avoid them reading the memory? It's pretty common for shared hosting to have each user running on their own local port and a reverse proxy listening on 80, just so that each user gets the benefit of the basic UNIX security model (we assume trust in the admin, of course). I guess I don't understand the whole password in a file thing, either. If those have proper permissions then the only person who have to trust other than yourself is root. Seems better than nothing to me.
Is your security analysis assuming that the attacker is running under a different uid than the web server? Why on earth would you do that?
In a secure shared hosting environment applications do not run as the web server UID. They run as the owner of the virtual host. Apache does this with mod_suexec.
Are you doing it differently? Why on earth would you do that?
The unix security model isn't amazing, but it does a reasonable job of protecting you from users other than root -- putting cleartext passwords in command line arguments is one way of throwing that away.
Then again, as you seem to be saying, manipulating cleartext passwords are usually a bad idea in the first place
It was a "trap" because the data is still available in memory either way? Are you serious? Oh, and if anybody has any clever retorts to this comment, I'm actually laying traps right now expecting you to say just that. Be warned
$PASSWD was available to everyone on the box anyway. You stick it in memory, it's readable. That's the way life works. You probably stuck it in a database too, right? Did you lock down the socket from local users? Probably not. Did you store the database password off-line? Probably not, because you wanted unattended startup to work.
The bottom line is that if you want to do password storage in your web app that is secure against local users, you have vastly more work to do than just finding a CPAN library somewhere.