一个发现,豆瓣 web 端账号密码明文写在 url 里

我记得豆瓣登陆，还是要手机号+短信，这造成账号密码明文影响不大。从技术、安全角度讲，确实不该明文。

自从强制要求验证手机号，就没登录过了。

https ，域名之后的所有东西，包括 path 和 GET/POST 数据，一出浏览器就已经加密了吧，代理抓包都看不到（中间人攻击另说）。它这个是 GET ，实际上你看下 Google 之类大网站的方式，也是账号密码明文放在 POST 里面。
安全性应当依赖 TLS ，除此之外的加密没什么意义，顶多搞一层加盐哈希。

应该用 post 方法

用 GET 的缺点是会留在浏览器历史记录里，在 Windows 这种没有应用沙箱机制的系统上，会被流氓软件扫盘读到。但这和网络传输安全性就没关系了。
只从网络安全角度，GET 和 POST 安全性没有区别，唯一重要的是 https 。

一般都是 md5 之后再进行服务端验证, 但是如楼上所说, 反正 https 都加密了, 这层 hash 有没有都差不多

有 TLS 对于任意第三方是安全的
但用 GET 在实践上会有点问题，比如明文密码会留存在各种访问日志中

没加盐？

无问题

逻辑是这样的，如果你的电脑都已经被第三方掌控，那一切安全措施都没有太大意义了。

用 GET 比较离谱

没加盐的话，是不是所有能访问到日志的豆瓣开发人员都能知道用户的账号密码？

@iCyMind 日志关于密码这一项，一般都会在打日志的时候进行加密

吓得我赶紧改密码，要是豆瓣被脱裤了的话，我的其他平台密码都一样就完蛋

还有 google analysis 之类的工具，也会保存 url 的吧？

@1156909789 存储肯定是加密处理的，只是传输的时候说明文的，不过有 TLS ，问题不大

唉，看错，原来是登录接口呀

@halberd #3 涨芝士了，一直以为 url 后面的都不会被加密，之前抓包的也没留意这个问题，又去看了一遍科普文章。

理论上有 HTTPS ，明文密码问题不大。但是实际上这扩大了被攻击面：

大型网站总有修不完的 XSS ，用户电脑被人攻击了之后一个 history API 就可以拿到密码；
客户端到 CDN 一般是 HTTPS ，但 CDN 到源站可能还是 HTTP ，被运营商里的蛀虫抓包可能就会被批量卖信息；
链路上的每层反向代理有任一一环忘了日志敏感信息加密；

冷知识，HTTPS 协议 URL 部分会加密的，跟放在 post body 中没有区别。

虽然但是，这个是登录接口 post-xhr 调用，只不过把参数放在 url 上

另外就算是 get 只要类型是 xhr/fetch ，就不会产生浏览器历史记录

会产生浏览器历史记录的是以前那种 sso 重定向登录系统

不能说完全没问题。只能说大致可以认为是安全的。因为攻击面比较小。
唯一剩下的一种攻击方式就是中间人了。很多可以代理但能看到 https 的工具就是基于这个原理，有些公司的网络监控也差不多这个意思。
颁发一个证书，让你信任。然后你发的他能解，然后代理出去。回来后他发的你也能解。