November 2006 – Gea-Suan Lin's BLOG

RMS 對於 GPLv3、Novell/MS、Tivo 的談話

在 RMS transcript on GPLv3, Novell/MS, Tivo and more 看到 RMS 在 5th international GPLv3 conference 上對標題上的那些東西的談話，晚點來看：Transcript of Richard Stallman at the 5th international GPLv3 conference; 21st November 2006。

Google 停車場

在 Google Parking Lot 看到的圖：

我喜歡那張 GNU CAR... :p

Two-factor authentication

工具要正確的被使用才有效果。

傳統只輸入密碼的方式有時被稱做 One-factor authentication，因為 Two-factor authentication 是指兩種以上的認證，通常是透過 USB 外接 Smart card 讀卡機用卡片另外做認證。

美國網路銀行將身份檢查的部分改用 Two-factor authentication 進行認證，希望可以對抗 Phishing (網路釣魚)。問題這樣還是會受到 Man-in-the-middle-attack 與 Trojan (木馬) 的攻擊。

以 Smart card 作為 Two-factor authentication 的架構來說，Man-in-the-middle-attack 攻擊是在使用者瀏覽釣魚頁面時去原來的網路銀行上抓 Two-factor authentication 所需要的 Message，傳給使用者後讓使用者認證。使用者認證完 (密碼以及 Smart card 對 Message 的數位簽名) 送回釣魚頁面，釣魚頁面再送回原來銀行網頁，完成認證的動作，接下來開始把錢轉帳到其他戶頭去。這也就是 Bruce Schneier 這篇 Fighting Fraudulent Transactions 提到美國銀行以及政府所使用的 Two-factor authentication 無法保護使用者。

但這並不是 Two-factor authentication 有問題，而是因為把 Two-factor authentication 用在錯的地方上。台灣的網路銀行在這點上面做的 Two-factor authentication 就是正確的方式。

以「轉帳」為例，你必須有一台 Smart card 讀卡機，由銀行產生 Message (在裡面會包括要轉出的戶頭，以及轉入的戶頭，金額，以及一個流水號)，讓晶片卡去這個 Message，然後傳回網路銀行驗證。

重點在於 Two-factor authentication 必須用在每個交易動作上，而不是只用在一開始的認證：

The solution is not to better authenticate the person, but to authenticate the transaction. (Think credit cards. No one checks your signature. They really don't care if you're you. They maintain security by authenticating the transactions.)
(解決的方法並不是尋找更好的方法「驗證使用者」，而是「驗證交易本身」。想想信用卡怎麼做的，沒有人會檢查你的簽名，他們根本不在乎是你本人，因為他們是透過信用卡對每一項交易動作進行認證，以維護安全。)

附上 d2.gv，上圖是用 dot -Tpng -o d2.png d2.gv 產生出來的：

digraph G {
    "D2 E-mail System"->{"Users" "Department"};
    "Users"->"Basic Data";
    "Users"->"Student Number";
    "Users"->"Student Department"->"Department";
    "Users"->"Username";
    "Users"->"Password";
    "Users"->"Forwarding E-mail";
    "Users"->"Quota";
    "Users"->"Creation Date";
    "Users"->"Creation IP";
    "Users"->"Last Login Date";
    "Users"->"Last Login IP";
    "Basic Data"->"ID";
    "Basic Data"->"Real Name";
    "Basic Data"->"Permanent Address";
    "Basic Data"->"Permanent Telephone";
    "Basic Data"->"Contact Address";
    "Basic Data"->"Contact Telephone";
    "Basic Data"->"Mobile Telephone";
    "Department"->"Number";
    "Department"->"Abbr";
    "Department"->"Description";
}