• 密碼的儲存用哪一種演算法?

    Image result for password encryption

    您選對了嗎? 密碼儲存的演算法, MD5, SHA, PBKDF2, BCrypt

    這邊文章主要說明密碼的儲存要用哪一種加密演算法儲存?

    各種演算法的優缺點? 業界與相關標準的建議

    MD5

    這是目前業界算是禁止使用的演算法

    優點是快速 , 但是卻很快就會被破解, 只有128bit

    除此之外, 該演算法很容易產生  collision

    也就是說計算出來的 Hash值有可能重複

    密碼 Hash的儲存通常會加上一個隨機數 (Salt)的方式當作參數

    Hash = (password, 隨機數 Salt)

    這樣一來, 駭客才無法用字典檔案產生一組 Hash來猜出原始密碼

    SHA

    SHA1 也被認定為弱演算法, 因此業界普遍使用SHA256

    • SHA-1 (Simplest one – 160 bits Hash)
    • SHA-256 (Stronger than SHA-1 – 256 bits Hash)
    • SHA-384 (Stronger than SHA-256 – 384 bits Hash)
    • SHA-512 (Stronger than SHA-384 – 512 bits Hash)

    但是密碼儲存我們也通常不會使用 SHA的方式

    密碼的儲存主要使用的演算法是 PBKDF2, BCrypt, Script

    PBKDF2, BCrypt , Scrypt的出現

    這三個是目前業界普遍使用來儲存密碼的 Hash演算法

    PBKDF2, BCrypt, Script有一個共通的特色,

    就是讓電腦執行速度變得很慢

    因此, 這樣的演算法有助於防止暴力破解

    哪一個演算法比較推薦呢?

    由於美國 NIST 與FIPS標準推薦使用 PBKDF2

    因此, 也讓 PBKDF2 更為有公信力

    倒不是因為其他兩個演算法比較弱或是有被找到漏洞

    所以如果您的密碼儲存演算法不是這三個其中之一的話

    要好好跟開發團隊討論討論囉.

    演算法比較

     

    相關標準: PBKDF2

     

    參考

     

     

  • Web API 如何做身份認證?

    Image result for API Key

    這篇文章主要討論當用程式與後端web服務溝通時

    這樣的程式 API 呼叫如何做認證?

    我們知道當使用者瀏覽網頁的時候, 有相關登入認證的機制

    但是對於程式 API呼叫並沒有使用者輸入帳號密碼的機制來判斷身分

    因此, Web API 要如何做身分來源認證呢?

     

    API Keys

    API Key就是API程式呼叫主要用來做身分認證的一種方式.

    但是後端服務如何從API Key得知該使用者是誰呢?

    這就必須讓使用者先有一個註冊的過程

    註冊完之後, 就會產生一組相對應的API key

    因此, 該使用者就可以利用這個 API Key 用程式進行呼叫使用後端服務

    API Key 的叫法有很多, APP Key, Consumer Key , Public Access Key 等

    這些名詞都是同樣的用意, 都是用來判斷該API呼叫的來源

     

    註冊取得 API Key

    當使用者或是開發者與後端服務註冊時, 會得到一組 API Keys

    開發者就可以用這組 API Keys 在之後調用或是呼叫 API  時候一起傳送

    API 呼叫中所帶的 API Key傳送到後端,

    後端就會根據該 API Key 的有效性進行身分認證

    由於 API Key 如果被盜取, 其

    實很容易造成第三方冒名的方式透過API呼叫

    因此使用者或是開發商對於 API Key 的保存的安全性

    就像保存帳號密碼一樣的重要

    因為 API Key 就相當於帳號密碼, 用來做身分確認

    因此, 對於後端服務來說, 定期更換 API Key  也是一種安全防護的機制

    API Key 驗證

    API Key 在檢查的時候, 會有哪些狀況呢?

    • API Key 的參數遺失或是沒有傳送
    • API Key的值格式非法不正確
    • API Key 格式正確, 但是未被啟動, 或是已經被註銷
    • API Key 不適用在特定服務資源的調用

     

    這些錯誤處理也是後端服務對於 API Key基本防護之道

    因為 API Key 就像是帳號密碼一樣

    因此在 API 可以呼叫請求之前,

    必須對 API Key的身分認證與合法性加以檢查

     

     

  • 世界頂尖專業的幾個工作思維

    Image result for top professions

    這篇文章主要說明如何在自己的專業領域上達到世界標竿的幾個方式

    將目標設定在達到業界標竿, 最後儘管不是業界第一但是至少會達到前三

    或是知道落差在哪裡? 未來前進的方向為何?

    工作不僅僅追求老闆交付的工作, 還要期許自己的專業朝向世界標竿前進

    那麼如何對標世界標竿呢? 如何學習呢? 這邊提供幾個方法

    廣泛閱讀相關書籍

    Image result for books

    每個特定專業的主題, 相信都會有類似或是相同主題的探討

    很少是世界你第一個人想到這主題

    即時是也是有些前人的心得, 你了解到而有新的做法

    因此, 筆者會針對某個主題至少閱讀三本書以上

    為什麼不是一本, 因為每本書的作者經驗背景不同

    書的出版日期時空背景不同

    看三本以上類似主題的書 ,

    可以讓你至少知道這個領域包含哪些內容

    整個專業的全貌與輪廓, 往後如果細節有些子議題可以參考

    業界標準或是規範

    Image result for iso standards

    每個領域都會有些業界相關的標準,

    例如 ISO定義許多標準

    美國NIST 也定義許多的標準

    這些之所以可以成為標準, 至少是普遍業界遵循的作法

    儘管標準不是最新的技術或是做法

    但是是業界認可一致性的作法

    所以必須研究清楚該專業領域相關的標準為何

    標竿企業

    Image result for fortune 500

    每個一專業領域通常會有相關的企業為該領域提供專業服務或是產品

    從該產品與服務的白皮書與介紹

    可以了解到該領域的技術, 客戶與市場應用的狀況

    畢竟這是該標竿企業實際商業運用可行的模式

    最佳實踐

    Image result for best practices

    最佳實踐指的是業界普遍或是建議的做法

    筆者建議可以參加各大論壇或是業界組織

    或是多看許多不同的 blog 看看不同專家的實踐與討論

    客戶需求

    Image result for customer

    專業領域最終離不開客戶需求

    內部客戶需求或是外部客戶

    對於該專業領域, 了解客戶原始的需求與解決的問題

    最終將解決方案落地到產品或是融入工作

    不然就會變成單純的研究工作, 而非客戶中心為導向

     

    最後最後

    輸出實踐

    一定要有自己的輸出, 不要只是閱讀或是研究

    輸出有幾種形式

    1. 到業界組織大會演講
    2. 在公司或是團隊內部分享會
    3. 發表寫一篇小的分享文章
    4. 將觀念融入在產品開發過程
    5. 實際運用解決客戶問題
    6. 出書
    7. 發表 blog 文章
    8. 整理 PPT 上傳到 slideShare

    最好的方式還是可以實際解決客戶問題

    在現有工作上體驗的實踐經驗

    輸出 實踐  解決客戶問題

    還是我們希望達到業界標竿專業的最終目的