在瀏覽器端進行用戶密碼加密后再傳輸的缺點!

紅薯 發布于 2014/10/20 08:39
閱讀 3K+
收藏 7

從數據到大模型應用,11 月 25 日,杭州源創會,共享開發小技巧

目前 OSC 的登錄可謂是武裝到牙齒,首先是 HTTPS 登錄,其次登錄時在瀏覽器端對密碼進行 SHA1 加密后再傳遞到 OSC 的服務器。也就是說連我們也無法得知你的密碼是什么!

很安全是嗎?但是這樣做有缺點!

這兩天有不少 OSC 的賬號被撞庫,這些賬號被用來發布各種小姐、毒品、詐騙等信息。

我昨晚半夜被同事電話 call 醒的時候再想一個解決辦法:

用戶登錄的時候,我直接在服務器端判斷其密碼是否過于簡單(例如純數字或者純字母),如果過于簡單則強制要求通過 Email 重置密碼。

但是在著手開始寫代碼的時候我發現,尼瑪,我怎么知道用戶的密碼啊,過來是 SHA1 過的哈希值!

擦擦擦!只好作罷?。?!

加載中
3
天天-_-
天天-_-
可以把一些常見的簡單密碼的sha1值放一張表里,用戶在注冊或修改密碼時去匹配一次,如果匹配到了就要求改密碼。當然這增加了成本
黑狗
黑狗
靠譜
苗哥
苗哥
我覺得這個方法靠譜,直接把常見的簡單密碼的加密后的值做成壹個字典,匹配加密后的字符串,如果相同給出提示,強制修改……
0
鈦元素
鈦元素

你的意思是先是在客戶端用js加密,然后到服務器上再進行二次加密?


0
DavidWTF
DavidWTF
可是我看登錄的網頁是http 的呀,中間人直接修改了網頁,后面的措施都是扯淡! @紅薯
0
DavidWTF
DavidWTF
撞庫的問題,我相信你已經加鹽了吧,應該不怕撞。應該是用戶在其它網站使用了相同的帳號密碼。
DavidWTF
DavidWTF
以為是撞hash 后的
DavidWTF
DavidWTF
噢,理解錯了。
紅薯
紅薯
裝酷跟加鹽沒關系,兄弟
0
DavidWTF
DavidWTF
密碼判斷可以在登錄時的網頁中判斷,給后臺發個標志,然后你就能發郵件讓它改密碼了。
0
愛思考的People
愛思考的People
為何不在用戶輸入時進行判斷?
黑狗
黑狗
不從服務端做驗證,都會被有人破戒掉,畢竟代碼用戶是可以看到的,也是可以修改的
0
Arrowing
Arrowing
在前端加密前判斷密碼是否簡單就好啦,然后付個參數傳給后臺
0
Canrz
Canrz
為嘛不先正則判斷下再傳?
0
jininij
jininij
把密碼的復雜度分析寫到前端里?。。?!
0
黑狗
黑狗

前段校驗密碼這種低級手段,對于搞破壞的人來說沒有一點點作用的。

就像現在的網游,只能把所有東西都放到服務器上,才不會被破解掉。不然,你代碼都在別人那里,別人直接改你前端代碼,或者直接發請求道你服務端就ok了

臺階
臺階
不對啊,這本是對正常用戶的善意!
當前問題已關閉評論
OSCHINA
登錄后可查看更多優質內容
返回頂部
頂部
一本久久综合亚洲鲁鲁五月天,无翼乌口工全彩无遮挡H全彩,英语老师解开裙子坐我腿中间