使用 TOTP 與 Google Authenticator 實作 Two-Factor authentication

在食衣住行育樂都需要的網路的時候，現代人擁有許多網路帳號，但能記憶的帳號密碼通常只有少數組合，當遇到密碼外洩(e.g.資料庫外洩、病毒側錄密碼)，相對的也影響了使用共同帳密的網路服務，對今日資安事件逐漸從惡作劇變往金融犯罪的趨勢，帳號有操作功能，個資，身份(實名化)，對盜竊者來說帳號密碼可以產生許多價值。

帳號盜用除了個人影響外，間接牽連的還有親友與網路服務提供者，對網路服務提供者而言，帳號盜用是會提高營運成本與降低使用者信賴度的麻煩事，因此面對使用者規模與服務品質，強化帳號安全逐漸成為不可忽視的事情，Google 於去年底開始提供 2-step verification 做多層次的帳號驗證，別於以往硬體 OTP 的方式，透過 Smartphone 使用軟體(i.e Google Authenticator) 來規模化佈署。

目前得知使用類似軟體驗證機制的服務提供者有

• Google Account
• Amazon AWS Account 
• Battle.net  
• Dropbox

在 Server 端的實作驗證流程不難，未來可能會變成一種常見的帳號驗證方法。

以下參考國外部落格文章與 Google Authenticator Android原始碼 實作 Two-Factor authentication 驗證流程，並釋出伺服器端原始碼。

[Java Performance]Chapter 2:Operating System Performance Monitoring

這篇談到如何在作業系統層級搜集數據(CPU、Memory、Network I/O、Disk I/O)，從數據中分析可能的效能問題

名詞定義：

• Performance monitoring： 使用非侵入式的方法從作業系統或應用程式搜集、觀察數據，如使用作業系統提供的工具(e.g. vmstat)搜集效能數據，但不會影響應用程式的行為與效能，這方法適用於大部份的環境(production / development/ testing ...)使用
• Performance profiling： 使用侵入式方法搜集較特定目標數據，如某method的total cpu time/輸入參數，但可能會調整到應用程式行為或者降低效能，這方法比較適用於development/ testing 環境
• Performance tuning： 通常是 monitoring與profiling之後，發覺問題進而修改程式碼 / 設定參數，增進應用程式效能

[Java Performance]Chapter 1:Strategies, Approaches, and Methodologies

在軟體開發流程中該在何時評估效能？

傳統上瀑布式開發(Analysis > Design > Code > Test)會在測試階段進行效能測式，當效能結果不符合要求，調整代價可能很高，因此在擬定需求時就需要將效能指標定義出來，由需求驅動開發過程中各階段的效能測試

• 期望的throughput為多少？

• 期望latency為多少？

• 要能負載多少的 concurrent users 或者 concurrent tasks？

• 在最大數量的 concurrent users 或者 concurrent tasks負載下，可接受的latency 或者throughput為多少？

• 最糟糕狀況下可接受的latency為多少？

• garbage collection 引入的延遲否容許？

假設某些use case可能造成高度的效能風險，那應該在Analysis階段之前製作prototype驗證效能的可行性

Java時間解析度

Inside the Hotspot VM: Clocks, Timers and Scheduling Events - Part I - Windows 說明作業系統在讀取時間與時間event(schedule/trigger)的限制，因此從java api取得的 nanosecond 的數值並不精確，越高的解析度(nanoseconds > microseconds > milliseconds)精確度越低，文中也提供了些使用上的建議。

• 需要讀取精確的時間使用 System.currentTimeMillis()
• 需要比較時間差異使用 System.nanoTime()
• 需要等待系統回應(e.g. wait/sleep)，設定時間別小於10 milliseconds

Memcached vs Redis vs MongoDB vs MySQL 效能比較

"記憶體是新一代的硬碟"在高流量網站內已是稀鬆平常的事情，像是採用 Memcached 做分散式快取服務即是典型的應用模式，Memcached 使用概念簡單且相關應用情境、文件、工具、演算法都已相當成熟，許多知名網站都運用 Memcached 提升scalability，像是GAE、Heroku 等PaaS 環境也有提供 Memcached 的收費服務，這些市場訊息已說明大規模的使用記憶體是可以合乎成本效益的。

Redis 是近年隨著 NoSQL 熱潮出現的 Key-Value store，其功能涵蓋了 Memcached 並且提供許多高階功能，在許多應用情境下相較 Memcached，能降低開發與營運複雜度，比如：

• 豐富的資料結構(strings, hashes, lists, sets and sorted sets) 更易於設計適當的資料粒度增進資料重用的機會，且可依不同的資料結構特性在redis server上做組合與計算，降低開發上的複雜度與資料傳輸
• 永續保存功能可充當簡易的資料庫降低重覆資料的一致性問題或一些特殊應用，像是當系統當機後能快速回復快取資料，避免大量重建的衝擊
• 資料覆寫功能 提升讀取效能，提升 availability
• 2.6版本可以寫script (lua)
• 3.0版本預期還會加上Cluster做HA與Balancing有些data grid的樣子

但效能是否能與 Memcached 匹敵呢？以下透過大量的 get/set 操作做簡單的比較，並且加入MySQL與MonogoDB 做為參考