gpt4 book ai didi

MySQL 区分大小写(或者,如何在 MySQL 中正确存储密码)

转载 作者:行者123 更新时间:2023-11-29 06:15:09 25 4
gpt4 key购买 nike

原因:

我有一个表,所有列都适本地整理utf8mb4_unicode_ci

CREATE TABLE IF NOT EXISTS `users` (
`user_id` int(8) NOT NULL AUTO_INCREMENT,
`username` varchar(100) NOT NULL,
`pass_word` varchar(512) NOT NULL ,
...etc etc...
PRIMARY KEY (`user_id`),
UNIQUE KEY `email_addr` (`email_addr`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=989 ;

...包括存储密码哈希的列(从 password_hash 生成),例如 $2y$14$tFpExwd2TXm43Bd20P4nkMbL1XKxwF.VCpL.FXeVRaUO3FFxGJ4Di

BUT,我发现由于列的大小写不敏感,$2y$14$tFpExwd2tXm43Bd20P4NKmbL1XKxwF.VCpL.FxEVRaUO3FFxGJ4DI 的散列> 仍然允许访问。

这意味着以不区分大小写的方式存储数据可能会发生数百次冲突。不好。


问题:

现在,有没有办法在进行比较时强制 MySQL 将 pass_word 列视为区分大小写 列。我想避免编辑每次出现的 PHP/SQL 查询,而是简单地将数据库表列设置为以区分大小写的方式进行比较默认

utf8mb4 字符集没有给我任何 _cs 选项,唯一的非 _ci 选项似乎是 utf8mb4_bin

很简单的问题:

  • MySQL 上的 UTF8mb4_bin 字符集和排序规则是否区分大小写处理标准比较? [是]
  • 使用 UTF8mb4_bin 来满足我的需求。我应该使用另一套吗?如果是,为什么?
  • 在 MySQL utf8mb4_bin 列中存储 password_hash 输出是否有任何问题?
  • 这种方法是否方便地避免了编辑每个登录查询的查询 SQL 的需要?我可以更改列类型然后继续吗?

编辑

As detailed by nj_ , this is a silly issue that is not an issue at all because the value of pass_word is never directly edited when logging in. ... It's been a long day.

最佳答案

如果您真的很担心 62^55 地址空间中潜在的 2^55 冲突,您只需将列类型更改为 BLOB,它始终区分大小写。

CREATE TABLE IF NOT EXISTS `users` (
`user_id` int(8) NOT NULL AUTO_INCREMENT,
`username` varchar(100) NOT NULL,
`pass_word` BLOB NOT NULL ,
...etc etc...
PRIMARY KEY (`user_id`),
UNIQUE KEY `email_addr` (`email_addr`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=989 ;

例子:

INSERT INTO `users` (..., `pass_word`) VALUES (..., 'AbC');

SELECT * FROM `users` WHERE `pass_word` = 'AbC' LIMIT 0,1000; -> 1 次命中

SELECT * FROM `users` WHERE `pass_word` = 'abc' LIMIT 0,1000; -> 0 次命中

关于MySQL 区分大小写(或者,如何在 MySQL 中正确存储密码),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36314130/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com