担心什么问题

https是加密传输的，所谓的"明文"其实也只有你自己能看到，别人截取你的请求看到的也是加密后的，不过各大平台在传输的时候确实是加密的，主要是防止你本地的木马之类的

这其实本质是个信任问题，关键在于后端怎么处理密码。
哪怕你登录时用不可逆算法加密后再提交，但你输入账号和密码那一刻，仍然是明文存在内存中的。如果站点真的要作恶，完全可以在混淆后的 JS 里提前截获明文，再加密后发送，外部是没法察觉的。
难不成你还要对每个站点都去逆向 JS 验证它有没有偷偷干这种事？
所以归根结底就是一句话：如果你不信任这个站，就别用这个站。

纠正你下，用户名密码是ssl加密传输的，不是明文传输。

系统保证密码ssl加密传输和服务端加密存储就可以保证密码不会被泄露，作为一个问答系统这个安全性已经足够了。

至于你浏览器是否被黑客控制不是我考虑的事情。如果你浏览器被黑客控制，即使我把密码加密传输也没用，黑客只需要简单的读取表单内容或者监听键盘就可以了，这种情况下在ssl加密的基础上再加密一次基本上没有什么意义。

首先，浏览器中的使用随机建议的加强密码已经足够。
其次，出于信任问题，我相信站长不会在后端储存明文密码，业界普遍会对密码进行一次哈希或者md5或者sha1.而且甚至会给每个人的密码加一个字段，随机盐，来保证每个人即使密码相同也会导致生成的密码不同，给逆向穷举带来指数级难度增长。
我感觉你担心的不是明文传输，而是后端数据表的密码字段是设计吧。我理解你担心的事情，但是我感觉对这个事情敏感的就不会使用多站同密码；不敏感的也不会提出这个问题。我认为对于这么一个问答网站没有问题。

其实我觉得，有疑问不明白发帖没问题，但是因为自己不懂就直接盖棺定论那就不合适了。

你无非就是想加多一套前后端通用的加密而已，你自己实现就是了。本身ssl传输就没啥问题。

应该说得是前端传递参数进行加密, 后端进行解密对数据进行对比吧

哈哈，笑死我了。
请先了解一下https

抛开https再客户端加密再传输就能保证安全？这不是掩耳盗铃吗？

github登录也是明文传输的，这么没看见它出过事呢

这是职业病？谁正常使用的时候会打开调试台看请求的？还是看登陆请求，有你密码了不用看，没你密码看了也没用。一个论坛还要要求等保了？

你可能对明文传输有一定的误解，实际上即使你使用 阿里云的登录输入的密码也是原内容发送的，有ssl的协议只要你不安装三方证书你传输过程的内容是足够安全的

就像老板的一个妙想。
老板：小王我最近按了F12，看见表单提交的密码是明文啊，很不安全。
我：好的老板马上处理。然后我把密码再提交的时候用base64使用了5次。
老板：你看这不就好了，虽然我提交了密码你看谁能看懂。
我：是是。
老板：你的技术不行啊。再这样降你工资。
我：。。。。。（我心里）你提交密码只能你自己能看到。别人看到是什么鬼？别人有密码还需要注意不注意你是明文？你给工资你说的都对。

版主提到的顾虑，用动态验证码登录（邮箱、手机接收动态验证码）就可解决其顾虑，这样双方都无需长久存储密码；无需用前端脚本对密码进行加密。另外最为用户而言：我会用一站一随机字符密码来登录的。

受不了了，我要注册一个账号，给楼主梳理一下，小屁孩吧，学点破烂知识，上个19800的辅导班，看一点培训机构的讲师视频，就觉得自己发现了人家都没有发现的bug？webman论坛全站开发者都没发现的bug被你发现了，webman作者写框架的，人家技术水平不在你之上，你能考虑到的东西人家考虑不到？还是说找不到工作，硬在论坛没BUG硬提，到时候面试的时候给HR扔一个：我再XXX网站提交了一个BUG（看！显得我多细心）

好，骂完了，讲事情，我从来是对事不对人，非要别人对个人才老实，贱不贱啊？

楼主观点无非就是：觉得密码明文传输不安全，希望客户端加密一层，最好还是不可逆加密；

楼中楼有些人提到了https，人家不是没看懂你说话，人家是聊天跟你不在一个高度上，这是后端社区，不是前端社区，连TCP握几次手，握了个啥都搞不明白的，tcp/udp/http/ftp 一群 p 结尾都没搞明白的，就在这里了放p，就会开个迅雷下片，连thrunder:// 学名叫啥都不知道，在这里 p p p 的；

