简短的回答

你不能

如果密码存储在发送给最终用户的工件中，您必须认为它已被泄露！即使工件是已编译的二进制文件，也总是有(或多或少复杂的)获取密码的方法。

保护资源的唯一方法是只向最终用户公开有限的API。要么构建编程API(REST、WS+SOAP、RMI、JavaEE+Servlets，…)，要么只通过SPROCs在DB中公开某些功能(见下文)。

一些事情先

这里的问题不应该是如何隐藏密码，而是如何保护数据库。请记住，密码通常只是一种非常弱的保护，不应被视为保护数据库的唯一机制。你在使用SSL吗？不？好吧，那么即使如果成功地在应用程序代码中隐藏了密码，在网络上嗅到它仍然很容易！

你有多种选择。都有不同程度的安全：

“应用程序角色”

为应用程序创建一个数据库用户。为此角色应用授权。一个非常常见的设置是只允许CRUD操作。

专业人士非常容易设置

防止查询(例如SQL注入？)

Cons每个看到密码的人都可以访问数据库中的所有数据。即使该数据通常隐藏在应用程序中。

如果密码泄露，用户可以在没有条件的情况下运行UPDATE和DELETE查询(即：立即删除/更新整个表)。

原子身份验证

为每个应用程序/最终用户创建一个数据库用户。这允许您定义原子访问权限，即使是在每列的基础上。例如：用户X只能从表foo中选择列far和baz。没有别的了。但用户Y可以SELECT所有内容，但没有更新，而用户Z具有完全CRUD(select、insert、update、delete)访问权限。

有些数据库允许您重用操作系统级凭据。这使得对用户的身份验证是透明的(只需要登录到工作站，然后将该标识转发到数据库)。这在完整的MS堆栈(OS=Windows，Auth=ActiveDirectory，DB=MSSQL)中最容易实现，但据我所知，在其他DBs中也可能实现。

专业人士设置起来相当容易。

非常原子的授权方案

Cons在数据库中设置所有访问权限可能会很繁琐。

拥有UPDATE和DELETE权限的用户仍然可能是意外的(或有意的？)删除/更新而不使用标准。可能会丢失表中的所有数据。

具有原子身份验证的存储过程

在应用程序中编写noSQL查询。通过SPROCs运行所有项。然后为每个用户创建数据库帐户，并仅为存储过程分配特权。

专业人士最有效的保护机制。

存储过程可以强制用户向每个查询传递条件(包括DELETE和UPDATE)

Cons不确定这是否适用于MySQL(我在这方面的知识很薄弱)。

复杂的开发周期：您想要做的一切，必须首先在存储过程中定义。

最后的想法

不应允许应用程序执行数据库管理任务。大多数情况下，应用程序只需要SELECT、INSERT、DELETE和UPDATE这些操作。如果您遵循此准则，用户发现密码几乎不会有风险。除了上面提到的几点。

无论如何，保留备份。我假设您希望针对意外删除或更新对数据库进行投影。但是意外发生了。。。记住这一点；)