很初級的簡單想法，先記下來。
需要有個年輕聰明的青年才俊論證一下：
1、是否用https，這些就沒有必要了。
2、嚴謹性：是否有漏洞，這麼做安全性依賴哪些要素，能多大程度上保證。
3、必要性：是否有冗餘環節。
4、效能：壓一下，注意監控cpu。
以下是正文。
1、所有的秘鑰都由我們生成並頒發。
2、我們需要儲存：
（1）我們自己的私鑰、公鑰。
（2）別人的公鑰。
（3）所有公鑰和實體（如：某組織、某組織中的某人、我們自己等）的對應關係。
3、頒發出去的私鑰由安全的方法傳遞給對方（u盤拷貝？）。最大限度保護對方公鑰和對映關係的私密性。
1、身份認證過程：
（1）不需要賬號、密碼神馬的。
（2）請求發起過程：
該使用者在我們系統的編號設為uuid。
step 1，對方自己生成乙個種子，設為 seed，需確保seed的隨機 。
step 2，用我們的公鑰加密，結果設為 token1。
step 3，用使用者自己的私鑰加密，結果設為token2。
使用者發 uuid，seed，token1和token2給我們。
（3）驗證過程：
step 1：用自己私鑰對token1解密，得到seed。
step 2：通過uuid獲得公鑰，用這個公鑰解密token2，也得到seed。
step 3：比對step 1和step 2獲得的seed是否相同。如果相同，傳輸成功。
step 4：驗證成功後，將token用使用者公鑰加密，發給使用者。我們的伺服器儲存token 20分鐘。
2、傳送資料給我們
（1）傳送過程：
資料設為data。
step 1:用我們的公鑰對data加密，得到密文c1（需要驗證一下效率）。
step 2:對密文生成數字摘要，設為z1。
step 3:用使用者自己的私鑰對摘要加密，得到密文z2。
step 4:用我們的公鑰對c2和token加密，得到密文c3.
step 5:傳送c1和c3給我們。
（2）接收過程：
step 1：用我們自己的私鑰解密得到data、z2和token。
step 2：通過token獲得使用者公鑰，對z2解密得到z1。
step 3：對data生成數字摘要，設為z1』。
step 4：比較z1『和z1，如果相同，則接受data。
3、反饋資料給對方：
blabla
附錄：掃盲
（以下內容**網際網路，原始鏈結... err...隨手把網頁關了...）
支付安全考慮
1.網銀類 像招行支付 工行支付 西聯快匯等 2.綜合電子錢包類 像支付寶 快錢 易寶 paypal moneybookers facebook credits等 3.虛實卡類 神州行 mycrad gash 駿網一 崑崙一 mol等 4.固話聲訊類 像杭州齊順 daopay等 5.手機簡訊類 像聯...
web安全考慮
1.sql注入攻擊 伺服器端程式有時希望接受客戶端輸入並且將他作為查詢的一部分 例如 乙個接收使用者名稱的登入介面可能執行以下 sql select from users where username 如果客戶端輸入以下字串作為使用者名稱 a delete from users sql select...
開放API設計安全考慮
1.加密敏感資料保證安全，非對稱演算法rsa和對稱演算法des sm4等 2.摘要演算法md5防止篡改，演算法中增加鹽值 雙方約定的乙個秘密值 增加伺服器時間值，用於判斷呼叫提交時間 3.採用token的方式校驗是否已經登入，乙個是判斷token是否存在，二是token是否過期 4.介面設計需要具有...