Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
there's always a tradeoff between convenience and security.
you can't have both.
that said, it might be possible to have some sort of basic encryption or rather obfuscation on the password, so you don't have it inside the script (or some other file) in plain text.
my distros packet manager shows a few results when searching for "password encrypt" - i suggest you do the same.
The problem is that even though ssh doesn't require an embedded password (using RSA), it only works if the RSA key is unencrypted... If they are, then you have to supply a passphrase either directly, or through the user agent tool which retains that passphrase/unencrypted keys to supply to ssh (which is still better than embedding the password in a script).
The problem with database passwords is that there is no alternative. They have to be in cleartext when supplied to the database to establish the connection (one of the problems with web services is that the unencrypted password is in the web scripts, and I have not seen any alternatives either).
I researched this very problem, and found only a few solutions. These are the only ones I adopted:
1. do my connections (At lease if they require passwords) from a well secured and locked down machine, so that no one but I have ACCESS to see anything that would give away the password. (As a system guy, this made sense but is obviously only as good as your isolation precautions).
2. Hard code the passwords into encrypted executables. (This only makes sense if you come form a programming background, I do)
And in both cases, use a secured channel for communications (VPN, ssl tunnel ala ssh, etc).
In the end, you cannot make it impossible to break password based security. Your objective is to make it so troublesome or expensive that no one will bother.
It seems stupid that OS and SYSTEM people have developed better answers, but the DATABASE people are still using 1980s solutions. (Says the guy who only USES databases, and has rarely developed DB software!)
The problem with databases is that no matter how you use them, applications are what connects. If if no human is involved (which is the majority of the case with batch processing), then the password MUST be provided in clear text.
I researched this very problem, and found only a few solutions. These are the only ones I adopted:
1. do my connections (At lease if they require passwords) from a well secured and locked down machine, so that no one but I have ACCESS to see anything that would give away the password. (As a system guy, this made sense but is obviously only as good as your isolation precautions).
2. Hard code the passwords into encrypted executables. (This only makes sense if you come form a programming background, I do)
And in both cases, use a secured channel for communications (VPN, ssl tunnel ala ssh, etc).
In the end, you cannot make it impossible to break password based security. Your objective is to make it so troublesome or expensive that no one will bother.
It seems stupid that OS and SYSTEM people have developed better answers, but the DATABASE people are still using 1980s solutions. (Says the guy who only USES databases, and has rarely developed DB software!)
Thanks for the information.
It's odd as I thought Linux was pretty much built with security in mind. I would have thought there would be some way to have a hash function or something. I guess for FTP the certs are a good solution.
Just for the record.
Linux is the kernel, and it is secure as the team and Linus T. can make it.
Your access is (mostly) controlled by applciations, generally GNU, and as secure as R. S. and that team can make them.
Databases are different teams, and they do not always communicate well with the first two.
When most people say "linux" they really mean the distribution or OS that blends the first two, and arguing about the real meaning is splitting hair (of which I have VERY few now) and a waste of time and talent.
Blaming Linux for database, shell, network, or application behavior is pointless unless you are willing to act to fix the problem.
The third, the database people, generally live off in their own little world. (Exceptions abound, natch.) Secure is nearly always second to "make it work" followed by "faster", because that is what their users demand of them!
All three groups are REALLY, REALLY smart people! None of them deserve disrespect. I would not have that job for the world and can only stand in awe.
That said, if you want a password-free way to securely access data in your database then you need to TELL them! Pick one or more of the database engines you would like to use, find those forums, and start asking about a solution to this problem. These guys LOVE a challenge! You may not like their solutions, but there WILL be solutions. That is pretty much how this all works.
If you do not ask, it may never happen.
Last edited by wpeckham; 11-14-2015 at 02:18 PM.
Reason: On being the squeeky wheel....
Just for the record.
Linux is the kernel, and it is secure as the team and Linus T. can make it.
Your access is (mostly) controlled by applciations, generally GNU, and as secure as R. S. and that team can make them.
Databases are different teams, and they do not always communicate well with the first two.
When most people say "linux" they really mean the distribution or OS that blends the first two, and arguing about the real meaning is splitting hair (of which I have VERY few now) and a waste of time and talent.
Blaming Linux for database, shell, network, or application behavior is pointless unless you are willing to act to fix the problem.
The third, the database people, generally live off in their own little world. (Exceptions abound, natch.) Secure is nearly always second to "make it work" followed by "faster", because that is what their users demand of them!
All three groups are REALLY, REALLY smart people! None of them deserve disrespect. I would not have that job for the world and can only stand in awe.
That said, if you want a password-free way to securely access data in your database then you need to TELL them! Pick one or more of the database engines you would like to use, find those forums, and start asking about a solution to this problem. These guys LOVE a challenge! You may not like their solutions, but there WILL be solutions. That is pretty much how this all works.
If you do not ask, it may never happen.
Oh, it has been asked.
The problem is that no matter what you use... a password in cleartext (or its equivalent) always shows up. Use a dongle? still unencrypted password... no intelligence in the dongle, it will supply a key as long as it is asked appropriately. Want that request encrypted? then you have to have an unencrypted key entry to set the link up... and that becomes your unencrypted password.
Even with SSH - the authentication keys have to be unencrypted to be used...
All that happens is that the password is in a different location.
The closest I've seen has been Kerberos. A time limited credential.
Unfortunately, that has exactly the same weaknesses as a password - other than the requirement to periodically renew the credential.
If the credential can be captured, the database is vulnerable until the credential is revoked or times out. On the plus side, the timeout period can be short. Though the shorter it is the more often the credential has to be renewed.
It also doesn't work well with things like web servers due to the need to renew the credential (which tends to make people create longer term credentials...)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.