[閒聊] 有沒有憑證都不用檢查的八卦?
看板Soft_Job (軟體人)作者StubbornLin (鍵盤創業家)時間11年前 (2014/09/30 13:50)推噓9(9推 0噓 23→)留言32則, 19人參與討論串1/2 (看更多)
為了怕用市面上的通訊 app 會洩露國家機密,政府好像打算禁用其它通訊軟體
https://www.youtube.com/watch?v=TA5qS8nndr4
除此之外,打算推工研院自己搞的一套 Juiker
號稱資安做得一級棒,身為不務正業的業餘資安人,好奇在網路上找到一份 API 文件,
檔名
"31.Juiker社群通訊服務平台.doc"
看了一下驚為天人,截錄一小段加密方式 http://imgur.com/Vml2psm

"將密文加在Random key後傳送如下"
有沒有好棒棒的政府為了加強資安保密,做出一套好棒棒的系統
產生出來的密鑰是跟密文一起傳送的八卦?金鑰產生的方式就不提了
加密方法用的也是好棒棒被認為已經有問題的 RC4
http://0rz.tw/C2EnG
還有根據官網 https://www.juiker.tw 這套好棒棒好安全的軟體
因為用了 HTTPS 就無敵了,可是 Android client 連憑證都沒驗
http://www.cvedetails.com/cve/CVE-2014-6693/
有沒有這個國家前途無可限量的感覺?
###############
更新:
根據 FB 上有人的回應是,那份 API 是以前某個活動開放給學生使用的而已
並非真正的產品 API
###############
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 76.21.8.197
※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1412056202.A.E04.html
→
09/30 14:00, , 1F
09/30 14:00, 1F
→
09/30 14:00, , 2F
09/30 14:00, 2F
推
09/30 14:54, , 3F
09/30 14:54, 3F
推
09/30 15:42, , 4F
09/30 15:42, 4F
推
09/30 15:52, , 5F
09/30 15:52, 5F
→
09/30 16:17, , 6F
09/30 16:17, 6F
→
09/30 16:52, , 7F
09/30 16:52, 7F
→
09/30 17:08, , 8F
09/30 17:08, 8F
推
09/30 17:43, , 9F
09/30 17:43, 9F
→
09/30 18:12, , 10F
09/30 18:12, 10F
→
09/30 18:15, , 11F
09/30 18:15, 11F
推
09/30 18:49, , 12F
09/30 18:49, 12F
→
09/30 18:50, , 13F
09/30 18:50, 13F
推
09/30 19:04, , 14F
09/30 19:04, 14F
→
09/30 19:06, , 15F
09/30 19:06, 15F
→
09/30 19:52, , 16F
09/30 19:52, 16F
→
09/30 20:03, , 17F
09/30 20:03, 17F
推
09/30 20:13, , 18F
09/30 20:13, 18F
→
09/30 20:13, , 19F
09/30 20:13, 19F
推
09/30 20:50, , 20F
09/30 20:50, 20F
→
09/30 20:54, , 21F
09/30 20:54, 21F
它從頭到尾都沒解釋 fixed key 怎麼來的 只說以 ecivreSpiS 做為 fixed key
也沒見到任何 fixed key 的交換機制 那我就只能解讀為 fixed key
就只是做為擴增密鑰長度的一個手段 沒有任何資訊安全的考量在裡面
(當然這手段也是.... 外行囉 正常都用 key derivation function)
好吧 就算他改用其它的字串當 fixed key 問題出在於沒有安全的交換機制
不是走 HTTPS 就叫安全 因為像它最基本的憑證都沒驗 有走等於沒走
如果 fixed key 是跟著手機 app 和各套軟體一起送出來的
那很簡單 我去看一下軟體裡的 fixed key 是什麼就好了
簡單的邏輯推論 沒有交換機制 也只能真的 fixed
要做到國家可以監聽 也不代表也要做到任何阿貓阿狗攔了就可以輕易解開
推
10/01 00:28, , 22F
10/01 00:28, 22F
→
10/01 02:24, , 23F
10/01 02:24, 23F
→
10/01 02:25, , 24F
10/01 02:25, 24F
→
10/01 02:26, , 25F
10/01 02:26, 25F
→
10/01 02:28, , 26F
10/01 02:28, 26F
開頭都說了是業餘囉 科科 不過呢 各種 protocol 細節如何的千百種
假如有人的專業是設計 smart card authentication protocol
講究的是用最低耗功去做出安全的協定 (幾乎只用 hash和 xor 避開對稱加解密)之類的
不知道所有東西也是很正常 做研究就是這樣 術業有專攻囉
不過這些並不是我的專業 所以我說我是業餘的
上面有更新寫了 他們說這是以前某次活動設計開放給學生用的 API
並非產品本身的 API 既然他們都這麼講 這部份就沒什麼好說的
只是最基本憑證沒驗還是該打屁股
不過我想了想 還是挺奇怪的 既然是做給學生活動玩的一次性 API
那做那套加密又是為什麼呢? 示範技術? 又或著是?
→
10/01 02:55, , 27F
10/01 02:55, 27F
→
10/01 02:55, , 28F
10/01 02:55, 28F
→
10/01 02:57, , 29F
10/01 02:57, 29F
撇開這 API 的用途不看 這加密確實是有問題阿
你自己也說了 它的 key 是 hardcore 的 再加上 random key 跟著密文一起送
所以這有加密等於沒加密 這應該算常識吧?
應該不用當到特級廚師才能評論這加密有問題吧?
當一道菜有毒 認出它是什麼菜很重要嗎? 你說魔女芝琳的鴉片加在麵裡
或加在飯裡 有差別嗎?
好啦 想想 即然是做給學生玩的 讓學生實作加解密也不錯
這部份沒先查清楚 是我的錯
搶鮮大賽 看來就是他們所說的活動的樣子
http://www.getfresh.org.tw/tdp_detail.aspx?No=62
話說 除了 Android 沒驗 Facebook 上也有人提到 desktop 的 app 也有類似問題的樣子
http://0rz.tw/VbmBJ
去研究實際的 API 呼叫應該會比看那份學生用的 API 文件有趣
有興趣的人再研究看看囉
※ 編輯: StubbornLin (199.241.202.154), 10/01/2014 04:19:31
※ 編輯: StubbornLin (199.241.202.154), 10/01/2014 05:16:50
※ 編輯: StubbornLin (199.241.202.154), 10/01/2014 05:17:20
→
10/02 15:25, , 30F
10/02 15:25, 30F
→
10/02 15:34, , 31F
10/02 15:34, 31F
→
10/02 15:34, , 32F
10/02 15:34, 32F
討論串 (同標題文章)
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章