首先，把2个场景结束掉；

1、第一种：不是 https 问题，那就不存在中间人拦截，不装第三方抓包证书的话，拦截就是加密内容，行，你自己犯贱非要装个第三方证书，说明文传输，那是你自己犯贱，自己犯贱不在我们讨论范围之内；你自己跪在地上把家里大门给小偷说欧巴擦啦嘿呦偷我家快偷不偷我干死你 :)

2、第二种：客户端F12调试，首先，这个场景就不是正常人的适用范围，退一万步说哦，前端入门容易，确实，是个人都能按F12打开浏览器调试看网络请求，但你是不是忘了一点，明文传输这一瞬间，是你自己电脑发出的，人家想要在你客户端偷看你密码，需要站在你背后，拿刀架在你脖子上，逼着你按下F12，让后他盯着屏幕右侧控制台，让你切换到网络，然后选中登录请求，然后看表单内容。那有没有一种可能性，你就不会以迅雷不及掩耳之势按下alt+f4关闭浏览器？咋了？平时召唤师峡谷键盘侠的手速，到这里都残废了？凹，假设不是匪徒拿刀子架在你脖子上不让你关闭浏览器，譬如你自己正好在登陆一瞬间，屎意来了，你走了，唉呀妈呀，天时地利人和，就差明着让别人偷看你密码了？这难道不是人的问题？这是软件问题？还是说你的逻辑方式就是这就是人的问题？

好！这两个场景结束，我们来说楼主的「workerman 官网登录的时候，密码是明文直接向后台发送的，这不太让人放心，请大佬改下，客户端先不可逆加密处理一下再发送到后端」

我来标注下重点：密码 明文传输 希望 客户端 不可逆加密

没问题吧？行，首先，你这 不可逆加密 就是 悖论？啥？不懂啥意思？我举个例子

PS. 插个题外话，只要这个后端不是脑子有大泡，后端入库密码肯定是加密的，不管md4 还是 hash，不可能说你客户端传输 123456 服务端入库就是 123456，后端没这么缺心眼，觉得别人缺心眼之前，先看看自己是不是乐子人

场景1：客户端可逆加密，服务端解密，譬如：AES

• 流程：客户端（123456）→ AES加密一下（xxxoooxxx）→ https 传输中（不可解密）→ 服务端接受（xxxoooxxx）→ 服务端解密（123456）→ 业务逻辑
• 首先：这个流程，AES加密，肯定秘钥就在客户端的，所以，脱裤子放屁，君子不用防，小人防不住；

场景2：客户端不可逆加密，服务端接受，譬如：MD5

• 流程：客户端（123456）→ MD5一下（e10adc3949ba59abbe56e057f20f883e) → https 传输中（不可解密）→ 服务端接受（e10adc3949ba59abbe56e057f20f883e）→ 业务逻辑

• 悖论：首先，这就是个悖论，为什么，任何主流不可逆加密算法，都是公开函数，比如：md5，不公开的，你源码都在客户端，人家真要调试，照样调试的出，退这一步不说。那如果假设客户端我密码就是“e10adc3949ba59abbe56e057f20f883e”怎么办呢？

• 流程复盘：客户端（e10adc3949ba59abbe56e057f20f883e）→ MD5一下（14e1b600b1fd579f47433b88e8d85291）→ https 传输中（不可解密）→ 服务端接受（14e1b600b1fd579f47433b88e8d85291）→ 业务逻辑

• 复盘分析：那好， 现在请问，你给服务端发送 123456 和 e10adc3949ba59abbe56e057f20f883e 在这个场景下，什么实质性区别？凹，你假装自己密码是md5，假装黑客看不出来？硬伪装成 32位 字母+数组？你是当别人傻缺还是你在抖机灵呢？

总结：还是前文所言：1、客户端不可逆加密对服务端没意义，不可逆的字符服务端接受，等于没加密（绕不明白这个逻辑的从埃菲尔铁塔跳下去得了）；2、客户端可逆加密，有一定意义，但意义了寂寞，还是那句话，防君子不防小人；3、客户端不加密吗，使用 https 协议，传输过程中加密，这是主流做法，不要挑战主流你不配

PS. 你自己非要在抓包证书 或 开着控制台给别人看 或者 你自己电脑自己都管不好的 这是人的问题 不是软件问题

@walkor 这贴关了吧