題:
在向員工發送用戶名和密碼時是否應該對經理進行抄送
enthusiast
2012-07-27 00:32:52 UTC
view on stackexchange narkive permalink

我經常為新員工創建登錄名,然後向他們發送一封包含其登錄憑據的電子郵件。在執行此操作的同時,我還抄送了其經理的信息,以告知他已設置用戶。
這是正確的做法嗎?在向用戶發送用戶名和密碼時,經理應該被抄送嗎?他們不做任何機密的事,但當然要對他們的行為負責。

您將電子郵件發送到哪裡?也就是說,**用戶首先如何訪問他們的登錄憑據?**(也就是說,我完全同意@Oded's的回答。)
希望A)此密碼是一個隨機字符串,B)僅一次使用,因為以明文形式發送任何憑據(更不用說存儲它們了)既愚蠢又危險
如果這是一個新帳戶,他們將如何登錄以提取包含密碼的電子郵件?在這種情況下,將初始密碼發送給老闆通常是最好的選擇。
為什麼將它們發送給新用戶?他們應該如何找回它們?似乎將完整的憑證發送給經理是新帳戶持有者接收憑證的唯一方法,對嗎?
通知老闆已經創建了一個新帳戶,但不發送密碼。順便說一句,您通過電子郵件發送的密碼必須是一次性使用的密碼...
您也可以將鑰匙放到門墊下面的辦公室前門。或告訴人們將密碼寫在便箋上,然後貼在顯示器的側面。您也可以只給每個人使用相同的密碼,從而節省了您必須告訴他們的密碼的時間。您可能以為我在開玩笑,直到您真正看到人們這樣做為止,然後突然變得不那麼有趣了。因此,談到安全性。不要像開玩笑一樣處理它。
十一 答案:
Oded
2012-07-27 00:35:20 UTC
view on stackexchange narkive permalink

通知管理員憑證已創建。

不應將上述憑證發送給管理員-特別是如果您有一個涉及用戶的審核記錄,如何確定係統標記了該用戶的確是用戶而不是其管理員?

登錄憑據的全部目的是確保登錄用戶就是他們所說的身份(身份驗證),以便使他們能夠訪問所需的內容(授權),並在某些情況下允許進行審核跟踪。

將其憑據提供給其他人完全顛覆了這一點。

我想我做錯了。
好吧,如果憑據是永久性的,那隻是一個真正的問題。畢竟,管理員('您')也認識他們!如果憑據需要在首次登錄時進行更改,那麼問題就不大了。
在我們的工作場所,甚至IT人員都不知道密碼。在為每個新用戶提供默認密碼後,系統會提示他們更改其密碼。然後,每隔90天,我們會被要求再次進行更改。如果忘記了密碼,我們會詢問IT部門,他們會分配一個通用密碼,在登錄時再次要求我們更改該密碼。我們使用Windows。
要說明的另一點是,如果這些憑據是由用戶提供的,並且將它們轉發給經理,您怎麼知道您也不會無意中將用戶的銀行密碼發送給經理!
由於有一些評論,我將添加更多詳細信息。我們不強迫用戶更改密碼。儘管用戶可以*更改它,但通常保持不變。這是因為我們只是一家小公司,沒有涉及任何機密信息+我是最近才被錄用的,在我之前,沒有技術人員可以調查丟失的密碼等,從而延續傳統。
@Thecrocodilehunter-像現在這樣,沒有時間更改這些傳統...正如其他人所評論的那樣,在許多環境中,設置了初始密碼,系統要求用戶在首次登錄時立即進行更改。也不提供密碼恢復服務-如果用戶忘記了他們的新密碼,管理員將以相同的條件設置一個新密碼-用戶登錄後需要立即進行更改。這樣可以確保用戶的密碼安全。您所擁有的現狀不是一個好狀況,為更好的系統而對其進行更改。
“這是因為我們只是一家小公司,沒有涉及任何機密內容。”-這並不意味著您在保護環境方面不能也不應遵循最佳實踐。這不僅關乎機密-如果A人知道B人的證書,A可以*假冒*B。在最壞的情況下,造成的重大損害以及受到指責的人甚至都不知道這件事正在發生。
實際上,要添加到alroc的評論中,現在正是您應該更改這些做法的時候。在這一點上,您只有少數人需要重新學習他們的行為,您有機會*在*公司變得更大且根深蒂固之前*更好地改變公司的文化。
Mark Allen
2012-07-27 02:45:22 UTC
view on stackexchange narkive permalink

