您可能想要尝试Kerberos，它可以使用操作系统用户的凭据，并将操作系统用户添加到外部标识的数据库中。请确保使用Kerberos，而不是使用旧的方法，因为旧的方法存在严重的安全问题。

对于Kerberos支持，您需要高级安全选项和最新的JDBC驱动程序，可能是11g版本。在尝试让它在Java中工作之前，请在Sql*Plus中使用/作为用户名和空密码进行尝试。“从双重选择用户”应该会给你user@domain.您还可能发现，在Kerberos配置方面，使用瘦驱动程序和OCI驱动程序之间存在根本区别。

您肯定不希望在没有凭据的情况下连接到数据库，因为这会使数据库容易受到攻击。

这是一个常见的问题，我如何存储访问外部系统所需的凭据？WebLogic有一个凭据映射器来解决这个问题，其中凭据（加密的）存储在嵌入式LDAP中。许多Oracle产品使用凭证存储功能，将凭证存储在Oracle钱包中。

在这个问题中，你提供了答案。存储加密的密码，并在需要时解密。显然，您必须使用对称加密算法（如3DES）才能解密。请确保对称密钥不是可以猜测的。

诀窍在于，您可以保留加密/解密所需的对称密钥。你可以把它放在一个通过操作系统保护的文件中，也可以把它保存在代码中，但你需要保护代码的安全。如果您使用的技术能够生成相同的密钥，并且算法相当安全，那么您也可以生成密钥。

如果你能保证代码的安全，那么你显然也可以在代码中保留密码。但是，您需要能够在不更改代码的情况下更改凭据的灵活性。

您也可以在此解决方案中添加更多层。您可以加密配置文件（使用不同的密钥）以及其中的密码，使黑客发现2个密钥。还有其他更安全的方法使用PKI，但它们很难设置。

我建议您研究代理身份验证。这在Oracle®数据库安全指南以及Oracle®Database JDBC Developer’s Guide and Reference（Oracle®数据库JDBC开发人员指南和参考）。从本质上讲，这允许您在数据库中拥有一个只有连接权限的用户。用户的真实数据库帐户被配置为能够作为代理用户进行连接。然后，通过JDBC连接的应用程序会存储代理用户名和密码，并且在连接时提供这些凭据，再加上用户连接字符串中实际数据库用户的名称。Oracle作为代理用户进行连接，然后模仿真实的数据库用户，继承真实用户的数据库权限。

所有J2EE容器（JBOSS、Tomcat和BEA）都有连接池。他们将打开许多连接，使它们保持活动状态，并在＜code＞1/100＜/code＞＜sup＞th＜/sup＞中为您提供从头开始创建一个连接所需的时间。

此外，它们还有一些很酷的功能，例如，在＜code＞JBOSS＜/code＞中，所有的连接信息都存储在一个外部文件中。如果您更改连接信息，即从测试切换到生产数据库，您的应用程序将动态地从新池获得连接

好消息是，您不需要运行完整的J2EE容器就可以使用连接池。外部资源允许以明文或伪加密的方式存储密码。

有关使用Tomcat内置连接池的指南，请参阅apache commons dbcp：

• http://vigilbose.blogspot.com/2009/03/apache-commons-dbcp-and-tomcat-jdbc.html

据我所知，jdbc连接用户名/密码需要以纯文本形式存储。限制这种可能风险的一种方法是限制用户的权限，以便只能使用给定的应用程序数据库，并且只能从预定义的主机使用。IMO，这将极大地限制攻击者：他只能使用来自原始应用程序所在主机的un/pw，并且只能攻击原始应用程序的数据库。

我过去曾对此感到疑惑。

该解决方案当然包括在服务器和网络级别具有适当的网络安全性，以真正减少可以访问系统的人数，并且拥有数据库凭据只允许访问数据库帐户，而该帐户只具有运行应用程序所需的最低权限。

对财产文件进行加密可能足以阻止“懒得去找密钥或密码短语”，让攻击者进入下一个受到威胁的服务器。然而，我不会依赖“我的邻居不太安全，所以请从他那里偷”的安全措施！

有两种关键方法，它们都对系统的设计产生了重大影响，因此在不进行重大重写的情况下，从一种方法转移到另一种方法是不容易的。在选择之前，您需要了解公司的安全治理策略是什么。

1） 每个用户都有证书，这些证书通过应用程序携带，用于应用程序正在使用的服务；在您的情况下，Oracle数据库使用这些用户凭据连接到数据库。缺点是每个用户都需要每个安全服务的凭据。这是一种合理的安全方法，但也需要大量额外的工作来提供和维护用户凭据。您的数据库管理员需要主动管理用户凭据，这可能与您公司的安全治理策略背道而驰。

2） 应用程序数据库凭据存储在安全目录服务上，例如安全LDAP。应用程序使用用户的凭据访问目录服务。目录服务为正在访问的服务返回相应的凭据。

在这两种情况下，应将数据库凭据限制为仅执行适当的操作。例如，凭证应反映业务流程的要求；它们允许从定义的视图/表中进行选择，插入其他视图/表，但不允许创建、更新或删除表。在第二种方法中，对每个主要业务流程使用单独的凭证，例如订单处理、会计、人力资源等。

然而，请记住，如果有人剥离了访问应用程序的层，这样他们就可以访问DB竞争池配置文件，那么安全性就像洋葱的层。他们可能会通过特洛伊木马程序捕获用户的凭据。这就是良好的安全治理策略的用武之地。

安全治理是一个复杂的问题，需要高级管理层的承诺，因为如果您的实时平台需要这种级别的安全性，则需要付出代价。您需要将开发的责任与部署、运营和维护分开；用户权限管理。您可能还需要有安全审计员，他们有查看更改的完全访问权限，但不能更改配置。它远非简单，而且是高薪专业。

由于我不完全清楚您的环境，除了Java&；JDBC与Oracle对话我将对此进行讨论。

如果你谈论的是Java EE应用程序，你应该能够在应用程序服务器上设置连接池和数据源，然后你的应用程序与处理该级别连接的连接池进行对话。

连接池和数据源保存并保护凭据。

您可以将凭据存储在任何位置，包括程序中的硬连线字符串或Windows注册表中的条目。不过，如果您使用了一些非标准的东西，则由您来检索它们；我不知道有任何不是明文的预先推出的解决方案。

您可以尝试Oracle的代理身份验证，JDBC客户端使用证书对数据库服务器信任的已知中间层组件/服务（代理）进行身份验证。不过我从来没有尝试过，所以我不知道这是否容易做到。

除了前面提到的解决方案（Kerberos身份验证，使用代理身份验证）之外，还有两种其他解决方案都可以使用JDBC精简驱动程序：

1. Store the password in an SSO wallet: a wallet can be used to store the user s password. If you use an SSO wallet then the wallet itself doesn t have a password. SSO wallets are commonly used in the context of SSL but they can also be used to just store a password.
2. Use SSL with user authentication: configure SSL with a user that s externally authenticated by the Distinguished Name (DN). This user doesn t have a password. As long as you connect with SSL using a certificate that has this DN you ll be able to create a session using this user.