LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This 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


Reply
  Search this Thread
Old 05-22-2017, 02:22 PM   #1
usao
Member
 
Registered: Dec 2011
Location: Chandler, AZ
Posts: 286

Rep: Reputation: Disabled
Hiding passwords in scripts?


I am working on a bash script which logs into a database via a command-line program.
I need to provide the administrator password to the database command line tool, and am not sure how to properly hide the value.
The command line program allows you to set the password in a shell variable to avoid putting it on the command line, or as part of a HERE document.
However, how do I get it into the shell variable without it being exposed in a filesystem?
 
Old 05-22-2017, 03:14 PM   #2
ondoho
LQ Addict
 
Registered: Dec 2013
Posts: 17,243
Blog Entries: 10

Rep: Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160Reputation: 5160
have you searched before posting?
https://duckduckgo.com/?q=linux+Hidi...rds+in+scripts
looks like you're not the first one to ask this question.
 
Old 05-22-2017, 03:16 PM   #3
usao
Member
 
Registered: Dec 2011
Location: Chandler, AZ
Posts: 286

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ondoho View Post
have you searched before posting?
https://duckduckgo.com/?q=linux+Hidi...rds+in+scripts
looks like you're not the first one to ask this question.
Yes, but these answers don't fit the bill.
All of them still require the password to be in a file in the filesystem.
 
Old 05-22-2017, 03:32 PM   #4
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
Is the script being called interactively (i.e. by a user) or in an automated way (e.g. by a cronjob).

In the first case you could set the variable containing the password even before calling the script. Or you could prompt for it using the read command.

In the second case it would be more difficult and possible answers would depend on your requirements, so maybe you could desribe those a bit more. (I am assuming your question has a security-related motivation, so please describe the attack scenario vs. legitimate use of the script).
Maybe it would solve your problem if the script was called from a cronjob running on another (more trusted) machine via ssh which could provide the password? (In that case make sure it is not showing up in ssh server logs of the target machine!)
 
Old 05-22-2017, 04:01 PM   #5
usao
Member
 
Registered: Dec 2011
Location: Chandler, AZ
Posts: 286

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by joe_2000 View Post
Is the script being called interactively (i.e. by a user) or in an automated way (e.g. by a cronjob).

In the first case you could set the variable containing the password even before calling the script. Or you could prompt for it using the read command.

In the second case it would be more difficult and possible answers would depend on your requirements, so maybe you could desribe those a bit more. (I am assuming your question has a security-related motivation, so please describe the attack scenario vs. legitimate use of the script).
Maybe it would solve your problem if the script was called from a cronjob running on another (more trusted) machine via ssh which could provide the password? (In that case make sure it is not showing up in ssh server logs of the target machine!)
The script would be called via automation (most likely cron).
The requirements are based on auditing policy which does not allow us to store any passwords in the filesystem.
We do not (currently) have any more trusted machine, as if I could reach it from the first host it's just as open to being hacked.
Getting an 'exception' to the policy is always an option, but im being asked to make sure there are no other alternatives before proceeding with an exception request.
 
Old 05-22-2017, 04:55 PM   #6
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.8.2003
Posts: 5,425

Rep: Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054Reputation: 2054
Quote:
Originally Posted by usao View Post
All of them still require the password to be in a file in the filesystem.
You should (might?) be able to set permissions on such a file so that only the user running the cron and root could see it.
 
Old 05-22-2017, 05:26 PM   #7
suicidaleggroll
LQ Guru
 
Registered: Nov 2010
Location: Colorado
Distribution: OpenSUSE, CentOS
Posts: 5,573

Rep: Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138Reputation: 2138
Quote:
Originally Posted by usao View Post
The requirements are based on auditing policy which does not allow us to store any passwords in the filesystem.
Well I'm not sure what your options are then. If you can't type it in interactively and you can't store it on the filesystem, where do you plan for the script to access the password? Whether it's plain-text in the script, or in the cron tab, or on another machine, or encrypted in a file with the password for that file located in plain-text in one of the above-mentioned locations...you're still storing the password in the filesystem, which is against policy. I think the only way around this is to get an exception to the policy. In doing so there are a few options, such as restricting permissions, putting it on a tmpfs/ramfs filesystem that gets wiped when the machine is power-cycled, etc.
 
Old 05-22-2017, 05:37 PM   #8
usao
Member
 
Registered: Dec 2011
Location: Chandler, AZ
Posts: 286

Original Poster
Rep: Reputation: Disabled
That's the rub. Ive heard of some type of key server type of thing, but don't know anything about them.
Supposedly you can checkout the password dynamically, in memory, but I don't know what they are called or anything else.
 
Old 05-22-2017, 06:28 PM   #9
hydrurga
LQ Guru
 