當然,請繼續-只要要求用戶在首次登錄時更改密碼即可。他們是對的?我的意思是,這裡的目標是獲得員工的資格證明,並證明您已這樣做/將他們授予對幫助新員工同時保持安全性有既得利益的人。

這樣一來,您就能獲得所有這些信息,此外,用戶還必須在“首次登錄”時更改密碼或現在進行任何更改,因此不會受到任何損害。也會以這種方式處理密碼更改-忘記密碼,他們會通過電子郵件將新的(臨時)密碼發送給您的直接管理員。

只要“我得到了我的憑據,但它們不起作用”就可以得到正確跟踪,而不僅僅是重新生成。
-1我要說的是,即使員工首次登錄後,這些密碼將被更改,經理也永遠不會看到他們的任何密碼。例如,如果一個邪惡的經理以僱員的身份登錄並將密碼更改為該僱員不知道的密碼,然後責怪該僱員在鎖定計算機的同時未完成工作,該怎麼辦?如果經理從未看到員工的證書,則這種情況是不可能的。
@Kevin I在假設(如答案中所述)的前提下工作,即經理在協助自己的員工方面具有既得利益。如果他們不這樣做,那麼比更改密碼有更大的問題。
@MarkAllen:如果經理正在(或正在計劃)破壞員工/公司,那麼他們就遇到了大問題……情況變得更糟!
Sahil
2012-07-27 11:34:14 UTC
view on stackexchange narkive permalink

您可以為此發送兩封電子郵件。這是我們公司遵循的原則,管理人員對此從來沒有問題。


致:員工

抄送:Manager1,Manager2

尊敬的員工,

您已在系統中註冊。您的用戶名是 firstname.lastname

為遵守公司的安全策略,密碼將在下一封僅標記為您的電子郵件中發送。

關於IT團隊


致:員工

尊敬的員工,

用戶名的密碼> firstname.lastname mynewpassword 。我們要求您立即進行更改。

關於IT團隊

似乎在第二封電子郵件中包含用戶名和密碼會否定單獨發送用戶名和密碼的意義!
@JeromyFrench:怎麼辦?關鍵是第二封電子郵件僅發送給員工,而不發送給經理。 (通過電子郵件發送純文本密碼是另一個問題,其他答案對此進行了討論。)
耶魯是正確的。在第二封電子郵件中同時填寫用戶名和密碼意味著:a)截獲該電子郵件的任何人都可以登錄帳戶b)第一封電子郵件毫無意義。第二封電子郵件應顯示為“您最近創建的帳戶的密碼為'mynewpassword'”
如果員工無法登錄系統以獲取電子郵件,該如何接收密碼?
@DJClayworth第一封電子郵件並非毫無意義。儘管員工兩次收到實際的登錄名,但這意味著每個人都知道已設置登錄名,每個人都知道其他人都知道,並且除了員工以外,其他人都沒有密碼。
tylerl
2012-07-27 14:11:44 UTC
view on stackexchange narkive permalink

通過電子郵件發送密碼是適當的,但該密碼必須是臨時的;首次登錄時,系統必須強制更改密碼。大多數企業級產品都支持此選項。

問題是憑據不應該公開存儲在任何地方-最不重要的是通過電子郵件發送,因為這是攻擊者的首要關注對象。在單獨的電子郵件中發送密碼並沒有真正的幫助,因為進入您的電子郵件的黑客將能夠看到這兩種消息,因此您再安全不過了。此外,經理或其他任何人可能會要求您將其複製到此類電子郵件中,這樣會大大增加攻擊面,並增加攻擊者獲取密碼的可能性。

