使用“数据库中”设计的身份验证管理

Question

我想讨论一下好主意还是坏主意：

我得到了一个MySQL DB，并创建了一个通用表"user“来验证登录名。

|User|
|user_id|username|password|created_at| 

我实现了一个存储函数和一些触发器。

首先：

ON BEFORE UPDATE

将在更改SHA256时生成password哈希和salt。salt是由created_at、user_id和存储在另一个“配置表”中的全局salt_mod混合生成的。

因此，当通过普通UPDATe在“密码”中输入123时，它将产生用户唯一的密码和盐散列。

接下来，我实现了一个存储函数。

checkUserAuth('username', 'password') 

返回:真或假

当然:接收普通用户名和密码，复制相同的散列逻辑，并返回bool "true“或"false"，这取决于凭据是否正确。

专业：

如果数据库的用户帐户被窃取，由于缺乏读取函数源代码和存储登录信息的列的权限，应用程序使用的任何连接apps.

• Database-account都可以不选择privileges.

• Even上的“用户名”、“密码”和"salt“privileges.

• Even，从而使密码算法完全同步。我们这里只有一个执行特权。

Contra：

• 好吧，如果有人以根权限侵入数据库，那么“如何生成散列”的源代码就会被泄露(基本上是盐渍公式)以及所有信息在一个地方被泄露。然而，由于global_salt.

在created_at date和user_id上的独特散列，彩虹表仍然很难找到。

将问题到上面的场景

Is this a good approach or totally vulnerable in point of data-security? 

我的意思是，一方面，数据库内部的入侵总是一个不应该发生的问题。

另一方面，即使应用程序的源代码被盗或应用程序中的漏洞窃取了数据库帐户，也不能窃取任何与登录相关的数据。

根帐户当然不允许在其他地方使用，然后在本地主机/服务器上使用。

你觉得这个怎么样？

Answer 1

主要的缺点是，在创建行时，以及每次调用checkUserAuth()函数时，都会以明文形式传递密码。

这可以窃听(除非确保在应用程序和数据库之间使用SSL连接)，如果启用了查询日志，它将被写入查询日志。它在processlist和performance_schema语句历史表中也是可见的。

这是在客户端中进行散列的一个很好的理由，并且在创建行时只发送密码的咸散列。验证时，从数据库中获取咸散列，并根据客户端中的用户输入对其进行验证。