|
jerrygarciuh has asked for the wisdom of the Perl Monks concerning the following question:
Esteemed Monks, In recent posts and CB discussions I have been advised to keep password data at site root outside of the document tree of my sites and not crypted in mySQL tables. I am curious as to why this conviction is so strong. As far as I understand the processes involved, both FTP access to site root and access to data in tables in mySQL require that a un/pw pair be supplied. mySQL will additionally require that the un/pw be applied to a specific db on the server. This database's name is not necessarily obvious. On the other hand, the name of most site's FTP server is perfectly obvious, therefore that's one less piece of info to discover to get access. Can someone explain the flaw in my thinking please? TIA jg _____________________________________________________Think a race on a horse on a ball with a fish! TG |
Re: OT ~ Security: Why is Root More Secure Than mySQL?
by Zaxo (Archbishop) on Sep 06, 2002 at 16:56 UTC
|
Big subject, I don't know all the answers, but I'll comment.
Security is always a compromise with usability. Nobody can memorise a new, long, and random password at short intervals. People will need to either
- write it down - a security breach
- communicate en clair with the authority to recover forgotten passwords - another hole
- or else suffer loss of the protected data - a defining characteristic of 'insecure'.
Any name/pass pair that is transmitted without encryption over a network can be read by any sniffers on the route. That is the weakness of telnet and FTP for managing remote accounts. The answer is to always use an SSL enabled protocol for remote connections. Administer your site via ssh and scp, and authenticate web users over https.
MySQL has varying security characteristics depending on how it's set up. It may or may not accept connections from a network. Many hosting companys only provide one password per account, forcing you to read public data over a connection with admin permissions on your database. For performance, the db server is often placed on a different machine than the web server, making connections from some subnet necessary. A compromised machine on that subnet becomes a threat to the db.
Localhost security of your home directory, outside your web root, depends entirely on secrecy of your login password. Your username is readily available to anyone with access to that machine. Use filesystem permissions to protect sensitive data there. It is occasionally necessary for cgi to write to files. Avoid that for anything sensitive if you do not have suEXEC available. If cgi runs as an unprivileged user, the directory containing the files must be publicly writable and readable.
The mysql manual has a section on security, mostly from the dbma point of view. It will tell you what to look for in a MySQL server.
Do not rely on secrecy of identities. Usernames, db names, directory names all can be discovered, and should be regarded as public.
I haven't given any easy answers. You need to examine your site and all its operations. Decide what is sensitive. Protect it with the proper tools.
Counterpane: Crypto-Gram is a good source for healthy pessimism on network security.
After Compline,
Zaxo
| [reply] |
|
|
Thank you for your detailed response Zaxo!! I do all my admin of mySQL via SSH but I guess I really should ditch my FTP entirely in favor of SSH for transfers. I am insufficiently paranoid I think. However I keep getting an error from SSH when starting a transfer session like: File Transfer Server Could Not Be Started Or It Exited Unexpectedly. Exit Value 0 was Returned.
But I digress, Thanks for the information and advice!!
jg
_____________________________________________________
Think a race on a horse on a ball with a fish! TG
| [reply]
[d/l] |
Re: OT ~ Security: Why is Root More Secure Than mySQL?
by gryphon (Abbot) on Sep 06, 2002 at 16:16 UTC
|
Greetings jerrygarciuh,
From my point of view, it seems like you have two options: 1. Keep crypted passwords in the database, probably as a column in a user table. 2. Keep crypted passwords in a file outside the Web site directory. (IMHO, at no point should passwords be kept in clear text. Even if someone gets to the file, you should make them work for the passwords.)
With either option, I can get to the crypted password information (eventually) if I can read your scripts' code. So first thing is to protect your scripts from me. Check out Ovid's CGI Course for some great wisdom on this. One trick I've used recently is to invoke CGI::Application. Aside from the super-cool auto-use of CGI and HTML::Template, it also lets me build really stripped down CGI scripts with the bulk of the processing code in "application module" files housed outside the Web server document root. If a cracker was able to get the code to my script via http, he wouldn't be able to read off the location of any data files or the location/username/passwords to any database.
Now to the specific difference between option 1 and 2. With a database, you can't really hide a table (as far as I know with my limited knowledge). A file, however, could be hidden a few different ways. You could use the file system to lock the file in specific ways, or you create a symbolic link to the file.
Personally, if it was just me, I'd go with the database approach because it's simpler. I have my database allowing only local connections with authentication. So I feel fairly safe. However, I'm very not a security guru. Other will certainly have better/more informed ideas.
gryphon
code('Perl') || die;
| [reply] |
|
|
Excellent point! If some used the null-byte hack or some other means to get the script source, they'd have all the mySQL info at their finger tips! However, the FTP un/pw is only in my head and hence more secure.
Thanks for clearing that up for me!
jg
_____________________________________________________
Think a race on a horse on a ball with a fish! TG
| [reply]
[d/l] |
Re: OT ~ Security: Why is Root More Secure Than mySQL?
by reyjrar (Hermit) on Sep 06, 2002 at 17:03 UTC
|
Actually, it depends. The data is only as secure as its container. In the case of the flat file, your container would be the directory structure, privileges around it, and ultimately the security of the host server. If someone was able to compromise the server and get root access, they would be able to circumvent any file restrictions or database permissions you have setup anyways. Also, I do know there have, at least in the past, been several severe security issues with mySQL that allowed a remote user to execute code on the server as the user mysql was running as. Unknowingly, most people have mysqld's running as root and have experienced some kind of false sense of security thanks to the 'safe_mysqld' command name.
My setup has mysqld runnign chroot jailed in /usr/local/mysql as the user mysql. mysql is the owner of /usr/local/mysql/data and is the only one (besides root) with read access to the database. Its also not necessary for my database to be accessible from anything but the box its running on. As a result I have configured mysql to run on 127.0.0.1:3306 rather than the default 0.0.0.0:3306. I also have taken into account the security of the server. I run only the processes I need to be running, have recompiled a kernel with security as a main concern, and monitor network traffic, the file system, and kernel calls.
Of course, even with all those precautions, someone can still circumvent them, but they'd need a good reason. Whether you store it in a database or a flat file, the password will ultimately get stored in a flat file that anyone with root access can read. If its necessary to store the password somewhere, you need to make an assessment of the amount of security you need. Needless to say, you should never store a root or privileged user password in a flat file or a database! Local user account passwords should be guarded pretty strictly as well. Application user passwords need to be stored somewhere and should be stored encrypted where-ever you decide to store them. Make sure you use taint checking, warnings, strict, and limit the number of system() calls in your code. Also, take some time to account for "the dumbest user in the world" and do some basic checking of ANY variables some other than you has a chance to modify. Oh yeah, and %ENV=(); doesn't hurt either.
-brad..
| [reply]
[d/l] |
Re: OT ~ Security: Why is a file outside the web root more secure than mySQL?
by fokat (Deacon) on Sep 06, 2002 at 23:15 UTC
|
What my fellow monks have said so far is very instructive. You must pay attention to their views.
I will add that no matter how you choose to store your passwords, you should avoid using reversible crypto. That is, you should use schemes that make the recovery of the original password, either impossible or very hard. This is the approach followed by the designers of Unix, long ago. They use a supposedly cryptographically strong hash function and a salt to protect the password.
Thanks to this approach, even knowing the algorythms used to protect the passwords and having access to the password database itself, obtaining the original passwords in clear-text (ie, for use in actual authentication) becomes a non-trivial problem involving brute-force and possibly massive amounts of processing power.
If you use reversible crypto, a cracker with knowledge about the algorythm used to secure the passwords and with access to the password database, can easily break into your system/application.
Take a look at Crypt::PasswdMD5, which allows you to protect passwords of any length, using the MD5 algorythm to hash them, making the recovery with methods other than brute force, infeasible.
Hope this helps. | [reply] |
Re: OT ~ Security: Why is Root More Secure Than mySQL?
by Anonymous Monk on Sep 06, 2002 at 19:38 UTC
|
There is a simple answer.
If your code is OK, then someone won't get access to either without breaking into somewhere that they shouldn't be. If the person has remote access to the database, they might not get anywhere else from there. If they have remote access to your webserver, then odds are high that they will shortly apply a rootkit, read your code and get at your database, etc.
So access to site root gives database access but not vice versa. Hence site root is more secure. (You have secured it, right?) | [reply] |
|
|
| [reply] |
|
|