最好的解決方案是只需強制用戶更改密碼即可。 請勿要求用戶更改密碼,,因為他從不會這樣做。那裡有成千上萬個使用密碼 12345 的帳戶,該帳戶已分配為臨時密碼,並且要求用戶進行更改...而他從未更改過。

+1表示交流登錄憑據的行業慣例。
Neuro
2012-07-27 19:20:02 UTC
view on stackexchange narkive permalink

不!不是-這是安全性和sysadmin 101。

您也永遠不會在同一文檔中明文發送用戶名和密碼。最佳做法是創建一個臨時密碼,並通過其他方法將此密碼傳達給員工,並讓用戶在登錄時更改密碼。

Anthony
2016-05-05 04:23:03 UTC
view on stackexchange narkive permalink

否,密碼甚至不應該放在電子郵件的首位。在我的工作場所,一個用戶將登錄ID告訴用戶並要求用戶致電IT 以獲得臨時密碼。

還有其他一些安全方面的考慮。

  1. 如果您的公司擁有強大的技術來支持它,則應該使用諸如bcrypt之類的強大算法對密碼進行哈希處理。諸如MD5和SHA之類的不安全協議永遠不要使用1。

  2. 電子郵件本身應加密發送

    避免使用SSL和早期版本的TLS作為加密方法,因為它們被認為是比較安全的。AES可以用來對稱加密,或者像RSA這樣的算法可以用來不對稱加密(2個密鑰)。加密時,請選擇較長的密鑰長度以最大程度地提高安全性,因為密鑰的安全性與其字符長度直接相關。

  3. 帶有敏感信息的安全電子郵件應以數字方式進行保護

  4. ol>

    一種單向哈希函數(例如HMAC-),以便收件人能夠驗證發件人的真實性並確保發件人不可否認。 SHA 256用於將電子郵件轉換為加密消息摘要。 請勿使用SHA 1算法進行簽名,因為該算法已被加密破壞,因此不再安全。使用PKI,只有您知道的私鑰才能用於加密。接收者使用您的公共密鑰解密後,結果消息散列應該相同。通過將所有者的身份與他/她的公共密鑰綁定在一起的證書,可以保護公共密鑰不被篡改。在驗證您在證書請求中提供的憑據後,將通過CA獲得證書。

    否則,消息完整性會丟失,並且所接收到的消息不能被信任為您發送的消息。

    私有密鑰僅對發送者是已知的,並且與電子郵件的接收者已知的唯一公共密鑰相關聯。通過接收者能夠使用與電子郵件的發送者相關聯的公鑰來解密電子郵件消息這一事實,意味著發送者無法拒絕已發送該消息>>

    Point 2確保電子郵件的機密不會受到損害。機密性意味著不會發生諸如通過MITM之類的未經授權的洩漏。

    第3點可確保完整性和不可否認性,或者確保未經未經授權的一方未更改電子郵件的內容,並且發件人不能拒絕,因為存在電子郵件接收者用來解密消息的公共密鑰。

    最後,您可以在顯示時屏蔽數據以獲得更高的安全性。

