擔心什么問題

https是加密傳輸?shù)?，所謂的"明文"其實也只有你自己能看到，別人截取你的請求看到的也是加密后的，不過各大平臺在傳輸?shù)臅r候確實是加密的，主要是防止你本地的木馬之類的

這其實本質(zhì)是個信任問題，關鍵在于后端怎么處理密碼。
哪怕你登錄時用不可逆算法加密后再提交，但你輸入賬號和密碼那一刻，仍然是明文存在內(nèi)存中的。如果站點真的要作惡，完全可以在混淆后的 JS 里提前截獲明文，再加密后發(fā)送，外部是沒法察覺的。
難不成你還要對每個站點都去逆向 JS 驗證它有沒有偷偷干這種事？
所以歸根結底就是一句話：如果你不信任這個站，就別用這個站。

糾正你下，用戶名密碼是ssl加密傳輸?shù)?，不是明文傳輸?/p>

系統(tǒng)保證密碼ssl加密傳輸和服務端加密存儲就可以保證密碼不會被泄露，作為一個問答系統(tǒng)這個安全性已經(jīng)足夠了。

至于你瀏覽器是否被黑客控制不是我考慮的事情。如果你瀏覽器被黑客控制，即使我把密碼加密傳輸也沒用，黑客只需要簡單的讀取表單內(nèi)容或者監(jiān)聽鍵盤就可以了，這種情況下在ssl加密的基礎上再加密一次基本上沒有什么意義。

首先，瀏覽器中的使用隨機建議的加強密碼已經(jīng)足夠。
其次，出于信任問題，我相信站長不會在后端儲存明文密碼，業(yè)界普遍會對密碼進行一次哈希或者md5或者sha1.而且甚至會給每個人的密碼加一個字段，隨機鹽，來保證每個人即使密碼相同也會導致生成的密碼不同，給逆向窮舉帶來指數(shù)級難度增長。
我感覺你擔心的不是明文傳輸，而是后端數(shù)據(jù)表的密碼字段是設計吧。我理解你擔心的事情，但是我感覺對這個事情敏感的就不會使用多站同密碼；不敏感的也不會提出這個問題。我認為對于這么一個問答網(wǎng)站沒有問題。

其實我覺得，有疑問不明白發(fā)帖沒問題，但是因為自己不懂就直接蓋棺定論那就不合適了。

你無非就是想加多一套前后端通用的加密而已，你自己實現(xiàn)就是了。本身ssl傳輸就沒啥問題。

應該說得是前端傳遞參數(shù)進行加密, 后端進行解密對數(shù)據(jù)進行對比吧

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

拋開https再客戶端加密再傳輸就能保證安全？這不是掩耳盜鈴嗎？

github登錄也是明文傳輸?shù)?，這么沒看見它出過事呢

這是職業(yè)??？誰正常使用的時候會打開調(diào)試臺看請求的？還是看登陸請求，有你密碼了不用看，沒你密碼看了也沒用。一個論壇還要要求等保了？

你可能對明文傳輸有一定的誤解，實際上即使你使用 阿里云的登錄輸入的密碼也是原內(nèi)容發(fā)送的，有ssl的協(xié)議只要你不安裝三方證書你傳輸過程的內(nèi)容是足夠安全的

就像老板的一個妙想。
老板：小王我最近按了F12，看見表單提交的密碼是明文啊，很不安全。
我：好的老板馬上處理。然后我把密碼再提交的時候用base64使用了5次。
老板：你看這不就好了，雖然我提交了密碼你看誰能看懂。
我：是是。
老板：你的技術不行啊。再這樣降你工資。
我：。。。。。（我心里）你提交密碼只能你自己能看到。別人看到是什么鬼？別人有密碼還需要注意不注意你是明文？你給工資你說的都對。

版主提到的顧慮，用動態(tài)驗證碼登錄（郵箱、手機接收動態(tài)驗證碼）就可解決其顧慮，這樣雙方都無需長久存儲密碼；無需用前端腳本對密碼進行加密。另外最為用戶而言：我會用一站一隨機字符密碼來登錄的。

受不了了，我要注冊一個賬號，給樓主梳理一下，小屁孩吧，學點破爛知識，上個19800的輔導班，看一點培訓機構的講師視頻，就覺得自己發(fā)現(xiàn)了人家都沒有發(fā)現(xiàn)的bug？webman論壇全站開發(fā)者都沒發(fā)現(xiàn)的bug被你發(fā)現(xiàn)了，webman作者寫框架的，人家技術水平不在你之上，你能考慮到的東西人家考慮不到？還是說找不到工作，硬在論壇沒BUG硬提，到時候面試的時候給HR扔一個：我再XXX網(wǎng)站提交了一個BUG（看！顯得我多細心）

好，罵完了，講事情，我從來是對事不對人，非要別人對個人才老實，賤不賤啊？

樓主觀點無非就是：覺得密碼明文傳輸不安全，希望客戶端加密一層，最好還是不可逆加密；

