為什麼互聯網產品的「找回密碼」不能把忘記的密碼直接通過郵件發給用戶?
12-29
因為網站也不一定知道你的密碼。因為我們設計資料庫的時候,就不會記錄你的密碼,而是經過演算法處理的密碼。
補充一下,這種加密是不可逆的,也就是不能還原出你輸入的密碼,只能比較你輸入的和你設置的是不是相同。第一,直接發回密碼,意味著系統要保存密碼明文,這是不安全的做法。第二,將密碼直接通過郵件發給用戶,就意味著讓密碼通過不可控的信道存儲到不可控的介質中,這也是不安全的做法。
當初設計找回密碼的時候還真想過這事,而且還做過調研
針對郵箱找回密碼(其他方式例如手機在此不談)主流的方式大概有三種
1、鏈接方式,用戶點郵件內鏈接來找回密碼頁面填表單,輸入新密碼確認後生效2、驗證碼方式,用戶通過郵件獲取一個短時間有效的驗證碼,在修改/找回密碼頁面輸入該碼和新密碼,確認後生效3、發回原密碼,用戶拿原密碼登錄後自行修改密碼根據我們調研的數據來看主流的方式還是1。
分析下來我們覺得2的問題在於郵箱獲取驗證碼遠不如手機方便,同樣基於pc瀏覽器的web服務,鏈接的方式比較無縫,而驗證碼更適用於跨終端的情況(pc同手機),而且用戶還得而且輸入或者複製粘貼驗證碼,操作不如鏈接簡單。另外我們的手機綁定率一直不高。。。。3直接就被拍死了,資料庫里我們只有md5加密後的密碼,所以我們也不知道用戶的密碼是啥。更何況如果發當前密碼,那用戶的郵箱一旦被盜(超多人就一個賬號密碼登錄所有地方),只要用戶不改郵箱,盜號者隨時都可以拿到用戶的最新密碼而不被發現,這尼瑪太可怕了。原理。註冊時的密碼都是以md5加密保存在資料庫的,md5加密是不可逆的,登陸的時候是把你提交的密碼進行md5加密,再與資料庫的加密後密碼進行比較,所以互聯網產品沒法發送原本的密碼到郵箱。好處。一旦被黑客黑了資料庫,也不會造成用戶太大的損失,畢竟黑客不知道原始密碼。如果使用了明文密碼(直接保存未經加密的密碼),就會造成連鎖效應,因為大多數人是在不同的產品里使用同一個賬號、密碼的,一個賬號被盜,就等同於其他產品里的賬號也被盜。如果不幸網銀、支付寶的賬號也是同一個,那就造成經濟損失了。PS: 真實案例,請看多家網站捲入CSDN泄密事件 明文密碼成爭議焦點.
如果他真的把我原來的密碼明文發送回來了,那我就立刻登錄這個網站,清空所有資料,把密碼改為woqunimalegebi250,並從此遠離這個網站。
這個問題有意思。
基本上,現在很多系統對密碼的處理都是把明文進行單向不可逆編碼處理後再保存到資料庫。
從理論上先杜絕了密碼被簡單查表得到明文的風險。
採用這樣處理方式的系統,除非它自己無聊到使用彩虹表做暴力破解(就算做了也未必能百分百破解),否則是無法知道密碼的明文的,所以它沒辦法發密碼給你。想系統發密碼明文到郵箱,除非資料庫中保存的是密碼明文,或者密碼的編碼處理是可逆的。當然,我見過另一種發送明文密碼到郵箱的方式。
在用戶申請密碼找回時,先生成一個若干位的隨機密碼,然後對其做加密編碼保存到資料庫,成功後再把這個新生成的密碼發到用戶郵箱。拋開直接發送明文在其他方面的問題和風險。單說上述方式與目前流行的發驗證鏈接的差別。
最根本的一點就是,上述方式每次申請密碼找回成功後,密碼都會被系統隨機重置成新密碼,申請人必須登錄後才能把密碼修改成自己想要的新密碼。發驗證鏈接的方式,你的密碼在被修改之前還是原來的密碼,點擊鏈接驗證成功後,可以直接輸入想要的新密碼,提交時執行了不登錄就修改密碼的操作。那麼,使用場景對這兩種方式的選擇就很重要了。
----------------------------------
抱歉,後面跑題了。我說的那種方式和問題評論里的有點像。有可能是MD5加密的演算法,這種演算法是不可逆的,只能重新加密組密碼。
我想找回金沙帳號1878573a的密碼
我們這些門外漢之所以會有」找回密碼「的想法,是因為我們的語文水平還算過得去!我們認為」找回密碼「的意思是」找回「丟失的鑰匙。他使用的字眼,讓我真的想知道以前自己用的密碼是啥來著,說不定還能找回一段回憶。然而他們全都讓我把鎖換了!技術上很難實現?讀了你們這些專業人士的解釋, 貌似還真是不好實現。不過好吧,希望那些製作系統密碼重置模塊的人員不要再用那個無恥的字眼了好么!你們的語文應該不是日本人教的吧!你們給腦殘的主管提個創新的建議。就說,咱們甩出的重置密碼鏈接,根本沒有找回用戶現在使用的鑰匙, 卻連鎖芯都換了!應該叫做……
md5加密是不可逆的,難道把Hash發給你有用嗎。
刷個機靈的確有互聯網產品把密碼直接通過郵件發給用戶lz用過招聘系統不
網站一般的密碼都是加密過的,而且加密的演算法應該是不可逆的(例如md5加密),所以,就算是網站的管理員也是不知道你的密碼的。
找回密碼的一般的方式有:1、通過後台生成一個隨機的密碼,在然後再加密,存入資料庫把原來的密碼替換掉,再發密碼發送給用戶。2、確認身份後,例如簡訊驗證、郵箱驗證,重新設置密碼,把密碼提交到伺服器,伺服器程序對密碼進行加密後存入資料庫,替換原來的密碼。這樣子是做就算用戶信息泄露也需要破解密碼才可以使用用戶的帳號來進行登錄。所以如果網站如果可以把密碼發送給你的話,有兩種可能性:1、通過能過對稱加密演算法加密,如果加密的演算法被破解了,那麼,這個網站就挺危險了。2、這個網站是能過明文對密碼進行存儲的,那麼,我覺得你可以效仿一下樓上的答案(至於密碼改成什麼請自行決定,建議委婉一點 ^^ * _ * ^^): 綜上所述,一個好的網站是不能夠把忘記的密碼直接通過郵件發給用戶!這是一個安全性的問題,因為大多數不會保存用戶的明文密碼,也不敢去保存用戶明文密碼。因為一旦遭遇某種原因的泄露也就意味著用戶的賬號與密碼全部公佈於眾或遭到別人獲取。也就說開發者也不知道用戶的明文密碼是什麼,也就無法直接返回給用戶明文密碼。
能夠將明文密碼發給你的網站你要小心了,他存你的明文做什用?
就算是明文存密碼,同樣的密碼,用戶能忘記一次就不會忘記第二次?所以還是讓他改一遍吧。
因為有點安全意思的網站是絕對絕對不會存儲用戶的明文密碼的,用戶註冊輸入密碼之後經過加鹽哈希之後變成一串字元串之後才存儲如資料庫,用戶登錄輸入的密碼經過同樣的演算法進行加鹽哈希之後再對比。所以網站自己也不知道用戶的密碼,也就沒辦法找回原來的密碼。
大體上還是同意排名第一第二的觀點,但是事實上違反常理很多大網站還是存有幾乎所有用戶的明文密碼。比如qq申訴需要的歷史密碼,假設你的歷史密碼是abcde12345,但是你申訴寫的是abced12345同樣有非常高的幾率申訴成功,如果採用加密存放的密碼資料庫是不可能出現這種情況的。那麼這樣做具體的原因是什麼呢?我不想匿,又不想被查水表,就不在這裡明說了,大家自己猜測也可以來單獨交流。。。
資料庫中記錄你的明文密碼,本身就是一個風險,CSDN的倒庫事件就是個赤果果的例子
推薦閱讀:
※如何完整的系統的分析一個網站的交互設計?例如有沒有一些規範的分析表格來進行填寫與收集。
※互聯網行業中交互設計和用戶體驗設計有什麼區別?
※OS X 上很多不夠方便甚至近似 bug 的問題,為什麼蘋果一直不改善?
※「下廚房」為什麼要在博客右上角顯示用戶是從哪裡跳轉(Source)的,這個信息對終端用戶有什麼意義呢?
※使用 PhoneGap 技術的跨平台應用中,在用戶體驗方面做得最好的是哪一款?理由是什麼?