**這應該是公認的答案。**另請參閱此[security.SE](http://security.stackexchange.com/a/17981/105419)問題和答案。
acolyte
2012-07-27 01:40:32 UTC
view on stackexchange narkive permalink

如果您要問這個問題,那麼您就在IT領域。問你的老闆公司的政策是什麼。那是最安全的道路。否則,我傾向於說不,不要給管理者憑據。

但是,總是讓管理者知道已經為其基礎創建了登錄。如果他們隨後要求提供憑據,請他們通過您的老闆提交,以便通過適當的渠道進行提交。

如果他們要求提供憑據,則主要是錯誤的。
不需要@jmort253。一般來說,這不是很好。但在某些情況下還可以。就事論事。畢竟,如果員工生病了並且應該進行演示,則老闆可能會請求訪問員工的計算機以提取相關文件,以便自己進行演示
這是應該考慮的風險。Bob不應是唯一有權訪問文件的人。管理員應該能夠使用他/她自己的登錄名來訪問系統。正如Oded所說,身份驗證的全部目的是驗證訪問資源的人是否是他/她所說的那個人。例如,這就是Google Docs具有共享功能的原因,因此我不必授予您訪問我所有內容的權限。在這種情況下,最主要的錯誤是員工,經理和IT部門缺乏計劃。
Wesley Long
2016-05-05 03:20:49 UTC
view on stackexchange narkive permalink

我會定期處理此問題。

這是迄今為止最好的解決方案:

  1. 我創建了一個小腳本來創建用戶帳戶,並設置密碼(我從dinopass.com提取信息,但不管您想要什麼,都將其分配給他們的工作角色(活動目錄組)。密碼設置為需要在首次登錄時重置。
  2. 然後,腳本將使用用戶的登錄名和密碼生成一個文本文件。它還包括有關登錄的簡單說明,以及支持部門的電話/分機。
  3. 我打印文本文件(通常我討厭打印,但在這種情況下,是的),將打印輸出放在密封的信封中
  4. ol>

    很明顯,如果您的組織規模如此之大,以至於您擁有多個校區,則此方法可能無法正常工作,但是可以使用以下方法:

  • 保護“愛管閒事”的同事的密碼。
  • 強制在首次登錄時重置密碼。
  • 清楚地告知管理員任務已完成。
  • 可以幫助您確定員工的第一條詢問線是對經理的詢問,而不是對服務台的詢問。

顯然,這在單一建築物的環境中效果很好,但對我來說確實很好這也使我的一線技術人員可以輕鬆地處理事情,因為我只給他們腳本(C#控制台應用程序,要求輸入用戶的名字/姓氏,並選擇員工角色)。

希望對您有所幫助。

mhoran_psprep
2012-07-27 00:45:51 UTC
view on stackexchange narkive permalink

如果您位於新員工附近,則可以讓他們領取登錄信息的紙質副本。您只需要讓經理知道已經準備好了。

如果您與員工之間的距離太遠,您將不得不通過電子郵件向經理髮送憑證。這是為了讓他們將憑證提供給新員工。

我在一個工作過的地方工作,試圖告訴您留下語音郵件來領取密碼。他們還向您發送了一封電子郵件,告訴您現在已啟用語音郵件。不用說,這種方法對新員工來說效果不佳。

我也曾經將憑證發送給經理,因為該員工不會嘗試登錄。他們告訴經理他們從來沒有得到他們。在創建新的臨時密碼並將其發送出去之後,經過4或5個週期,在我也將它們發送給管理員之後,它們奇蹟般地到達了。

GreenMatt
2013-01-12 01:48:52 UTC
view on stackexchange narkive permalink

我使用過的解決方案,但沒有看到建議的解決方案:向新用戶發送電子郵件,讓他們知道他們的帳戶已設置。如果抄送他們的經理似乎合適或必要,那就這樣做。但是,您向他們發送您的電話號碼,並讓他們致電(或拜訪)您以獲取其憑據。或者,您可以在此電子郵件中向他們發送其登錄ID;但是, 不要通過電子郵件發送密碼

gnasher729
2016-05-04 12:45:45 UTC
view on stackexchange narkive permalink

想像一下,已經造成了一些刑事損失,毫無爭議的證據表明,這是由擁有該用戶名和密碼的人造成的。現在你有問題了。有兩個人,您可以肯定一個人是罪犯,一個人是無辜的。貴公司有大問題。在歐洲,您遇到了一個巨大的問題,因為您知道有人造成了刑事損害,您不能解僱他們。在美國,您仍然有一個巨大的問題,因為您可以解僱兩個人,但其中一個人完全是無辜的,您將失去很可能是一個好員工的人。另外,員工和經理都知道這一點,因此,如果只有一個人知道密碼,那麼可能就不會造成損害。

除了該用戶外,其他任何人都必須知道密碼。 IT可能具有重設密碼的方法,並且在重設密碼後可能能夠進入計算機,但是他們也必須不知道當前密碼,並且不能更改密碼,從而對該用戶的帳戶造成損害,並且改回密碼。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...