这是一个创建于 3649 天前的主题，其中的信息可能已经有所发展或是发生改变。
github 使用 ror 开发的，那么应该使用的是 ror 的自带的密码管理系统，我不了解 ror ，应该也是 salt+散列方法对密码加密(PBKDF2 或者 bcrypt 或者是自研的）。
但是 github 的 api 又是支持 http basic authentication 的，也就是原始密码有可能会被明文保存，或者对称式加密保存，是这么理解吗？那被拖库不是不安全了？
第 1 条附言 2015-10-31 09:59:50 +08:00
sorry ，脑子缺氧了，理解错了。汗~~~
 | 1 cyberdak 2015-10-30 13:16:07 +08:00 http basice auth != 明文 |
 | 2 tony1016 2015-10-30 13:17:58 +08:00 既然保存的散列，比较的也是散列，何必要保存明文。至于你说的“有可能”，那“非编制内的员工”，很有可能在日志里或者哪里保存一下。 |
 | 3 ryanking8215 OP |
| 4 ryanking8215 OP sorry, 理解错了。 base64 解码后和标准认证是一样的 |
 | 5 clino 2015-10-30 13:40:27 +08:00 "又是支持 http basic authentication 的" 和 "也就是原始密码有可能会被明文保存，或者对称式加密保存" 没什么逻辑关系吧? 比如说用保存 hash 值的办法,一样可以支持 http basic authentication 啊,每次把 http basic authentication 传来的用户名密码 hash 计算以后和保存下来的 hash 值比较不就能够鉴别用户了 |
 | 6 SoloCompany 2015-10-30 23:23:22 +08:00 「所以为了支持 basic auth, 它要么保存原始密码，要么原始密码进行对称式加密保存」 这理解能力也是醉了，明明是正好相反 |
| 7 ryanking8215 OP @SoloCompany 呵呵，之前脑子抽住了，错误地认为 login form 传的是散列后的密码，其实密码散列计算在 server 端做的，那么 basic auth 也是 ok 的。 |
Select Language