Registered: Nov 2008
Location: Pictland
Distribution: Linux Mint 20 MATE
Posts: 8,048
Blog Entries: 5

Rep: Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917Reputation: 2917
How about you write a program to run on your computer and do the actual database read/writes, not in shell script but in some language where you can employ binary code obfuscation and which can access the database securely using the password calculated from its own internals. The program will also check to see if any of its own code has been modified at any point. The program would have *very specific and restricted* login permissions to the database and transactions it could undertake. Naturally the source code would be nowhere near the machine in question.

A hacker with root access to your computer and reasonable skills will be able to do anything they want, effectively, but if you make it more difficult to achieve their task then they *might* think about finding a softer target.
 
Old 05-22-2017, 06:47 PM   #10
Shadow_7
Senior Member
 
Registered: Feb 2003
Distribution: debian
Posts: 4,137
Blog Entries: 1

Rep: Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873Reputation: 873
What is the logging in for? Is it something that can be done by other means? With a middle man that runs on the database server that generates results to a file, or inputs changes from a file. With more acceptable scp or sftp methods via key pairs?

From a certain point of view, ALL passwords are on the disk / filesystem. Baring the rare exception of hardware that handles that function. Even if it's in the program it's on a filesystem. You can hide it logically by joining multiple chunks from non-adjacent locations, or convert it from hex or binary strings. But it's still ON the filesystem from an overly technical point of view.
 
Old 05-23-2017, 08:05 AM   #11
usao
Member
 
Registered: Dec 2011
Location: Chandler, AZ
Posts: 286

Original Poster
Rep: Reputation: Disabled
The app server is the middle man in this case. The application needs to login to the database to get access to data.
While it's possible to store the password encrypted, the decryption process itself requires a password, so that's a catch-22.
 
Old 05-23-2017, 08:23 AM   #12
joe_2000
Senior Member
 
Registered: Jul 2012
Location: Aachen, Germany
Distribution: Void, Debian
Posts: 1,016

Rep: Reputation: 308Reputation: 308Reputation: 308Reputation: 308
I vote for the exception to the policy. Implemented in a responsible way. The thing is: The application is on the machine. Whatever you implement: there will always be a risk that someone who "hacked into the machine" will be able to intercept/reverse engineer/reproduce or otherwise compromise the authentication process.

The time you spent on this question would be better spent thinking about how to implement general hardening for the machine to prevent it from being compromised in the first place.
Oh, just to make sure it has been said: for your app server you'll want to use login credentials of a database user that only has read access if that's all your application needs.
 
1 members found this post helpful.
Old 05-23-2017, 10:26 AM   #13
Habitual
LQ Veteran
 
Registered: Jan 2011
Location: Abingdon, VA
Distribution: Catalina
Posts: 9,374
Blog Entries: 37

Rep: Reputation: Disabled
Unavoidable?

I do use export scripts in a root-owned crons.
stored in /root/ and 700
But...<wait for it>
as suggested, it is a database "user" with the least amount of privs necessary.

It is the exception and not the rule.

Just sayin'

Last edited by Habitual; 05-23-2017 at 10:27 AM.
 
Old 05-23-2017, 10:49 AM   #14
usao
Member
 
Registered: Dec 2011
Location: Chandler, AZ
Posts: 286

Original Poster
Rep: Reputation: Disabled
The "user" is the database account itself. The scripts are all of administrative nature, auditing, code release, monitoring and ETL.
Ill probably have to go with the exception, but was trying to cover my bases and see if there was some other tool/utility or methodology which could work that I wasn't aware of.
 
Old 05-23-2017, 01:05 PM   #15
BW-userx
LQ Guru
 
Registered: Sep 2013
Location: Somewhere in my head.
Distribution: Slackware (current), FreeBSD, Win10, It varies
Posts: 9,952

Rep: Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148Reputation: 2148
The ole' CRON job needs password to run scenario -
color me stupid but it seems to me if a cron job needed a password to run then it needs to be ran on the Administrate (root) side where no password is needed. Then only one that is root or has that password can fiddle with it. fingers then would be known where to point if something happens that is directly related to that script (job) running.

Last edited by BW-userx; 05-23-2017 at 01:06 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Passwords in scripts Entropy1024 Linux - Newbie 16 09-22-2016 05:32 AM
hiding passwords in bash scirpts aristosv Linux - Software 27 04-07-2016 11:38 AM
Hiding arguments in shell scripts 3saul Linux - Software 2 01-09-2006 02:44 PM
passwords in shell scripts djcham Linux - Software 4 10-04-2005 01:57 AM
Hiding Server Side Scripts TomalakBORG Linux - Enterprise 3 07-26-2005 02:47 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 02:38 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration