我有一個要求,可以安全地存儲一些數據,這些數據可以由授權用戶在網站上檢索。這不是信用卡,但同樣是你不希望有人得到他們的數據。使用PHP安全存儲數據
,將檢索數據的唯一用戶是誰張貼的一個。
所以,我在想東西放在一起類似如下:
- 一切都運行在SSL
- 要登錄,用戶將進入他們的用戶名和密碼,還必須上傳「鑰匙」文件 - 用戶將被推薦到只保留密鑰文件的一個副本拇指驅動器或類似
- 用戶的密鑰將不被物理存儲在服務器上。當用戶提供其鍵登錄,將被存儲在內存中
- 所有存儲的數據將使用MCRYPT_RIJNDAEL_256進行加密,並使用加密密鑰將是他們必須上傳密鑰文件的一部分(即不是存儲在一個服務器)
- 當用戶的密鑰被保存在內存中,這也將使用MCRYPT_RIJNDAEL_256使用每天都在變化的密鑰加密
- 當數據被檢索我們將生成一個新的32字節的IV,所以我們應該得到不同的結果爲兩個獨立的檢索
- 用戶可以再生時,他們要求他們的關鍵,在這一點所有的存儲數據與他們的新的密鑰 重新加密
- 用戶可以在其密鑰的內存存儲器中設置超時值 - 例如,要求他們每30分鐘重新提供一次超時值。
- 用戶還可以在內存中設置一個不活動的超時時間,所以假定他們不執行一個動作(例如)5分鐘,它也將過期密鑰
- 該框本身將被鎖定只露出端口80和端口22到單個IP(我們的辦公室IP)
我的問題是:
上午我沿着正確的線路在想什麼?上述解決方案是安全的嗎?還是我錯過了一些將使數據變得簡單的攻擊媒介?據我所知,攻擊者需要物理訪問機器(或需要在我們的辦公網絡上),即使情況如此,他們也只能檢索登錄用戶的數據那一刻(因爲他們是唯一可以存儲的密鑰)?我的假設是否正確?
是否有刪除的要求來存儲用戶在內存中的關鍵,而他們在(短,要求他們重新提供他們在每次請求鍵)記錄的方法嗎?我不認爲有,但我希望這是我沒有想到的。
謝謝!
[HSTS](http://dev.chromium.org/sts)也可能是一個很好的實施建議。我也同意一些OP的做法聽起來有點「過度設計」 – 2013-03-23 00:54:22
不錯。不知道HSTS。即使使用不同的Web端口也會比80或443(HTTPS的默認值)更好。 – 2013-03-23 01:02:15
謝謝@ cpattersonv1,這裏有一些非常有用的信息。 爲了澄清,存儲數據的框不在我們的本地網絡中,它位於面向網絡的安全數據中心內。是的,有鍵盤安全,24小時警衛,相機等,所以這不是太多的關注。我之所以提到關於在我們的網絡上的原因是因爲端口22將開放給我們的網絡連接 感謝您的建議 - 這裏有很多東西讓我思考! – 2013-03-23 10:30:42