樓中樓有些人提到了https，人家不是沒看懂你說話，人家是聊天跟你不在一個高度上，這是后端社區(qū)，不是前端社區(qū)，連TCP握幾次手，握了個啥都搞不明白的，tcp/udp/http/ftp 一群 p 結尾都沒搞明白的，就在這里了放p，就會開個迅雷下片，連thrunder:// 學名叫啥都不知道，在這里 p p p 的；

首先，把2個場景結束掉；

1、第一種：不是 https 問題，那就不存在中間人攔截，不裝第三方抓包證書的話，攔截就是加密內(nèi)容，行，你自己犯賤非要裝個第三方證書，說明文傳輸，那是你自己犯賤，自己犯賤不在我們討論范圍之內(nèi)；你自己跪在地上把家里大門給小偷說歐巴擦啦嘿呦偷我家快偷不偷我干死你 :)

2、第二種：客戶端F12調(diào)試，首先，這個場景就不是正常人的適用范圍，退一萬步說哦，前端入門容易，確實，是個人都能按F12打開瀏覽器調(diào)試看網(wǎng)絡請求，但你是不是忘了一點，明文傳輸這一瞬間，是你自己電腦發(fā)出的，人家想要在你客戶端偷看你密碼，需要站在你背后，拿刀架在你脖子上，逼著你按下F12，讓后他盯著屏幕右側控制臺，讓你切換到網(wǎng)絡，然后選中登錄請求，然后看表單內(nèi)容。那有沒有一種可能性，你就不會以迅雷不及掩耳之勢按下alt+f4關閉瀏覽器？咋了？平時召喚師峽谷鍵盤俠的手速，到這里都殘廢了？凹，假設不是匪徒拿刀子架在你脖子上不讓你關閉瀏覽器，譬如你自己正好在登陸一瞬間，屎意來了，你走了，唉呀媽呀，天時地利人和，就差明著讓別人偷看你密碼了？這難道不是人的問題？這是軟件問題？還是說你的邏輯方式就是這就是人的問題？

好！這兩個場景結束，我們來說樓主的「workerman 官網(wǎng)登錄的時候，密碼是明文直接向后臺發(fā)送的，這不太讓人放心，請大佬改下，客戶端先不可逆加密處理一下再發(fā)送到后端」

我來標注下重點：密碼 明文傳輸 希望 客戶端 不可逆加密

沒問題吧？行，首先，你這 不可逆加密 就是 悖論？啥？不懂啥意思？我舉個例子

PS. 插個題外話，只要這個后端不是腦子有大泡，后端入庫密碼肯定是加密的，不管md4 還是 hash，不可能說你客戶端傳輸 123456 服務端入庫就是 123456，后端沒這么缺心眼，覺得別人缺心眼之前，先看看自己是不是樂子人

場景1：客戶端可逆加密，服務端解密，譬如：AES

• 流程：客戶端（123456）→ AES加密一下（xxxoooxxx）→ https 傳輸中（不可解密）→ 服務端接受（xxxoooxxx）→ 服務端解密（123456）→ 業(yè)務邏輯
• 首先：這個流程，AES加密，肯定秘鑰就在客戶端的，所以，脫褲子放屁，君子不用防，小人防不?。?/li>

場景2：客戶端不可逆加密，服務端接受，譬如：MD5

• 流程：客戶端（123456）→ MD5一下（e10adc3949ba59abbe56e057f20f883e) → https 傳輸中（不可解密）→ 服務端接受（e10adc3949ba59abbe56e057f20f883e）→ 業(yè)務邏輯

• 悖論：首先，這就是個悖論，為什么，任何主流不可逆加密算法，都是公開函數(shù)，比如：md5，不公開的，你源碼都在客戶端，人家真要調(diào)試，照樣調(diào)試的出，退這一步不說。那如果假設客戶端我密碼就是“e10adc3949ba59abbe56e057f20f883e”怎么辦呢？

• 流程復盤：客戶端（e10adc3949ba59abbe56e057f20f883e）→ MD5一下（14e1b600b1fd579f47433b88e8d85291）→ https 傳輸中（不可解密）→ 服務端接受（14e1b600b1fd579f47433b88e8d85291）→ 業(yè)務邏輯

• 復盤分析：那好， 現(xiàn)在請問，你給服務端發(fā)送 123456 和 e10adc3949ba59abbe56e057f20f883e 在這個場景下，什么實質(zhì)性區(qū)別？凹，你假裝自己密碼是md5，假裝黑客看不出來？硬偽裝成 32位 字母+數(shù)組？你是當別人傻缺還是你在抖機靈呢？

總結：還是前文所言：1、客戶端不可逆加密對服務端沒意義，不可逆的字符服務端接受，等于沒加密（繞不明白這個邏輯的從埃菲爾鐵塔跳下去得了）；2、客戶端可逆加密，有一定意義，但意義了寂寞，還是那句話，防君子不防小人；3、客戶端不加密嗎，使用 https 協(xié)議，傳輸過程中加密，這是主流做法，不要挑戰(zhàn)主流你不配

PS. 你自己非要在抓包證書 或 開著控制臺給別人看 或者 你自己電腦自己都管不好的 這是人的問題 不是軟件問題

@walkor 這貼關了吧