活動網站：
http://csim.tca.org.tw/
http://www.ares.com.tw/pki_pk2009/a.php
1. 報名日期：98年10月1日(四)至11月19日(四) 下午六點截止
2. 初賽日期：98年11月23日(一)至11月27日(五)
3. 決賽日期：98年12月5日(六)
4. 競賽地點：台灣大學綜合體育館（台北市羅斯福路四段一號）
別忘了還有這個活動啊XD
---
報名還要錄製VCD，且邊操作邊說明，所以這系統一定要在期限內完成啊。
2009/10/11
2009/10/04
One-Time Password
沒想像中的那麼容易，為了簡化文章，我直接將運作流程列出來：
這是正統的 RFC2289 一次性密碼系統的流程，很明顯在我們的系統用這種東西根本不對。
因為教授說用預先定義好的內容作數位簽章，很容易被中間人攻擊，所以希望這個內容能夠隨機產生，最好是一次性的，這樣中間人攔截內容要重送時已經失效了。
不過正規的OTP系統，是寫死的流程，跟我們單純要求的隨機內容有點差距。所以又只能自己動手了。
因為我們要求的隨機密碼不會有讓使用者手動輸入的機會，得到後就立刻數位簽章送給伺服器認證，不必擔心太過複雜難以輸入的問題。我的想法是這樣的：
登入系統向伺服器要求(https)一次性隨機密碼
↓
伺服器回傳(https)，同時紀錄於 Session 內
↓
登入系統收到密碼，簽章傳送給伺服器(https)
↓
伺服器拿出使用者憑證跟 Session 紀錄的一次性隨機密碼，進行驗證。不論成功與否皆清除 Session 密碼
原先教授的疑慮是這樣的：當我用固定的內容(如: 「超爽的，撿到一百塊咧」或者是當天日期)，系統送出給伺服器的過程中假如被攔截(假設 https 還會被攔截解密的話啦...)，中間人可以進行重送攻擊 (因為簽章驗證會通過，驗證是驗證資料不是送的人)。如果是固定文字，那此攻擊可以不限時間成功；當天日期的話，當天重送攻擊都有效。所以教授才會說要將內容加到分鐘，甚至是秒，以避免這種攻擊。
改成隨機內容的話，由於使用者要登入都得先向伺服器要求產生一次性隨機密碼，這個密碼萬一真被中間人竊取成功，中間人並沒有私鑰可以進行簽章，所以攻擊失敗。要是在送出簽章的時候攔截實施重送攻擊，一來中間人並沒有要求伺服器發給一次性密碼，伺服器也就沒有用Session儲存，在進行檢查的時候就沒有東西可以用，而紀錄警告；二來這個一次性隨機密碼已經在剛才的正規使用者登入時，就已失效，所以還是沒有用。
如果中間人夠厲害，一次性隨機密碼、數位簽章都取得，再加上入侵伺服器將 Session 改成一次性隨機密碼，那就有機會。但是這需要攻擊 HTTPS, 伺服器，自有難度。Session 變造內容的攻擊法還沒有聽說過，因為 Session 存在伺服器除非入侵不然改不到。只有 Session ID 攻擊 (參見: Session Hijacking 攻擊與Cookie 欺騙(4/5) - 網路攻防戰)：利用 Session ID 綁 Cookie 的設計，竊取正規使用者 Cookie，把自己的 Cookie 改的跟正規者一樣，Session ID自然一樣，對應的 Session 正是合法使用者的。
解決方式是每次要求就改變 Session ID，PHP 有函式 session_regenerate_id() 可以避免這種問題。
結論：根基於 HTTPS、一次性隨機密碼、數位簽章、Session 跟每次改變 Session ID的方式，讓中間人的破解難度增加，我想可以達到安全。
- 先在「安全環境」(如你家電腦)設定產生OTP的各項參數: 密碼, Seed, 演算法, Count/Seq.，產生OTP密碼表格
- 到「非安全環境」(如網咖、學校)登入時，系統會要求你查找密碼表格的某一個密碼(例如第49個)
- 以查表法查出正確密碼，輸入後登入。如果不想查表，可以用 OTPGen/Mobile-OTP 等 Java程式，給予當初初始化的參數，算出表格再查表輸入
這是正統的 RFC2289 一次性密碼系統的流程，很明顯在我們的系統用這種東西根本不對。
因為教授說用預先定義好的內容作數位簽章，很容易被中間人攻擊，所以希望這個內容能夠隨機產生，最好是一次性的，這樣中間人攔截內容要重送時已經失效了。
不過正規的OTP系統，是寫死的流程，跟我們單純要求的隨機內容有點差距。所以又只能自己動手了。
因為我們要求的隨機密碼不會有讓使用者手動輸入的機會，得到後就立刻數位簽章送給伺服器認證，不必擔心太過複雜難以輸入的問題。我的想法是這樣的：
登入系統向伺服器要求(https)一次性隨機密碼
↓
伺服器回傳(https)，同時紀錄於 Session 內
↓
登入系統收到密碼，簽章傳送給伺服器(https)
↓
伺服器拿出使用者憑證跟 Session 紀錄的一次性隨機密碼，進行驗證。不論成功與否皆清除 Session 密碼
原先教授的疑慮是這樣的：當我用固定的內容(如: 「超爽的，撿到一百塊咧」或者是當天日期)，系統送出給伺服器的過程中假如被攔截(假設 https 還會被攔截解密的話啦...)，中間人可以進行重送攻擊 (因為簽章驗證會通過，驗證是驗證資料不是送的人)。如果是固定文字，那此攻擊可以不限時間成功；當天日期的話，當天重送攻擊都有效。所以教授才會說要將內容加到分鐘，甚至是秒，以避免這種攻擊。
改成隨機內容的話，由於使用者要登入都得先向伺服器要求產生一次性隨機密碼，這個密碼萬一真被中間人竊取成功，中間人並沒有私鑰可以進行簽章，所以攻擊失敗。要是在送出簽章的時候攔截實施重送攻擊，一來中間人並沒有要求伺服器發給一次性密碼，伺服器也就沒有用Session儲存，在進行檢查的時候就沒有東西可以用，而紀錄警告；二來這個一次性隨機密碼已經在剛才的正規使用者登入時，就已失效，所以還是沒有用。
如果中間人夠厲害，一次性隨機密碼、數位簽章都取得，再加上入侵伺服器將 Session 改成一次性隨機密碼，那就有機會。但是這需要攻擊 HTTPS, 伺服器，自有難度。Session 變造內容的攻擊法還沒有聽說過，因為 Session 存在伺服器除非入侵不然改不到。只有 Session ID 攻擊 (參見: Session Hijacking 攻擊與Cookie 欺騙(4/5) - 網路攻防戰)：利用 Session ID 綁 Cookie 的設計，竊取正規使用者 Cookie，把自己的 Cookie 改的跟正規者一樣，Session ID自然一樣，對應的 Session 正是合法使用者的。
解決方式是每次要求就改變 Session ID，PHP 有函式 session_regenerate_id() 可以避免這種問題。
結論：根基於 HTTPS、一次性隨機密碼、數位簽章、Session 跟每次改變 Session ID的方式，讓中間人的破解難度增加，我想可以達到安全。
訂閱：
文章 (Atom)