开头声明一下我对 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 (没错 没错) --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.169.46.22 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/PHP/M.1558467687.A.8C7.html ※ 编辑: Crow22312 (118.169.46.22), 05/22/2019 03:45:32 ※ 编辑: Crow22312 (118.169.46.22), 05/22/2019 03:46:46 也不是真的全都自己想出来的啦 /o,o\ 是之前搬迁过一个 md5/bcrypt 混成的到我也忘了用什麽 hashing 的去 所以还算有记忆.. 只不过就找不到之前是参考 stackoverflow 上的哪篇了 link 看起来不通, 或许指的是这篇(?) https://stackoverflow.com/a/36062706 更新资料库中密码的动作可以跟验证拆开这还真是没想到, 一拆开还真的清楚又简洁 ※ 编辑: Crow22312 (118.169.46.22), 05/24/2019 01:30:48 这篇直接把 1 2 5 6 都处理好了 真不错 // This model use your second connection to the other database 这段如果我没理解错, 是连去现行 laravel 使用以外的其他 user table 那就要小心: a. 拿到就密码的坏人可以一直用旧密码登入 ( 甚至有可能因为使用的是 collision 所以真正帐号主人反而会变得无法登入.. ) b. 因为回锅时间太慢被其他人注册走相同帐号发生不可预期的问题 ( 但都用 email 当帐号的话应该就不会? ) ※ 编辑: Crow22312 (118.169.46.22), 05/24/2019 02:20:06