多數業務系統都自帶使用者登陸模組，而其中最常見的登陸方式為使用者名稱+密碼，常見的安全性考慮**如下
1、當使用者輸入不存在的使用者名稱時，提示「使用者名稱不存在」更友好？2、當發現某惡意請求後，限ip?
某廣告：每日**ip量可達100萬,不重複
3、資料庫儲存明文密碼？
所有拿到資料庫訪問許可權的人都知道使用者的密碼，想想多可怕？
4、資料庫儲存md5後的密碼？
比明文好一點點，但是
某彩虹庫廣告：共24萬億條記錄，共占用160t硬碟
通過空間換時間，一般的字串批量解密已經是很簡單的事情
5、md5加鹽？
首先鹽要夠複雜，如果是「2017」，那加了跟沒加效果差不多
其次鹽不能採用固定值，萬一被洩露了或被嘗試出來了，那會是個隱患，常用的做法是給每個使用者分配乙個鹽值
那使用者密碼表裡面加個鹽字段，用uuid總可以了吧？那萬一被脫庫，鹽不也洩露了嗎？給鹽單獨建個庫？成本貌似也挺高，萬一鹽庫也被脫了呢？
那把鹽一分為二，庫里放一部分，**（/程式配置）裡放一部分，那萬一資料庫和**一起洩露了呢？
為了這個鹽我們還真是操碎了心。所以說架構師具休實施時還需要根據實際情況權衡吧
http明文協議，是導致資料洩露、資料篡改、流量劫持、釣魚攻擊等安全問題的重要原因。http協議無法加密資料，所有通訊資料都在網路中明文「裸奔」。所以全網https只是時間問題：
以下為https核心原理圖示：
step1:客戶端請求獲得服務端的公鑰，公鑰也能被攻擊者獲取
step2:客戶端生成隨機金鑰（對稱加密），並將金鑰使用step1的公鑰加密發給服務端，攻擊者由於沒私鑰無法解密
step3:客戶端和服務端都獲得了隨機金鑰，而攻擊者沒有能得到，所以後續雙方通訊的內容均以該隨機金鑰加密傳輸理論上是安全的。
7、自定義加解密演算法
https就一定安全了嗎？試想一下，如果在客戶端和服務端之間存在乙個**，對客戶端它裝成是服務端，對服務端它裝成了客戶端，那密碼這些核心資訊不就洩露了嗎？這就是中間人攻擊的核心原理。中間人攻擊的容易實施的乙個前堤是加密演算法是公開的，如果客戶端和服務端之間採用自定義加密演算法（更常見的做法是自定義加密演算法和公開加密演算法相結合），那勢必會提高中間人攻擊的成本。注意：自定義加解密演算法不能杜絕中間人攻擊，但會增加中間人攻擊的成本，可以阻止一般通用的中間人攻擊。
8、日誌log
按使用者名稱和密碼登陸介面，很常見的情況下會被封裝成如下所示：
@data
public class logininfo
所以當重寫tostring方法時， 要注意把敏感資訊去掉不展示，如本例中的password。
9、驗證碼
驗證碼是為了防止機器嘗試暴力登陸，但是這也極大的降低了使用者體驗。以前的驗證碼用肉眼是很容易識別的，隨著驗證碼機器識別技術的提高，驗證碼也越來越複雜。有些驗證碼，連人都識別不出來，更別說是機器了。但是，這就足夠安全了嗎？！網上驗證碼人力識別已經形成乙個成熟的黑產鏈了。
趣聞：據說某公司基於其龐大的使用者量，當使用者登陸時要求其輸入別家的驗證碼，這樣他的使用者其實是免費幫他識別了一次驗證碼。這也算是社會工程學的運用了吧......
10、簡訊驗證碼
隨著手機保有量的提高，不少**以手機做為使用者的惟一標識，使用簡訊驗證碼登陸也是很常見的做法，也有**是以使用者名稱、密碼+簡訊驗證碼作為對登陸安全的增強校驗。簡訊難證碼使用時容易引起以下問題：
11、其他**密碼洩露
偷懶是人類的天性，很少有人給自己的不同賬號設定不同的密碼，哪天鄰家的資料庫被脫庫，很大可能也會殃及你家的使用者。最大的挑戰在於你能保證自己家的資料安全，卻沒辦法保證鄰家的安全。
對策：1、密碼定期更換機制
2、核心操作二次鑑權 （如登陸密碼+交易密碼，登陸密碼+驗證碼）
3、安全團隊跟進鄰家惡性脫庫事件，對洩露的使用者進行標識，傳送警告簡訊、郵件並在使用者資訊得到進一步驗證前鎖定使用者。
12、風控
暴力破解、使用他家被脫庫的賬號登陸進入業務系統後的操作流程都會與使用者正常使用的習慣上存在較大的差異，基於此，可根據使用者操作日誌做風控，一旦觸發，則鎖定使用者，要求進一步核實資訊。
13、密碼控制項
安全控制項在一定程式上防止了在輸入密碼時被鍵盤輸入記錄直接被擷取。它的加密演算法是寫在 native 裡面的，而且公鑰也可以直接內建到客戶端，中間人無法篡改公鑰，也就沒辦法拿到密碼明文。甚至還能加上一些客戶端執行環境安全檢驗的功能，當不安全時拒絕使用者輸入密碼。在一定程度上保障了密碼安全。
14、跨站請求
你不能阻止你的使用者在訪問完你的**（在未主動退出登陸且會話未超時的情況下）之後繼續訪問其它**，而你也不能保證其它**一定不會是釣魚**，釣魚**在返回的頁面中通過使用者瀏覽器給你的**偷偷地發起了使用者不知情的請求，這就是著名的csrf（cross-site request forgery）跨站請求偽造攻擊。
常見的防範csrf攻擊的方式是http頭加referer頭校驗並對每個請求加個crsf token，即使用者請求生成表單時隨機生成乙個token返回給客戶端，使用者提交表單後校驗這個token是否正確。一般由於csrf攻擊方只能模擬對跨域站的get和post請求，跨域無法獲取對方的dom，所以無法完全模擬使用者請求。
15、xss攻擊
輸入都是不可信的，假如你的應用是個論壇，攻擊使用者發個貼子，內容如下：
總結：
隨著程式設計師安全意識的提高，從當年的sql注入攻擊和cookie安全，到csrf和xss攻擊，安全問題也有從後端漸漸蔓延到前端的趨勢。使用者輸入都是不可信的，訊息在傳輸中都是可以被監聽的，這就要求我們對輸入的資訊進行完善的過濾，對傳輸的訊息進行加密。而企業內部及使用的第三方服務（如簡訊服務商）也存在一定的涉密的可能，要求我們對此要有足夠的預案。這裡介紹的常見方法也不會是孤立的，而是互相組合靈活運用，而道高一尺，魔高一丈，安全的攻與防，矛與盾也將會一直持續下去......
安全性測試 登陸
登入功能怎樣做安全性測試，要關注哪些方面.閒來無事，根據自己以往做過的專案，現總結如下 1 登入時對使用者名稱 密碼 驗證碼的合法性驗證 2 連續登入失敗後的處理策略 比如 連續失敗3次，鎖定賬號一段時間 3 使用者名稱的規則 4 密碼策略 比如 長度限制 字元限制 不能與賬號相同等 5 密碼輸入框...
PHP 安全性漫談
本文所討論的安全性環境是在linux apache mysql php。超出此範圍的安全性問題不在本文範疇之內 一 apache server安全性設定 1 以nobody使用者執行 一般情況下，apache是由root 來安裝和執行的。如果apache server程序具有root使用者特權，那麼...
PHP安全性漫談之PHP安全性設定
伺服器並不能阻止所有的安全問題，例如程式漏洞問題 使用者輸入表單問題 php檔案許可權問題等。也可以通過一些手段來迷惑黑客或者別有用心者。1 程式 漏洞問題 很多 php 程式所存在的重大弱點並不是 php 語言本身的問題，而是程式設計者的安全意識不高而導致的。因此，必須時時注意每一段 可能存在的問...