开头声明一下我对 laravel 不是那么了解..
※ 引述《st1009 (前端攻城师)》之铭言：
: 各位大大日安
: 不才想请教一下Laravel的登入系统，
: 不才写了段code如下:
: $email = '[email protected]';
: $password = 'user-password';
: dd(Auth::attempt(['email' => $email, 'password' => $password]));
: 但是我从Stack上捞到了一组hash码如下
: $hash = '$2y$10$NhRNj6QF.Bo6ePSRsClYD.4zHFyoQr/WOdcESjIuRsluN1DvzqSHm';
: 我使用我的password并且DB里面密码是使用这组hash时，
: 可以登入php artisan make:auth造出来的登入页面，
: 却无法登入上面那段code，不知道出了什么问题...
: 恳请各位大大解惑。
这个会建议你先把 dd 拔掉换成简单的 if / var_dump 之类的接上 exit
印出来看看到底跑了什么东西出来. 因为不是很确定你的 function dd
做什么的, 但有可能它的行为会不如你预期..
: 此外我使用bcrypt()时，每次结果都不一样...不知道要怎存DB，相当困惑。
要怎么存 DB 可能要看你用的 bcrypt 从哪来的了..
( PHP 有相似的功能, 但没直接内建这个名字的 function )
bcrypt 是个基于 blowfish cipher 的 hashing function,
既然是 hashing 那就是单向不可逆的, 而且就会有 cost / salt 这些问题,
使用的 cost / salt 不一样就会有不一样的结果;
这些资讯也必须一并存在 database 里面
所以说要怎么存得看你怎么产生的.
$2y$10$NhRNj6QF.Bo6ePSRsClYD.4zHFyoQr/WOdcESjIuRsluN1DvzqSHm
若是以前述的这个为例子, 那就是..
$2y$ -> blowfish 的前缀
10$ -> cost = 10
NhRNj6QF.Bo6ePSRsClYD. -> hashing salt
4zHFyoQr/WOdcESjIuRsluN1DvzqSHm -> hashed result
你可以试试看:
echo crypt('user-password', '$2y$10$NhRNj6QF.Bo6ePSRsClYD.');
结果就会是前述那段.
想知道更多可以参考:
https://en.wikipedia.org/wiki/Bcrypt
https://www.php.net/manual/en/function.password-hash.php
( PASSWORD_BCRYPT 那段 )
https://www.php.net/manual/en/function.crypt.php
( CRYPT_BLOWFISH 那段; 其实前一个 link 就会把你骗来这了 )
然后是说 $2y$10$NhRNj6QF.Bo6ePSRsClYD.4zHFyoQr/WOdcESjIuRsluN1DvzqSHm
这个就是一个存 database 的良好范例了, cost / salt 都存放一起是 ok 的.
不需要做额外的修饰以及混淆, 额外的动作对于安全性帮助不大
只会徒增日后维护的困难.
这也有很多额外的延伸阅读, 但这边就偷懒不放了 /o,o\
: 之所以要使用bcrypt()是因为本来有一个原有系统，使用者已经在上面注册了帐密了，
: 希望搬到laravel之后，他们可以使用原来的帐密登入，
: 目前的想法是，
: 1.把登入密码先用原来的md5加密
: 2.传给laravel登入
: 为了完成这点，
: 1.我需要一个可以自定义的登入系统。
: 2.我需要把原有数据库里的MD5数据，用laravel的方式加密。
: 可是完全搞不懂Laravel的登入系统，太复杂了...
: 恳请各位大大帮忙<(_ _)>
: 另外我也看不太懂藏在hidden的csrf要如何作用...
看到 "md5加密" 这个首先必须要先厘清一点..
(password/) hashing 跟 encryption (加密) 是不同的东西:
前者是单向的, 后者才能取回原文;
前者目的是为了避免资料外流后使用者在其他网站的帐号也遭殃,
后者则是有各种可能的目的.
回到你的正题.. 就我的理解你现在构想的设计是:
1. 把旧数据库的 md5 纪录丢给 laravel 的 password hashing function
以后储存在 laravel 的数据库里面.
2. 使用者来了以后先用 md5 hash 完以后才拿去 laravel 的登入 Auth:: 那个
验证使用者的身分.
hmm.. 可以是可以啦, 但有点不太好:
1. 这样子让密码被缩限于 md5 的 128 bits 长度,
亦即可以轻易的猜完所有组合然后登入任何使用者 ( 数据库遭窃状况 )
2. 日后若想再搬迁会增加维护上的困难 ( 今天你是 md5 还好,
这种作法若是遇上了有 cost/salt 的又 php 版本问题真的就会撞山 )
3. 你的这个前置的 md5 动作必须随着日后 laravel 更新一起维护拔不掉
遇到 password hashing function 改变通常的作法是..
0. 预先把旧系统的帐号在新系统里面注册起来, 标注一个尚未搬迁的 flag
( 这个用来避免旧帐户回锅前就被新系统的其他人注册造成冲突 )
1. 使用者经由新系统登入
2. 新系统登入失败后由额外的 code 介入
( wordpress 直接有 hook 可以用, laraval 我不熟 Orz )
3. 检查新系统里面是否真的存在帐号
3n. 登入失败 不做额外处理 (end)
4. 检查帐号搬迁完毕 flag 是否已完成搬迁
4y. 已完成搬迁者 登入失败 不做额外处理 (end)
5. 将帐号密码拿去旧系统登入看看是否会成功
5n. 登入失败 不做额外处理 (end)
6. 透过新系统的方式变更密码, 将明文密码交由新系统去储存
并且标注为已完成搬迁 (登入成功)
亦即真正正确的密码搬迁到新系统的数据库是发生在你改好以后
使用者第一次回来成功登入你的网站的时候.
99. 超过一定时间或者一定比例使用者回锅后关闭上述途径
日后再回锅的就人工接洽处理或者系统信变更密码那套处理
( 一来是旧系统就算只有 user 这个 table 撑著也是种成本
二来是时间太久的说实话密码的安全性也没多少 不如重新验证 )
这种做法的好处是:
- 比较不恼人 (使用者; 相较于强迫重发密码变更信之类的方法而言)
- 不牺牲新系统的 hashing 所带来的安全性强度
- 单纯化资料与处理方式, 不会几年后你要透过层层 hashing 才能登入
当然也是有缺点:
- 相当多额外的 code (对老板来说没差 A_A)
- 去旧系统验证登入这段有时间差, 严格上来说算是一种安全性漏洞
( 输入一组帐号明显网页反应时间比较慢就知道这组帐号存在且未回锅 )
- 相当多额外的 code (没错 没错)