Home » RDBMS Server » Security » how to hide password in script (unix / oracle )
( ) 1 Vote
| how to hide password in script [message #493198] |
Sun, 06 February 2011 11:59  |
 |
crocuta
Messages: 8
Registered: November 2010
Location: muenchen
|
Junior Member |
|
|
I have following problem I have simple script in bash where I connect to db and launch simle select.
username:$(value)@host...
Problem is that i want to hide the password or encrypt.
currently as you can see Iam using variable (value) where the passwod is keeped.
the problem is that, mentioned script is launched by many people which are using the same user (monitor).
the variable is read from a file where user (monitor ) has acces its in the same directory.
is there any way how to solve it ?
for e.g.
1. to put the file with password in another folder where the user (monitor) has no acces to see the file.
2. to decrypt the password, but I have no clue how to do it .
|
|
|
|
|
|
| Re: how to hide password in script [message #493409 is a reply to message #493198] |
Mon, 07 February 2011 15:38  |
pwl
Messages: 22
Registered: May 2000
|
Junior Member |
|
|
Crocuta,
since you are using linux the following steps will work:
1) create a Operating System identified user in the database
2) in the Linux, as this user, create your script with password.
3) Put the group of this user the same as your runtime user
4) set the permission of the bash script so that anyone in the group has execute
but not read
5) Your runtime user now specifies the full path of the script and gets the output
Mind you unless you start sqlplus with a -s a ps command can show the command
line and hence the password
cheers
pwl
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: how to hide password in script [message #496148 is a reply to message #493961] |
Thu, 24 February 2011 17:01 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
There is no completely secure way to hide a password from a operating system account breach, and therefore you should not be automating scripts that connect to your database using an operating system scheduler.
The correct approach is to create a scheduled job within the database to execute a stored package or procedure. If you require the results of your automated execution to be output to a file on the database operating system, then use UTL_FILE. If you require the results to be delivered to a user, then generate an email using dbms_mail. In order to access utl_file and dbms_mail you will need elevated privileges on your database, and this should be in line with your organisations security requirements.
If you absolutely must execute a script or application from outside the database, for example from a remote host, then create an external password store, to do this you will need to investigate the Oracle mkstore tool. This remote password store is vulnerable to theft and therefore you should ensure the file system security on this file is absolutely correct.
Kind regards,
Michael hartley
[Updated on: Thu, 24 February 2011 23:39] by Moderator Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496182 is a reply to message #496148] |
Fri, 25 February 2011 01:51 |
 |
Michel Cadot
Messages: 68757
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
Quote:There is no completely secure way to hide a password from a operating system account breach, and therefore you should not be automating scripts that connect to your database using an operating system scheduler.
If you don't need to provide a password as when you use Oracle Secure External Password Store, there is no problem.
Quote:The correct approach is to create a scheduled job within the database to execute a stored package or procedure.
Many batches are not just execution of a stored procedure.
Quote:If you require the results to be delivered to a user, then generate an email using dbms_mail.
Most entreprises do not allow to send mail from a database server or from inside the database or restrict it to DBA for database health reporting purpose.
Quote: In order to access utl_file and dbms_mail you will need elevated privileges on your database, and this should be in line with your organisations security requirements.
I agree with the last part. There are very few big entreprises that allows to write on the database server.
Quote:If you absolutely must execute a script or application from outside the database, for example from a remote host, then create an external password store, to do this you will need to investigate the Oracle mkstore tool.
I think this is the correct way.
Quote:This remote password store is vulnerable to theft and therefore you should ensure the file system security on this file is absolutely correct.
Yes, say it in bold.
Regards
Michel
|
|
|
|
| Re: how to hide password in script [message #496225 is a reply to message #496182] |
Fri, 25 February 2011 05:57 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
1. An external application or batch mechanism always needs to provide a password to access the database. All attempts to connect to the database locally using operating system authentication is inherently flawed security. And therefore the question of encryption of a password becomes important.
2. Many application vendors invent a password encryption strategy to effectively hide the password, however encryption is flawed in this case because application must always decrypt the password to connect to the database. If the application is able to execute the decryption function, then it follows a determined individual or group of individuals will also be able to decrypt the password.
3. The problem with operating system batch executions is that they are often designed and developed with the mind set of a security mentality that is out of date. That is, the level of security threat, the cost of the loss of integrity or ownership of the data so great that historic batch techniques are no longer safe. And therefore security is often improved through a combination of uncoupled batch mechanism executed by the operating system and by the database scheduler. As soon as the OS batch attempts a connection to the database, security is compromised. A common approach is slightly complicated but available via the dbms_scheduler event monitoring facilities against OS files.
4. The Oracle wallet mechanism aka secure external password store, is only secure providing no user of the host machine, including root or sudo users can access the wallet files. The use of Oracle wallet is essentially bad practice, but does provide a practical improvement above plain text passwords. I often use wallets in automated RMAN situations. RMAN has a disagreeable tendency on Unix/Linux/windows to publish usernames and password on the process listing.
5. Many organisations have security experts who have little genuine experience of operating complex operational sites and gained most of the security expertise from so called "best practice" guides. From the perspective of choosing a mechanism to post data to a user there is always threat related trade off between making the results of work available to the database consumer.
6. Tested and confirmed packages executing from inside the database that subsequently post results to consumers by email is valid, though not necessarily in all cases. Oracle 11g has improved the email infrastructure and should be used.
7. Clearly there are better mechanism, for example SOAP related infrastructure, but remember the topic of conversation here is not "how do I spend a billion dollars to create a security environment" it was, how do I secure access to my plain text password. For example, if I am running an SME and have 1 IT person who runs the PC shop and the Oracle database, whilst the threat of security does not diminish, the IT practitioner needs to implement security in lots of small strategies that are cost effective and practical.
8. In terms of database access to file systems for writing reports, it is worth remembering that hardware cooling systems are expensive to operate. (okay, cheap to buy these days) but the running costs in terms of both electricity running the hardware the electricity for cooling the equipment. And due to these reasons, many businesses these days either employ virtual machines to separate responsibilities, or combine responsibility into a single operating system platform. I know this sounds like a strategy contraction, in fact it is exactly that, but businesses have to be pragmatic about their revenue streams and therefore you would be surprised how many organisation accept utl_file, external tables and data pump as valid data extraction on the database host.
Kind regards
Michael Hartley
[Updated on: Fri, 25 February 2011 06:11] by Moderator Report message to a moderator |
|
|
|
|
|
| Re: how to hide password in script [message #496262 is a reply to message #496228] |
Fri, 25 February 2011 11:02 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi
the use of the Oracle external password store is bad practice though a better compromise to plain text passwords because:
- it is external to the database and thus only protected by the operating system security.
- contains the username, password and database alias for the target database; these 3 pieces of information in a single store make the existence of the store a high priority target.
- is encrypted and not one way hashed.
- as the file is external to the database it can be stolen and copied to any other host. For example, I can copy it from a Unix host and mount the same file on my Windows PC.
The only secure place to keep a password is in the database because the password is one way hash and cannot be decrypted.
All encrypted data is naturally a target for attack, the very fact that a piece of data is encrypted naturally suggests importance and sensitivity and therefore worth the effort of decryption.
However, as I have already mentioned, an encrypted wallet is better than a plain text, but often suggests a series of poor design decisions.
The only way to secure a facility is to throw the passwords away.
For example, long running applications are started by the application team who change the database password, start the application, provide the password to the application, then throw the password away. The password should not be stored anywhere outside of the database. This way, the password cannot be available to either the root team or the DBA team.
As mentioned previously, batch systems started by OS schedulers is an outmoded and insecure strategy which is best updated to include a decoupled approach.
Kind regards
Michael Hartley
[Updated on: Fri, 25 February 2011 11:18] by Moderator Report message to a moderator |
|
|
|
|
|
| Re: how to hide password in script [message #496269 is a reply to message #496265] |
Fri, 25 February 2011 11:38 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi
not true, the application should not be attempting to store the password. If the application attempts to store the password, then the security model is flawed.
Historically, passwords have been stored by applications to make life easy for the administration and development teams.
Until the fairly recent past only facilities securing highly sensitive information would throw passwords away, but with the expansion of on-line customer trading, on-line customer account management, on-line business to business trading, the rewards for unauthorised access to interested parties are far greater.
Due to the sensitivity of secure data and the impact on the reputation of any organisation that looses that data, the cost of loosing control of a user account includes loss of business, loss of jobs and good old fashioned denial of service.
And therefore, the only secure password is a long, strong and gone password.
Kind regards
Michael Hartley
[Updated on: Fri, 25 February 2011 11:45] by Moderator Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496272 is a reply to message #496269] |
Fri, 25 February 2011 11:47 |
|
Michel Cadot
Messages: 68757
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
Quote:not true, the application should not be attempting to store the password. If the application attempts to store the password, then the security model is flawed.
So how do you provide something that is not stored which means something that is nowhere?
Regards
Michel
[Updated on: Fri, 25 February 2011 11:47] Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496282 is a reply to message #496272] |
Fri, 25 February 2011 15:04 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi
The password is used by the application to authenticate against the database, if the password must be retained in memory ( for example, so that application can re-authenticate if the database is restarted ), the password is obfuscated to defend against memory scan attacks. As described previously, if the application is restarted, the password is recreated at the database, interactively allocated to the application and thrown away by the administration teams.
Kind regards
Michael Hartley
[Updated on: Sat, 26 February 2011 00:46] by Moderator Report message to a moderator |
|
|
|
|
|
| Re: how to hide password in script [message #496318 is a reply to message #496297] |
Sat, 26 February 2011 08:03 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi
you seem to be hanging onto insecure batch processing concepts.
As described earlier, an incrementally more secure batch processing strategy is to create a decoupled and independent OS and database scheduler strategy.
There are already mechanisms within 11g to enable you design and develop database schedule based batch processing tasks that incorporate activities against the OS and the database.
It is very easy to construct problems and barriers with security strategies, however most of the arguments are equivalent to the examples you just provided and are based on operational convenience rather than security.
Briefly, direct suggestions to your problems may be:
1. For an external batch. Decoupled OS and DBMS scheduler designs or DBMS scheduler jobs processing chains where one or more of the chain steps executes an external process.
2. If the external batch mechanism resides on a host remote from the database. Either remote external database scheduler jobs or redesign of the batch mechanism so that the processing can occur closer to the database.
3. No application team at 3am? This is a constructed argument. If your data is sensitive and requires a secure environment, then you need out of hours support. If you organisation cannot afford out of hours support, then the security requirement must be compromised on practical grounds. If you cannot reduce the security requirement due to SOX or PCI standards requirements, then your business cannot operate in it's current format and perhaps the IT support should be outsourced to a professional organisation.
4. I'm sure you can work out how to change a password in a secure environment.
Kind regards
Michael Hartley
[Updated on: Sat, 26 February 2011 08:04] by Moderator Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496320 is a reply to message #496318] |
Sat, 26 February 2011 08:15 |
|
Michel Cadot
Messages: 68757
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
Quote:you seem to be hanging onto insecure batch processing concepts.
No, I am stuck with real cases, not possible ones.
If I was free to choose, I perfectly know how to get secure batch.
The real case is: there are batches that run on batch server and connect to remote database server.
The batches have been written many years ago, they can't be changed, only some parameters can be changed in these batches like connection strings.
These batches are scheduled by external scheduler, local OS scheduler (like cron) or remote mainframe one.
The only thing you can change is the batch environment and this must be transparent to the batch.
What do you do in this case?
I don't think that outsourcing security is something... secure. 
Regards
Michel
[Updated on: Sat, 26 February 2011 12:17] Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496323 is a reply to message #496320] |
Sat, 26 February 2011 08:31 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi
I think you've already answered your own question, that is, due to various constraints, you are unable to re-engine the security model. In cases where the security model cannot be re-engineered, all that is left is to hide passwords using various encryption techniques such as a wallet mechanism.
If your batch environment includes the processing of credit card details and/or other highly sensitive data, you either comply with the data security standards required by your country or you outsource the processing of these details to an organisation that can and there are plenty of organisations that can process your data securely.
Simply encrypting all your connection string data into a wallet does not necessarily make your environment more secure, though it will prevent other users of the batch system getting the connection string from the Unix PS listing.
Kind regards
Michael Hartley
[Updated on: Sat, 26 February 2011 08:35] by Moderator Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496325 is a reply to message #496323] |
Sat, 26 February 2011 09:02 |
|
Michel Cadot
Messages: 68757
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
I think the model is quite safe (but you can point the holes):
- batch server has no account but root, sysadmin and batch accounts
- batch accounts can't be reached by interative session, so only sysadmin can connect
- root can't directly connect only by su/sudo from sysadmin accounts
- only sysadmin can interactively connect (through ssh and secure key, no local password)
- database accounts and passwords are stored in Secure External Password Store
- database allows connection with these accounts only from these batch machines with these batch programs and using some internal passphrases.
So the password is nowhere in clear, only sysadmin can steal the wallet but to use it they should also find how to generate the passphrase (and be on the correct machine/IP but this can be spoofed).
This is one of our model.
In another one, where nothing can be changed in batch but connection procedure, this batch asks for a password to a password application that checks the asker "parameters", generates a password, changes the password in the database and returns the password to the batch which has just a small amount of time to connect before the password application changes it to another one.
(The main issue I see there and I don't like is that this application needs to be able to connect to any database with a quite powerful account.)
In a third one, for the services that have money enough to buy ASO, we implemented Oracle Entreprise users where credentials are checked against a directory.
Of course, all network roundtrips are crypted.
Regards
Michel
[Updated on: Sat, 26 February 2011 12:21] Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496398 is a reply to message #496325] |
Sun, 27 February 2011 13:59 |
Michael Hartley
Messages: 110
Registered: December 2004
Location: West Yorkshire, United Ki...
|
Senior Member |
|
|
Hi
My comments on the batch system.
Seems pretty tight, and if nobody can connect to the batch systems that the probability of the wallet being copied seems unlikely but not impossible. You need to consider the backups: where they are stored, where and when they go off-site, who manages the backups, how the test and development systems are created from Live backup restores, I'm sure there are other observations about backups.
I think you may find the batch program pass phrase does not form part of the database login mechanism. If you are using database login triggers, the most you can expect will be source machine data and session data. Pass phrases simply don't form part of the knowledge of a login trigger. And therefore, anyone that has the wallet can access the RDBMS batch user accounts, even if they only leave a small Easter egg for themselves to exploit in the future.
Check your login triggers; make sure the trigger can discriminate time periods for the batch connections (if this is appropriate), for example, if your batches connect between 22:00 and 23:00, modify your login trigger so that any connection requests outside of that period are rejected and logged.
If you have not started database audit logging, make that an urgent task. Include not only session creation audit records, but also that packages, procedures and functions the batches execute. Routine examination of the audit logs will help you identify typical behaviour and therefore atypical behaviour. Ensure dangerous package executions are audited across all your databases, my default audit list looks like this
AUDIT EXECUTE ON sys.DBMS_EXPORT_EXTENSION by access;
AUDIT EXECUTE ON sys.DBMS_FGA BY ACCESS;
AUDIT EXECUTE ON sys.DBMS_FILE_TRANSFER BY ACCESS;
AUDIT EXECUTE ON sys.DBMS_JOB BY ACCESS;
AUDIT EXECUTE ON sys.DBMS_LOB by access;
AUDIT EXECUTE ON sys.DBMS_NETWORK_ACL_ADMIN BY ACCESS; -- 11g
AUDIT EXECUTE ON sys.DBMS_RANDOM by access;
AUDIT EXECUTE ON sys.DBMS_RLS BY ACCESS;
AUDIT EXECUTE ON sys.DBMS_SCHEDULER BY ACCESS;
AUDIT EXECUTE ON sys.DBMS_XMLGEN BY ACCESS;
AUDIT EXECUTE ON SYS.KUPP$PROC BY ACCESS; --this is an interesting package to monitor. I recommend you keep a very close eye on this package!
AUDIT EXECUTE ON sys.UTL_FILE by access;
AUDIT EXECUTE ON sys.UTL_HTTP by access;
AUDIT EXECUTE ON sys.UTL_MAIL by access;
AUDIT EXECUTE ON sys.UTL_SMTP by access;
AUDIT EXECUTE ON sys.UTL_TCP by access;
My comments on the password system.
This seems like a crazy idea. I cannot imagine how a batched mechanism is better secured simply because the batch can request a password change each time it runs. Not only is the password application likely to be an insecure mechanism for obtaining passwords, but the mechanism itself must have some kind of stored credential so that it can connect to the database, and no doubt, as a super user. I bet most people could work the password application interface by reading the batch scripts.
The entire strategy seems like nothing other than an attempt to make the batch login procedure complicated but not secure. The most effectively systems are nearly always simple. Any system that ejects passwords on request are likely to a target for interested persons.
Personally, I would dump the password application, use a wallet but keep a very close eye on who can access the wallet and work hard on the database login trigger for the batch users.
My comments on the ASO system.
Single sign on is an administrative convenience facility and of course users love them because it just make life so easy. Single sign on (SSO) facilities are everywhere these days, but I wouldn't trust my bank account details with an SSO provider, even if they were authorised and regulated.
Why? Because if the SSO directory is leaked then I have lost control of everything. How the directory is leaked does not matter, the fact remains that it can leak, unless you unplug the system from the network, burn the backup tapes and lock the service in a concrete safe with no users. Even then somebody may break into the safe.
SSO is just great for your HR applications, your business intranet services like timesheet systems, shared online storage systems.
Super users should never form part of the SSO network because the cost of losing control of one super user could be catestrophic for an organisation.
Are the SSO users audited? Are you sure people are not sharing accounts? Would you know if people are sharing accounts? Do you have an effective joiners and leavers policy that actually works. Do you lock accounts that haven't been used for several months? Are you forcing users to change their passwords every 90 days? Are you enforcing a long and strong password policy?
In summary
We don't always need to create individual bullet proof security, we just need lots of it. Like onion rings, each ring of defense should be firm and effective, but an interested person will overwhelm an individual ring, no matter how tough it is. There are a lot of darn clever people out there. Therefore, we need a lot of rings, with auditing and alerting. If an security ring is breached, we need to know that it happened, how it happened and how we can stop it happening again.
If you don't get the security right, you organisations credit card number might end up on the internet and your customers will dump you faster than last nights curry.
Kind regards
Michael Hartley
[Updated on: Mon, 28 February 2011 00:58] by Moderator Report message to a moderator |
|
|
|
| Re: how to hide password in script [message #496413 is a reply to message #496398] |
Mon, 28 February 2011 01:33 |
|
Michel Cadot
Messages: 68757
Registered: March 2007
Location: Saint-Maur, France, https...
|
Senior Member
Account Moderator |
|
|
Quote:Seems pretty tight, and if nobody can connect to the batch systems that the probability of the wallet being copied seems unlikely but not impossible. You need to consider the backups: where they are stored, where and when they go off-site, who manages the backups, how the test and development systems are created from Live backup restores, I'm sure there are other observations about backups.
This is right but go far from the original question.
Quote:I think you may find the batch program pass phrase does not form part of the database login mechanism. If you are using database login triggers, the most you can expect will be source machine data and session data. Pass phrases simply don't form part of the knowledge of a login trigger. And therefore, anyone that has the wallet can access the RDBMS batch user accounts, even if they only leave a small Easter egg for themselves to exploit in the future.
You are right passphrase is not part of the login but next step of the (logical) connection: batch accounts can do nothing but connect without the passphrase (which is by no means insignificant as PUBLIC has, for me, by default too large privileges), roles are enabled by it (we use Oracle secure application roles).
Quote:Check your login triggers; make sure the trigger can discriminate time periods for the batch connections (if this is appropriate), for example, if your batches connect between 22:00 and 23:00, modify your login trigger so that any connection requests outside of that period are rejected and logged.
This is part of what I mean with "batch account parameters".
Quote:If you have not started database audit logging, make that an urgent task.
Of course, it is. Thanks for your detailed list.
Quote:the mechanism itself must have some kind of stored credential
I agree, I said I don't like it but sometimes client wants something without any possible debate.
Quote:and no doubt, as a super user.
No only the privilege to execute a procedure to change password of batch/application user accounts. And to anticipate, no the procedure cannot be subject of sql injection.
Quote:I bet most people could work the password application interface by reading the batch scripts.
Not so easy as most parameters are "physical" ones (machine, ip, date/time...) that are autmotically sent by OCI interface but as I said I don't like so much this solution.
Quote:Personally, I would dump the password application, use a wallet but keep a very close eye on who can access the wallet and work hard on the database login trigger for the batch users.
Which is our first solution.
Quote:My comments on the ASO system
We don't use SSO just Oracle Entreprise user.
Quote:Are you sure people are not sharing accounts?
People are responsible of their digital prints. 
Quote:Do you have an effective joiners and leavers policy that actually works.
Yes, very efficient, too efficient sometimes.
Quote: Do you lock accounts that haven't been used for several months?
Yes and it is not months but weeks.
Quote:Are you forcing users to change their passwords every 90 days?
60.
Quote:Are you enforcing a long and strong password policy?
Of course.
Thanks a lot for all your comments, I wanted to make this topic like a reference discussion about batches for this Security forum, sorry if, with my first remarks, I make you feel I was really dumb.
Regards
Michel
|
|
|
|
Goto Forum:
Current Time: Sun Apr 27 07:26:52 CDT 2025
|
] 
Blog
Search
Help
Members
Register
Login
Home
