[閒聊] 密碼該不該加密

看板Soft_Job作者 (自立而後立人)時間13年前 (2013/01/19 02:45), 編輯推噓20(20推 0噓 57→)
留言77則, 24人參與, 最新討論串1/2 (看更多)
本日網路圈頗 high 議題 XD https://www.facebook.com/PlainPass/posts/532376003453674 密碼使用不可逆加密、不儲存原碼，可以用幾乎沒感覺的成本， 卻能在網站遭到入侵時相對的降低損失。 是筆者非常推薦的作法。 這不是為什麼要做跟該不該做的問題，而是「為什麼不作」。 -- Life's a struggle but beautiful. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.34.116.11
推
01/19 03:04, , 1F
工程師都夜貓阿 討論這麼熱烈
01/19 03:04, 1F
推
01/19 03:22, , 2F
這根本是釣魚文吧...
01/19 03:22, 2F
→
01/19 03:42, , 3F
網路是很安全的，我用以下五點證明。
01/19 03:42, 3F
→
01/19 03:42, , 4F
1.
01/19 03:42, 4F
→
01/19 03:43, , 5F
2.
01/19 03:43, 5F
推
01/19 03:43, , 6F
吾點
01/19 03:43, 6F
→
01/19 03:43, , 7F
3.
01/19 03:43, 7F
→
01/19 03:43, , 8F
4.
01/19 03:43, 8F
→
01/19 03:43, , 9F
5.
01/19 03:43, 9F
→
01/19 04:53, , 10F
砍文了 QQ
01/19 04:53, 10F
→
01/19 04:54, , 11F
只剩下備份文了 http://goo.gl/bmvml
01/19 04:54, 11F
推
01/19 05:39, , 12F
今天太累太早睡，沒跟到這麼精彩的文章(大哭)
01/19 05:39, 12F
→
01/19 08:04, , 13F
這種十年前的問題, 還在討論, 真是有趣.
01/19 08:04, 13F
→
01/19 08:05, , 14F
SHA1,MD5 早有TABLE 可以查, 這算是路人都知的事.
01/19 08:05, 14F
→
01/19 08:06, , 15F
只是TABLE 多大,就你拿到的囉. 而不管你怎麼HASH
01/19 08:06, 15F
→
01/19 08:06, , 16F
能HACK 進去拿到DB的, 也有不存在意義了.
01/19 08:06, 16F
→
01/19 08:07, , 17F
沒被HACK 進去,只會被SNIFF, 哪麼, REPEAT 不就好了?
01/19 08:07, 17F
推
01/19 08:12, , 18F
密碼加密可還原, 代表db adm隨時可以拿到你的密碼
01/19 08:12, 18F
→
01/19 08:13, , 19F
平常對詐騙就這麼小心, 卻對摸不到的db adm 這麼放心, 真矛盾
01/19 08:13, 19F
→
01/19 08:46, , 20F
驚人的程度= =+
01/19 08:46, 20F
推
01/19 09:44, , 21F
真是奇琶XDDDD
01/19 09:44, 21F
→
01/19 10:06, , 22F
dba 既然知道加密算法, 哪麼改掉你的PW, 拿你的東西
01/19 10:06, 22F
→
01/19 10:07, , 23F
再還回去行不行? 既然知算法, 查MD5 或SHA1 的
01/19 10:07, 23F
→
01/19 10:07, , 24F
的TABLE 還是有機會摸到你的明文.
01/19 10:07, 24F
→
01/19 11:20, , 25F
dba 不用你的密碼也可以直接改你的東西啊 @@
01/19 11:20, 25F
推
01/19 11:33, , 26F
dba要改東西還要你的密碼嗎...
01/19 11:33, 26F
推
01/19 12:15, , 27F
這，奇文共賞啊 XD
01/19 12:15, 27F
→
01/19 12:31, , 28F
我的做法是密碼就是不可逆。但用戶可以申請「臨時密碼」
01/19 12:31, 28F
→
01/19 12:31, , 29F
但是臨時密碼只有限制登入一次。第二次就無法再使用。
01/19 12:31, 29F
→
01/19 12:31, , 30F
申請密碼的用戶必須在可以登入的那一次去改密碼。
01/19 12:31, 30F
→
01/19 12:32, , 31F
但如果是信箱被駭這個我就實在沒輒了。
01/19 12:32, 31F
→
01/19 12:35, , 32F
總不是嚴謹到用戶得傳身份證影本或打電話+EMAIL確認吧！
01/19 12:35, 32F
→
01/19 12:46, , 33F
不管你怎麼做, 作為ROOT的人都可以動手腳. 而user 的
01/19 12:46, 33F
→
01/19 12:46, , 34F
pw 加個md5, sha1 都只是好心而已.
01/19 12:46, 34F
推
01/19 12:46, , 35F
搞錯了吧.... 加密不是為了防dba....
01/19 12:46, 35F
→
01/19 13:23, , 36F
哪叫HASH 不應叫加密, 再說, 真的要有保障的HASH
01/19 13:23, 36F
→
01/19 13:24, , 37F
請改用SHA1-512 或以上.
01/19 13:24, 37F
推
01/19 13:29, , 38F
要認證使用者的方式很多種,用SMS綁手機等等
01/19 13:29, 38F
推
01/19 13:31, , 39F
有夠長的 salt 就不怕 rainbow table 查表
01/19 13:31, 39F
→
01/19 13:33, , 40F
還是改個強一點的算法吧.
01/19 13:33, 40F
推
01/19 13:34, , 41F
重設密碼比較安全的方式應該是
01/19 13:34, 41F
→
01/19 13:35, , 42F
1. 當初註冊填一些重設密碼資訊，忘記密碼就用這資訊重設
01/19 13:35, 42F
→
01/19 13:35, , 43F
2. 經過手機驗證，把OTP用簡訊寄送
01/19 13:35, 43F
→
01/19 13:38, , 44F
rainbow table 和演算法強不強關係不大
01/19 13:38, 44F
→
01/19 13:40, , 45F
要防暴力硬破的話可考慮加上 Key derivation function
01/19 13:40, 45F
→
01/19 14:44, , 46F
MD5是資訊摘要,當初明文既已遺失資訊而取得這個摘要,就不可
01/19 14:44, 46F
→
01/19 14:45, , 47F
從查表從MD5反摸到明文.
01/19 14:45, 47F
→
01/19 14:50, , 48F
當然如果你說有可能摸到某一個字元的值域以及該字元的位置,
01/19 14:50, 48F
→
01/19 14:52, , 49F
只能說如此理想假設,倒不如別說的好.
01/19 14:52, 49F
推
01/19 15:08, , 50F
建表破解的原理是假設使用者使用 n 個字之內包括
01/19 15:08, 50F
→
01/19 15:09, , 51F
那些字元的密碼, 把這些密碼事先算好 hash, 就可以反查
01/19 15:09, 51F
→
01/19 15:11, , 52F
防禦的方法有 salt 和 key stretching 等
01/19 15:11, 52F
→
01/19 15:53, , 53F
MD5 及SHA1 都是弱HASH, 不查表, 也可以給你硬TRY
01/19 15:53, 53F
→
01/19 16:41, , 54F
md5, sha1 有時丟到 google 去就有解的說 xd
01/19 16:41, 54F
推
01/19 16:59, , 55F
SHA1 加上 PBKDF2 / bcrypt 破起來就沒那麼簡單
01/19 16:59, 55F
→
01/19 17:02, , 56F
SHA1 只要有 salt (不能查表) 要硬破其實沒那麼容易
01/19 17:02, 56F
→
01/19 17:02, , 57F
(如果使用者的密碼不是很簡單, 字典檔裡就有的話)
01/19 17:02, 57F
→
01/19 17:05, , 58F
MD5 的確是很弱就是
01/19 17:05, 58F
→
01/19 17:34, , 59F
加SALT 要加夠長的, 但有沒有哪麼不簡單
01/19 17:34, 59F
→
01/19 17:35, , 60F
看你的自然人憑證, 要加長KEY 到256了.
01/19 17:35, 60F
推
01/19 18:16, , 61F
@danielguo: 你自己加一些字典裡沒有的字即可, 這樣就算
01/19 18:16, 61F
→
01/19 18:17, , 62F
是弱密瑪也沒法靠一般的hash表破解了...
01/19 18:17, 62F
→
01/19 18:33, , 63F
hash防硬爆的可能性計算 請參考random oracle
01/19 18:33, 63F
→
01/20 00:13, , 64F
你可以RANDOM 用Oracle,但ideal MODE 的東西就別去想.
01/20 00:13, 64F
推
01/20 01:29, , 65F
discuz的密碼就是用MD5(MD5($password).$salt) 有興趣可以
01/20 01:29, 65F
→
01/20 01:30, , 66F
暴力破解看看 ==
01/20 01:30, 66F
→
01/20 01:31, , 67F
但是每個user的salt都是註冊時亂數取的 XD
01/20 01:31, 67F
→
01/20 01:42, , 68F
不是早就有破解的PHP 了?
01/20 01:42, 68F
推
01/20 03:19, , 69F
@leicheong: 因為如果密碼弱的話, 有salt或其他輔助幫助
01/20 03:19, 69F
→
01/20 03:20, , 70F
也有限. 例如密碼在一個不大的字典檔裡有,攻擊者用同樣
01/20 03:20, 70F
→
01/20 03:22, , 71F
的編碼方式把字典檔對每個 hash+salt 都試一遍不會太久
01/20 03:22, 71F
推
01/20 20:50, , 72F
加了中文字集的單字的字典表有嗎?
01/20 20:50, 72F
→
01/20 20:52, , 73F
這樣除非網站本身的source外洩, 否則會很難破吧...
01/20 20:52, 73F
→
01/21 00:25, , 74F
有些人連雜湊與加密的用途與目的不分，當然無法討論
01/21 00:25, 74F
推
01/22 02:22, , 75F
這樣只能防網站 source/config 沒外洩的情形, 如果
01/22 02:22, 75F
→
01/22 02:24, , 76F
用 salt + key stretching, 就算拿的到兩者也沒法快速破
01/22 02:24, 76F
推
01/22 07:51, , 77F
純推PBKDF2和salt了~____~
01/22 07:51, 77F
‣ 更多 TonyQ 的文章
文章代碼(AID): #1G-PWxLQ (Soft_Job)
‣ 更多 TonyQ 的文章
文章代碼(AID): #1G-PWxLQ (Soft_Job)