2010-03-09 24 views
0

我知道標題有點偏離,但很難用短句解釋問題。登錄爲webapp,需要提供支持人員

我是一個遺留Web應用程序的管理員,可以讓用戶創建調查並將它們分發給一組人。我們有兩種「用戶」。

  1. 授權的許可證持有人,它們都自行設置。
  2. 客戶誰只是希望有一個調查來看,但仍需要一個用戶(因爲web應用程序具有「用戶」作爲一個surveyenvironment頂部實體。)

有時在#1的用戶希望我們這樣做他們的設置(我們提供)。這意味着我們必須以他們的身份登錄。 這也是我們的支持方式:我們以他們的身份登錄,然後跟隨他們,引導他們。

這將我帶入我的兩難境地。目前我們的安全性低於標準。但是這讓我們很容易做出支持。我們希望增加安全性,並且我一直在考慮的一件事就是對DB進行常規哈希處理,但是,我們需要能夠以客戶身份登錄,並且如果他們在未通知我們的情況下更改密碼,並且密碼在db中被散列,我們無法知道它。

所以我正在考慮對密碼進行某種雙向加密。無論是那種或某種主密碼。

有什麼建議嗎?

(該平臺是傳統的ASP ...我說,這是傳統的...)

回答

0

聽起來像你想從你的身份有點脫鉤您的身份驗證。也許像管理員覆蓋頁面那樣,所以在以管理員身份登錄後,您可以選擇想要假定的用戶身份。選擇身份後,您將繼續使用該應用程序而無需進一步身份驗證。

+0

這允許存儲所有密碼與強大的單向加密 – 2010-03-09 10:31:12

1

我會做的是讓支持人員用他們的用戶名/密碼登錄,但選擇用戶「模仿」。因此,在你的會話,你將有:

  1. logged_user - 誰在他/她的用戶名和密碼輸入的實際用戶
  2. 模擬用戶 - (1)是代表的

用戶你所做的一切都是通過模擬用戶的權限和偏好來完成的。 如果您不是冒充任何人impersonated_user=logged_user。 這樣您必須始終使用「實際」用戶名和「模擬」用戶名記錄任何操作;例如:

2010-03-09 | 11:34 am | deleted item #890 | 'George' impersonating 'Lizzie' 
+0

我認爲這將是一個重新編碼太多... – 2010-03-11 13:11:31

1

您提出的兩個選項對我來說都沒有吸引力。

  • 一個主密碼是可能比你在做什麼,現在

  • 數據庫加密(而不是散列)密碼,更危險的是不夠是好IMO,因爲只需要休息在你的最後掌握所有的密碼。他們真的應該被哈希。

我承擔產品,是一箇舊的遺留應用程序,是不可能的(或經濟上是不可行)的方式來改變該管理員帳戶可以模擬用戶帳戶,這在我看來仍然是這一點的最好辦法在現實世界的情況下(並非所有人都認同這一觀點,就問題here進行討論)。

如何引入包含散列密碼的第二密碼列(password2進入?該應用程序的登錄過程可能很容易調整爲查看第二列。這可能很容易實現,我看不到任何額外的安全問題(如果我錯了,請糾正我的錯誤)

0

我喜歡Manrico Corazzi提供的解決方案。它提醒我,當你需要微軟的支持時,有辦法將你的機器的控制交給技術人員。這可能是實現假冒機制的另一種方式。爲了管理員帳戶登錄,授權許可證持有者必須明確允許他加入他的會話並以他的所有特權行事。