Re: DB link Secureness

From: Lok P <>
Date: Sat, 19 Dec 2020 19:01:36 +0530
Message-ID: <>

Thank you Andy.

I hope you mean that the technique mentioned in the blog below , i.e the password for the DB link as it's stored in$ table can be decrypted using dbms_crypto.decrypt?

Also if I understand you correctly, as the password is readable/decryptable in this version, So if somebody gets access to sys.Link$ OR dbms_decrypt OR having export/import privilege OR SYSDBA privilege can see it and play with it. So it is advisable to control access/privileges on these entities rather than worrying about the exposure of DBlink password through export/import file/utility.

And by the way, from your description it looks like a simple export of a db link and importing it on any other database can quietly create it with the same password/credentials without fail. Correct me if wrong.

And yes, we are planning to move to 19C asap, but some third party tool dependency are currently restricting us for that, but it's in plan.

On Sat, Dec 19, 2020 at 5:54 PM Andy Sayer <> wrote:

> For 100% clarity, DB link passwords can be read without much issue in an
> 11g database if you have the right privileges (default sysdba).
> If you have privileges to export the DB link then you can import it
> wherever you want and grab the password from the database it was imported
> into. You want to treat your DB exports as secure as possible (you would be
> doing this anyway because data leaks are a serious problem).
> As long as sysdba is only given to authorised people and as long as you’re
> not putting exports in insecure places then you should be okay. That said,
> there may well be privilege escalation vulnerabilities in your version of
> Oracle, there might even be in some of the code that you’ve manually
> deployed on top.
> There’s not really a more secure replacement for DB links, if you need to
> use them then you’re going to have a hard time moving away.
> Thanks,
> Andy
> On Sat, 19 Dec 2020 at 11:58, Lok P <> wrote:
>> Thank You.
>> Actually even these are two different databases and both are prod say DB1
>> and DB2 and are in the same network. The DB links of DB1 should not get
>> simply imported to DB2 silently(with same credentials under the hood even
>> if it's not exposed in EXPORT/IMPORT files) thus opening a window to access
>> the REMOTE PRODDB (say DB3) which was initially meant for DB1
>> users/applications only. Won't this be considered as a threat? Correct me
>> if my understanding is wrong here.
>> On Sat, Dec 19, 2020 at 11:56 AM Stefan Knecht <>
>> wrote:
>>> Well, there's two sides to this.
>>> In any proper secured network, a DEV machine should not be able to
>>> connect to a PROD machine. Be it via DB link or any other means. That's not
>>> a database problem, that's a network zoning problem.
>>> But also, most places use post-import or post-restore steps which are
>>> automatically or manually performed, to deal with anything left over that
>>> shouldn't be the way the import creates them (e.g. you'd replace real world
>>> user's emails with dummy emails when refreshing dev or qa with prod, and
>>> you'd likely also want to change any passwords or database links
>>> accordingly).
>>> On Sat, Dec 19, 2020 at 1:34 AM Lok P <> wrote:
>>>> I checked two ways i.e first by taking the export dump and doing impdp
>>>> with parameter SQLFILE and as I see in version the dblink DDL is
>>>> having a bind variable in place of password.
>>>> Then I did try to see the .DMP file content and it's all junk. I didn't
>>>> see any hashed value or bind value. So that looks perfect with respect to
>>>> security stand point.
>>>> Now one thing wanted to see, if somebody takes the export dump of
>>>> dblink from PRODDB and import it in some Dev database say DEVDB , will that
>>>> dblink will be created without any error? And in that case will the user
>>>> silently able to connect to the REMOTEPROD using that dblink without
>>>> anyone's notice? If it's true then even the password is not exposed to
>>>> outside but still it's a security risk. Correct me if wrong?
>>>> On Thu, 17 Dec 2020, 9:59 am Lok P, <> wrote:
>>>>> I am not very sure how to create DB links using TCPs and if it's the
>>>>> safest with no security loophole. Can you explain a bit and we are on
>>>>> so if there is any version dependency?
>>>>> But the below doc does state that the password was stored as cleartxt
>>>>> in$ in prior 10GR2. But nothing mentioned if export/import
>>>>> password is exposing that in clear text in current versions or not?
>>>>> MOS Doc ID 202987.1
>>>>> On Thu, Dec 17, 2020 at 8:14 AM Mladen Gogala <>
>>>>> wrote:
>>>>>> Or create link using TCPS.
>>>>>> On 12/16/20 2:03 PM, Powell, Mark wrote:
>>>>>> > Ask the security team to present you proof the password can be
>>>>>> exposed
>>>>>> > when some exports/imports the link
>>>>>> --
>>>>>> Mladen Gogala
>>>>>> Database Consultant
>>>>>> --
>>> --
>>> //
>>> zztat - The Next-Gen Oracle Performance Monitoring and Reaction
>>> Framework!
>>> Visit us at | _at_zztat_oracle | |

Received on Sat Dec 19 2020 - 14:31:36 CET

Original text of this message