題:
可以將密碼告訴公司的sysadmin嗎?
BЈовић
2011-07-22 01:29:49 UTC
view on stackexchange narkive permalink

我正在一家小公司(有20名員工)中擔任高級軟件工程師。

在我的電子郵件出現問題後,我們新聘的IT管理員要求我將用戶密碼寫給我們的託管公司可以幫助他們發現問題。

我毫不猶豫地給了他用戶密碼。

30分鐘後,我意識到在數家公司工作的10年中,沒有人要求我輸入密碼,於是我發現這很奇怪。之後,我立即更改了密碼。

在某些情況下,確實需要將密碼告訴IT管理員時,確實需要密碼嗎?

我聽說過管理員僅在每日WTF之類的網站上詢問用戶密碼的故事,才提示了此問題。

(相關內容:”一位客戶想告訴我他家用筆記本電腦的密碼。我必須把他推向更複雜的選擇嗎?“

此問題的[其他版本](http://security.stackexchange.com/questions/5534/is-it-ok-to-tell-your-password-to-an-admin/5537#5537)已關閉,因為不專注於安全性的答案。我的回答集中在實際問題上。在現實世界中,糟糕的外部服務無法為本地支持人員提供幫助。如果您需要當地人的幫助,那麼您可能別無選擇。您可以在之前和/或之後更改帳戶密碼,也可以自己解決問題。
@Zoredache,現在在這裡閱讀更新的答案,尤其是最後一段,確實會有所改變-但請參閱下面我的評論,關於“共享”帳戶的確不是一個好主意。此外,OP確實說了“我的密碼”,看來情況並非如此-但我確信VJo可以澄清這一點。
可悲的是,這發生在我身上。但是管理員是公司的所有者。你能做什麼?
@AviD對。該帳戶未共享。
@LarsTech管理員是幾個月前僱用的一個人
“我的密碼”和“我們託管公司的密碼”是兩個完全不同的東西。前者與管理員沒有業務往來,後者很可能需要他完成工作!
@MichaelKjörling:非常好;您應該將其複制並粘貼到新答案中。尊敬的OP:如果他這樣做,您應該接受。
@unforgettableid我想[@David Houde](http://security.stackexchange.com/a/37867/2138)就是這樣做的。
@MichaelKjörling:建議的修訂版2不明智地將短語“在遇到一些電子郵件問題之後,我們的新聘IT管理員要求我提供密碼以與託管公司聯繫,以了解其確切原因”,改為“在一些電子郵件問題之後,我們的新聘IT管理員向我提出了要求。密碼給我們的託管公司,以查看其確切原因”。 OP沒有解決問題,因此[批准](http://security.stackexchange.com/review/suggested-edits/258)建議的編輯。 OP現在已修復該錯誤。因此,事實證明,它畢竟是sysadmin請求的OP的用戶密碼。
@MichaelKjörling:看來DavidHoude的[answer](http://security.stackexchange.com/a/37867/2138)已被刪除。
九 答案:
AviD
2011-07-22 01:52:20 UTC
view on stackexchange narkive permalink

簡短答案:

絕對不可以!
您的密碼在您和您自己的計算機之間。
沒有其他人。

不是您的老闆,他的老闆,系統管理員,銀行職員,保險代理,ISP支持技術人員或您的貓。好吧,你可以告訴你的貓,如果她答應不分享。

從來沒有一個很好的理由來共享密碼。
有很多理由不願意。通常,因為密碼是您的身份驗證,而且即使一個人知道了它,它也無法再證明您的身份。

您的管理員提出的任何理由都是虛假的,要么是因為他是惡意的,懶惰的,錯誤的消息或不稱職的。
那不是他的錯,而是組織的錯。無論哪種方式,都會出現無能,無知和懶惰的現象。

如果管理員或任何支持技術人員要求您輸入密碼,則正確的答案是對LAUGH。
因為他們不可能認真對待,對嗎?

如果您的管理員堅持要-向他解釋您將與他共享密碼的文檔...並且在此基礎上,您將向周圍發送討厭的電子郵件-而不是 about 他,但您會聲稱它們來自他 (使用您的帳戶,以您的名義,使用您剛剛與他共享的密碼)。當然,他將無法證明自己沒有濫用您的密碼...這就是重點。

不,再三考慮,不要給他您的密碼。是您的,僅在您和計算機之間。

我還將指出,除非您明確信任此人,否則您不應在他的計算機上鍵入密碼。而且他不應該問-這是對用戶的不良教育,訓練用戶在任何隨機計算機上鍵入密碼-可能會有鍵盤記錄程序,流量嗅探器等。
有人喜歡使用CAPSLOCK設定要點。
轉變,實際上。有選擇地使用它,是強調的有用工具。
這就是我以為會得到的。
問題是有關管理員可能有權訪問的外部服務的密碼。如果期望上述管理員能夠幫助解決需要這些特定憑據的複雜問題,那麼您如何期望在不共享密碼的情況下發生這種情況?發送令人討厭的電子郵件或面對要求您提供幫助的技術而大笑,這可能會導致您得不到幫助,或者是那個以BOFH風格對您進行報復的傢伙。
@Zoredache,如果管理員應該有權使用此服務,則他應該具有自己的憑據。如果他不這樣做,那麼他不應該這樣做。請注意,(擁有)憑據幾乎等同於(擁有)身份-不應共享。討厭發送討厭的電子郵件,而是為了顯示共享密碼的問題。笑聲也是如此,因為有了誠實,稱職的系統管理員,這只能說是笑話。 (順便說一句,根據我的經驗,安全人員可以使用* real * bofh東西...;)
順便說一句,@Zoredache,以上註釋的一個“例外”是,如果憑據不是用於他的*個人*帳戶,而是用於“公司”共享帳戶。 (我*認為*這可能是您得到的...?)在這種情況下,當然不應they積它們,並交給任何負責管理的人。這是非常糟糕的做法,受到許多法規的禁止,但沒有像將密碼密鑰交給您自己的身份王國那樣糟糕。
是的,我主要是在談論外部提供商將其視為屬於組織而非個人的憑據。問題是關於小型企業的。不幸的是,在小型企業中這很常見,IT支持將無權訪問,或者管理員無權訪問他所希望幫助的服務。我同意您幾乎永遠不應該共享密碼,但是我只是說在一些不太理想的環境中,沒有太多選擇。
不要告訴您的密碼您的貓。在任何情況下,貓都是[不受信任的](http://jpetrie.myweb.uga.edu/journal.html)。儘管它們看起來很無辜,但已知它們是惡意的。
這隻貓顯然已經知道了密碼,因為它也是他的名字。
@KristoferA:是密碼*他的名字*還是[*他的名字*](http://www.catquotes.com/thenamingofcats.htm“ TS Elliot的“貓的名字”)?我問是因為他不關心後者,而您也不應該知道前者。 …………………………………………………………那麼,當有人知道您的密碼時,您會更改貓的名字嗎? :-)
“ [[不被信任的貓]](http://jpetrie.myweb.uga.edu/journal.html“貓日記中的條目”)鏈接已損壞。原始內容的版本略有不同[此處](http://www.pawsperouspets.com/humor/catdiary.shtml“貓秘方日記”)和[此處](http://www.goodeatsfanpage.com/幽默/otherhumor/dog_cat_diary.htm“貓的日記”),帶有更長的版本[此處](http://www.papermodelers.com/forum/comedy-stand/12698-excerpts-cats-diary.html“摘錄自貓的日記...”)和[此處](http://gpsinformation.info/main/cat-diary.txt“俘虜的貓的日記”)。
@AviD您的論點聽起來很合理。但是,這些原則是否有權威來源?我認為向我們的IT人員顯示一個隨機的stackexchange答案來證明它們是錯誤的不會令人信服。
M'vy
2011-07-22 02:00:47 UTC
view on stackexchange narkive permalink

讓我們嘗試另一個想法:您是否願意向IT經理伸出手指,以便他在您工作時可以修復您對建築物的訪問權限?

我會假設答案是否定的。您的密碼也是如此。即使您為所有服務都使用一個密碼(從來沒有發生過,我也承認這對我來說也是如此),但密碼永遠都不會與任何人共享。這是唯一可以驗證您自己身份的東西。這可能會打擾您不得不浪費時間在IT支持上,但這也可能使您長時間入獄。

因此,絕對是:

伸出手指是不必要的過度誇張,不是嗎?畢竟,在IT人員完成工作之後,您只需更改密碼即可,無法更改手指。
不,它並不誇張。擁有帳戶後,便擁有該帳戶-例如,根據所提供的服務和所提供的功能,用戶可以創建代理帳戶(例如,轉發電子郵件地址,輔助管理員帳戶等) 。授予他人“臨時”訪問您的身份的權限通常不是這樣。
不過,我可能會給他*手指*。)
-1
奇怪地使用了那裡的軼事...但是,用手指作為密碼,幾乎就像在任何地方都將密碼保留在便箋上一樣。
@Kevin,,但這與“借用”您的密碼不同...如果管理員重置或接管您的帳戶,則*正在審核*。另外,不要忘記諸如EFS,仍然無法更改用戶密碼。問題是這種思維方式“實際上是系統管理員就是上帝”,這是不正確的,也不應該是這樣:上帝不必證明自己的行為是合理的,系統管理員則是。
我們不會談論在哪裡進行審核的重置!但是提供您的密碼並不意味著審核。確實,管理員是上帝,但它是以他的名字做的,而不是您的名字(Linux和su上有一些例外)
-1
@AvID:審核有幫助,共享密碼的確不會發生這種情況,它不會否定我的聲明。證明自己的行為是在事實之後發生的,並且在安全方面,事後可能為時已晚。對於EFS的示例,除非您已禁用恢復代理,或者使用智能卡樣式的系統,否則域控制器的管理員可以獲取私鑰的副本並解密文件。由於在許多公司中,域管理員也是人機上的本地管理員,因此他們(至少理論上)可以繞過EFS。
這是一個可怕的類比。它試圖使讀者對變形的恐懼作出反應,並用它代替理性的論證。不同意?然後,將參數中的“手指”替換為“指甲剪”。突然聽起來還不錯...但是參數沒有改變。
您不應該將密碼提供給管理員,他應該具有不需要的足夠權限。但是,系統管理員可以合法地將服務中間人(他具有所需的證書,密鑰和網絡訪問權限),並以此方式獲取您的純文本密碼。
noktec
2011-07-22 03:51:15 UTC
view on stackexchange narkive permalink

之前已經解釋過,沒有人可以將密碼提供給管理員(我同意所有密碼),但是您應該與他的上司聯繫,這是怎麼回事,因為如果他詢問您的密碼,很可能他會詢問其他18個人的密碼(第19個人可能是他的上級),我很確定您的一些同事在各處都使用相同的密碼。

+1好點。與主管或政策核對,以查看管理員是否應詢問。
如果是這樣,很可能去更新這些政策...
Ormis
2011-07-22 18:31:57 UTC
view on stackexchange narkive permalink

簡短的回答,如果他是管理員,則永遠不需要您的密碼。最壞的情況是他需要重設您的密碼並給您一個新密碼(您將立即更改)。

除非有緩解措施,否則密碼/代碼/短語僅適合您。 (ei,如果管理員在您的PC上沒有特權帳戶)

我輸入了一些工作,長期的員工將擁有一台沒有管理員帳戶的一次性機器我可以在上面使用的,但是即使那樣,還是要讓用戶(假設他們有權)將管理員設為可以使用的特權帳戶,這是一個更好的解決方案。因此,即使那樣,我仍然很難想出管理員為什麼需要您的密碼的任何可行原因。得知用戶沒有管理權限,未連接到域以及設置該域的管理員已經十年沒有工作了,這總是令人沮喪的一天。

ps如另一個答案中所述,管理員可能習慣於從上級那裡得到“完成”處理,這可能導致他們只要求輸入密碼。

ps。如果密碼是管理員級別的密碼或管理員確實需要訪問的外部服務的密碼,則他確實需要密碼(或需要在該服務上為其創建的管理級別帳戶)。我的回答是從您的密碼來看。如果用於公司服務(即公司的網絡託管服務商),則不是“您的”密碼。即使這樣,還是最好每個人都有單獨的登錄名(出於責任/審計目的)。
RobertRay
2011-07-22 12:19:49 UTC
view on stackexchange narkive permalink

可能是時候挖掘出您的IT安全策略了。如果您的組織中有一個。如果不是,請抽空讓團隊坐下來給一支筆坐下來。如果沒有檢查每個請求的密碼,密碼肯定會增加組成帳戶的機會。

問責制引起的問題也令人擔憂。

肯定不是一個好習慣。

StupidOne
2011-07-22 13:08:27 UTC
view on stackexchange narkive permalink

密碼共享還有另一個問題。

如果您的帳戶或在登錄其他人時帳戶發生任何事情,您將被人負責。即使公司內部可以通過安全策略合法地(至少在我的國家/地區)通過密碼共享密碼,您還是會遭到指控的。

那很有意思;我對當地的法律不熟悉,但是在大多數地方,能夠證明別人有您的密碼(被盜或以“合法”方式提供)可能會導致嚴重的否認問題,即免除您的責任(-ish )的責任)。
我知道幾年前,有一個女孩把她的郵件帳戶交給了男友,然後男友發送了一些勒索郵件。儘管證明她沒有發送郵件,但她仍被判有罪。編輯:好吧,無論如何,即使您可以證明不是您,而且根據法律您也不會被判有罪,這仍然是令人不快的情況,您不同意嗎?
絕對,我完全同意這一點。
查看服務的“服務條款”,您將確認密碼是您的唯一責任。
當然是@Mvy,。但是,當您可以證明某人“其他”擁有它時,會發生什麼?是您的錯,您要承擔責任嗎?還是否認?
@AviD♦:取決於。我見過的大多數ToSes都說:“這是您自己的錯,只要您關心我們的密碼,就是*您*” –這可能是證明別人沒有密碼的又一個障礙。和往常一樣,IANAL。
HumanJHawkins
2018-02-10 00:04:13 UTC
view on stackexchange narkive permalink

要詢問的核心問題是:“管理員是否有必要要求輸入密碼?”顯然,它不必要。但是,讓我們將“必需”定義為“完成關鍵任務所必需的”。

使用這些參數,在安全基礎結構中存在嚴重/破壞性漏洞的情況下,可能需要公開密碼才能完成關鍵任務任務。在大型公司和政府中,我已經發現像這樣運行了多年的系統遭到破壞,然後才遇到它們。從保持操作運行的角度來看,是的,有必要在進行修復的同時繼續進行這種密碼洩露。

每種情況下的關鍵是記錄問題,記錄並清晰地傳達解決方案。在這種有缺陷的安全狀況下操作的風險,請從領導那裡獲得政策聲明,指示在什麼情況下進行修復時應暴露密碼,然後記錄下在糾正安全系統後繼續操作所必需的任何密碼暴露。

總之,它永遠都沒有必要。但是,如果確實如此,則可以通過將責任風險轉移到自己的責任,即由負責不合適的決策/基礎架構的一方來承擔責任。當然,如果沒有解決此問題的方法,則可能需要考慮繼續進行。

Ancient One
2015-01-30 07:37:30 UTC
view on stackexchange narkive permalink

也許..您對他們有多信任?您還在其他任何地方使用此密碼嗎?如果您使用的密碼與您用來訪問可直接操縱財務地點的密碼相同(或由其簡單衍生而來),那麼您最好信任系統管理員不要使用您的密碼來訪問那些區域。亞馬遜客戶服務:“先生,我們的日誌文件和審計記錄顯示,購買了1200份“ Sharknado 2”。”

您的便利性對您的安全性是否更為重要? ?“伙計...如果我不給sysadmin當前密碼,他們將對其進行更改,而我將不得不在手機的電子郵件設置中再次對其進行更改。BOGUS !!!”

密碼會讓您為別人所困擾嗎? (最喜歡的電視真人秀明星,說髒話,做愛姿勢...)

以上示例表明答案為“否”。但是...

系統管理員:“由於您決定使用該公司不支持的Truecrypt加密硬盤驅動器,因此,除非有您的解密密碼,否則我無法從筆記本電腦中恢復任何數據。”

因此,在每種情況下答案都不會是“是”或“否”。答案取決於周圍環境的原因。

然後..始終考慮一下,如果除您自己之外的其他人使用了您的密碼,可能會以某種方式傷害到您自己之外的人。機密服務:“總統先生!您將核發射代碼交給了那個小伙子???

答案不是“也許”,也不是合格的“不是通常”,答案是嚴格的“否”。如果您不明白原因,請參閱其他答案。老實說,這個答案已經存在了一年多,沒有人對此表示反對或評論,我感到很震驚。對於其他人,不要相信此答案,請閱讀投票率較高的答案
ddyer
2013-07-10 09:55:13 UTC
view on stackexchange narkive permalink

如果管理員試圖僅診斷您所遇到的問題,則可能有充分的理由“按您的方式”訪問您的帳戶,以有效地識別問題。如果可以輕鬆解決問題,則更有可能解決問題。

考慮一下,您的數據並不是sysadmin真正的秘密,因此,您真正要保護的只有密碼本身。如果您已經遵循良好的密碼衛生習慣,那麼只要您在完成密碼更改後再次進行更改就沒有任何價值。也不吸引人。

但是可以通過加密將數據保密,不是嗎?我不確定“後門”是什麼意思。正式地,Linux沒有後門;)
這與服務帳戶和收到的電子郵件有關。沒有單獨的加密(或者如果沒有的話,用戶密碼將是無關緊要的。)作為UNIX的root用戶,我可以更改您的密碼並以您的身份登錄。後門怎麼樣?
@ddyer:什麼是服務帳戶?
-1。 AviD [指出](http://security.stackexchange.com/questions/5539/is-it-ok-to-tell-your-password-to-your-companys-sysadmin#comment9163_5543)如果sysadmin重置您的密碼,它將創建一個審核跟踪,而如果您為sysadmin更改它,則沒有審核跟踪。不要共享您的密碼:相反,請您的系統管理員將其重置,然後診斷問題。


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