有些事情首先
这里的问题不应该是如何隐藏密码,而是如何保护数据库.请记住,密码通常是非常弱的保护,不应被视为保护数据库的唯一机制.你在使用SSL吗？没有？那么即使你设法将密码隐藏在应用程序代码中,仍然很容易在网络上嗅探！
您有多个选项.全部具有不同程度的安全性：
“应用角色”
为应用程序创建一个数据库用户.应用此角色的授权.一个非常常见的设置是允许CRUD操作.
优点
>非常容易设置
>阻止DROP查询(在SQL注入中为f.ex.？)
缺点
>看到密码的人都可以访问数据库中的所有数据.即使该数据通常隐藏在应用程序中.
>如果密码被盗用,用户可以无条件地运行UPDATE和DELETE查询(即：一次删除/更新整个表).
原子认证和认证
每个应用程序/最终用户创建一个数据库用户.这允许您即使在每个列的基础上定义原子访问权限.例如：用户X只能从表foo中选择far和baz.没有别的但用户Y可以选择所有的内容,但没有更新,而用户Z具有完整的CRUD(选择,插入,更新,删除)访问权限.
优点
>相当容易设置.
>非常原子授权方案
缺点
>可以很乏味
>具有UPDATE和DELETE权限的用户仍然可能会意外(或故意地)删除/更新无条件.您可能会丢失表中的所有数据.
存储过程与原子验证&auth
在您的应用程序中不写SQL查询.通过SPROC运行一切.然后为每个用户创建db-accounts,并将权限分配给SPROC.
优点
>最有效的保护机制.
> SPROCs可以强制用户对每个查询(包括DELETE和UPDATE)传递标准
缺点
>不知道这是否适用于MySQL(我在该领域的知识是片面的).
>复杂的开发周期：您要做的一切都必须首先在SPROC中定义.
最后的想法
您不应该允许应用程序的数据库管理任务.大多数情况下,应用程序需要的唯一操作是SELECT,INSERT,DELETE和UPDATE.如果您遵循这个准则,用户几乎没有发现密码的风险.除上述要点外.
无论如何,请保留备份.我假设你想为你的数据库预测意外的删除或更新.但事故发生…记住这一点;)
