題:
如何安全地要求客戶提供諮詢公司的密碼?
Wim Deblauwe
2016-06-23 16:45:55 UTC
view on stackexchange narkive permalink

在作為開發人員的工作中,有時需要客戶提供用戶名/密碼組合,以確保第3方服務上的設置正確無誤,才能與我們正在構建的網站/應用程序一起使用。例如。我們在遊戲網站上使用的付款服務提供商。

什麼是詢問其用戶名和密碼以確保其安全的好方法?如果我確實給他們發送電子郵件,他們只是要給我發回帶有密碼的純文本電子郵件,但那是不安全的

更新:

我看到我的問題有點被誤解了,因此我將添加一個示例:

假設我是一家軟件公司CoolSoft的開發人員。另一家公司(我們稱它們為Games,Inc.)希望我們為他們創建一個網站。該網站將使用我們需要與之集成的第三方服務進行支付和客戶支持。 Games,Inc.與支付提供商和客戶支持提供商一起創建帳戶。但是它們完全不是技術性的,我們需要擁有其憑據才能設置正確的回調URL等。他們如何安全地將密碼發送給我們,以便我們可以更改其帳戶的設置(我們永遠不會親自見面)? / p>

人與人之間的接觸不合時宜嗎?
是的,確實忘記了提及。
雖然Philip的答案似乎不錯,但這並不總是可行的解決方案,因此您可以使用諸如oleksii之類的端到端加密應用程序。
剛剛注意到一個類似的問題:http://superuser.com/questions/21391/how-can-clients-easily-and-securely-send-me-passwords
一旦您了解了客戶的信譽,是什麼阻止他們將您將來在任何時候出現的任何問題歸咎於您?您真的不想要這些信息
我在這樣的第三方網站上工作,您絕對需要這些憑據來進行開發。我們要做的(因為這始終是我們的初始開發類型的工作)是在開發過程中使用一次性密碼。然後,作為產品移交的一部分,我們將引導客戶逐步接管憑據並設置自己的真實密碼。這消除了每個人都提到的因將來的行為而受到指責的問題。
@NeilSmithline嗯,事實上,他們在OP完成他正在做的事情后就立即更改了密碼,因為他們遵循理智的安全策略(例如理智的人)嗎?
請檢查您的網站以進行SQL注入。您的代碼聞起來。
您應該能夠在代碼中簡單地添加一個管理鉤子。就像一個隱藏參數`?adminlogin = true`,然後在用戶帳戶中輸入管理員密碼。SQL可以改為檢查管理員的密碼。
抱歉,您的榜樣使我不清楚。你能說清楚結局嗎?為什麼需要憑證?您為什麼要“修改他們帳戶上的設置”?
您的示例太抽象了。公司運動會做什麼?CoolSoft的網站是什麼?
“我們從不親自見面”也許你應該。在我看來,這部戲中演員太多。CoolSoft,Games,支付提供商,客戶支持提供商:已經有4個參與者,這太多了。我認為這是您問題的一部分。
我可以對我的`?adminlogin = true`建議作出回應嗎?
我對在這種情況下表示驚訝的人數感到困惑。是的,在理想的世界中,每個參與者都將是該站點的訂戶,並在解決方案上進行協作。但是這個問題對我來說似乎是完全合理的,因為“鑑於不幸的情況,我無法完全控制住該情況,如何將安全風險降至最低”。
舉一個具體的例子,考慮一個DNS控制面板。這些對於非技術用戶來說完全是莫名其妙的,但是作為部署的一部分,可能需要多次訪問。在理想情況下,DNS提供程序將允許臨時委派對第二個用戶名的訪問,但是在現實世界中,您將需要以某種方式登錄該控制面板。
八 答案:
Philipp
2016-06-23 17:05:58 UTC
view on stackexchange narkive permalink

你不知道。

當您教用戶將用戶名和密碼提供給某人時,您會訓練他們容易受到網絡釣魚或其他社會工程攻擊。

相反,設計系統時,管理員可以查看和編輯這些設置而無需用戶憑據。

當您確實需要查看內容時從用戶的角度對問題進行故障排除,請用戶輸入密碼,然後讓他們向您顯示問題。這可以親自完成,也可以使用遠程管理工具來完成。

當您遇到客戶擁有您的應用程序中需要的憑據以與第三方解決方案集成時,請在非技術用戶具有易於使用的用戶界面來設置這些憑據的方式。無論如何,您都將需要它,以防客戶需要更改它們而您不可用。

在應用程序部署到自己的服務器上之前,用戶無需輸入該信息。在開發過程中,您應該使用測試帳戶與第三方進行交互。您絕對不希望對客戶造成任何費用,因為您在第三方付款界面上進行了一些測試,結果與您的預期不符。

... 若有可能。即使在現代環境中,似乎總是會有系統帳戶,供應商管理員帳戶或最終共享的其他憑據。
我認為我的問題不清楚。我添加了一個示例,希望可以使其更加清晰。
@WimDeblauwe您的問題很明確,正確的答案仍然是“您不要”。如果您想對其進行測試,最好備份那裡憑據的哈希值...在那編輯密碼/ api密鑰...測試...然後恢復那裡的憑據。
@schroeder僅僅因為它一直在發生並不意味著它是安全的或最佳實踐。
在我看來,遠程管理工具將是您的理想之選,並且可以避免共享密碼。
-1
@ben遠程管理員不適合問題中的示例
@WimDeblauwe我更新了答案。我的結論沒有改變:您不需要用戶密碼,也不需要用戶密碼。
@schroeder肯定會這樣做,除非我誤解了“遠程管理員”的含義。我正在想像一個遠程桌面會話,就像我們的IT部門為企業網絡上的用戶在需要幫助配置某些東西時所做的那樣。用戶登錄需要訪問的任何內容,支持將引導用戶完成配置,或者只是控制並為他們完成操作。然後,通過電話,如果需要,支持人員可以指導用戶禁用或卸載所使用的任何遠程軟件。
@ben閱讀了Philipp的最新更新:第三方整合
當我讀到這個問題時,這是關於_____________成為沒有任何合適自己的僱員的公司作為承包商的管理員。如果系統具有公司帳戶和可以授予公司帳戶權限的單獨用戶帳戶,那就很好。但是某些系統僅具有帶有憑證的公司帳戶,因此無法傳遞這些憑證。
@JanHudec:,我將您的異議視為“沒有不合理的支出就沒有辦法”。天無絕人之路。但是需要雙方安裝遠程軟件或培訓人員,或向系統添加一個(原本未經計劃的)憑證管理組件可能會影響預算和/或時間。在這種情況下,具有安全意識的組織至少應了解更好的做法,並能夠向自己和客戶解釋他們正在做出的妥協以及如何最大程度地降低風險。
@NeilSlater,這裡有一個“第三方”。想想Google Play-他們允許現在授予其他帳戶的權限,但早期卻不允許。因此,僱用來處理它的承包商需要訪問權限,並且如果只有一組憑據,那麼承包商就需要它們。這裡的“不合理的支出”是“完全忘掉生意”。承包商和員工之間也沒有主要區別-公司需要有人信任才能擁有主密碼。
這很好地說明了我們的安全行業,投票最多的答案不是解決方案,實際上並沒有考慮很多情況。OP並沒有要求最佳實踐,而是要求一種安全地傳輸密碼的方法。
schroeder
2016-06-23 17:02:49 UTC
view on stackexchange narkive permalink

有許多“團隊密碼管理器”,允許團隊共享,更改和撤消對憑據的訪問。大多數都是有償的(或小團隊免費),但這可能是最好的選擇。它們通常提供加密以及對特定憑據訪問的訪問控制。

您可以舉任何例子嗎?
@WimDeblauwe,如果您使用Google“小組密碼管理器”,則可以選擇很多
例如,LastPass Enterprise。https://lastpass.com/enterprise_overview.php
1Password也有一個基於雲的團隊。https://1password.com/teams/
[CyberArk PIM](http://www.cyberark.com/products/privileged-account-security-solution/enterprise-password-vault/)適用於大型組織。
HopelessN00b
2016-06-23 20:08:16 UTC
view on stackexchange narkive permalink

我看到的唯一可行的選擇(還沒有提到,很奇怪)是讓客戶端設置帳戶具有適當的權限,以供您在這些系統/互聯網服務上使用。這樣,他們可以處理供應商關係和付款,但是您擁有的帳戶具有所需的訪問權限。

正如Phillip的回答所述,您根本不要求也不參與在共享密碼。到處都是不好的,因為如果別人使用共享帳戶時出現問題,您就應該責備自己。 (“我知道我的員工永遠不會做這樣的事情,而且您是我們唯一與之共享密碼的人,所以它一定是您 所做的一項! !“)

完美的答案,我還要補充一點,如果要交換密碼,則需要修改SLA,我永遠不會讓任何人在沒有法律約束力的情況下擁有任何密碼。並且,與工作相關的特權較低的帳戶丟失憑據的好處不會像丟失原始憑據那樣有害(如果這種情況曾經發生,上帝禁止)。
從概念上講,這是一個好主意,但它仍然會向客戶提出可能難以實現的要求。它仍然需要客戶端方面的一些技術知識。
@Ijustpressbuttons設置用戶帳戶通常不是技術過程。認為這是繁重要求的客戶將是一場噩夢。
@HopelessN00b當然,這取決於他們在其中設置帳戶的系統?某些系統根本無法創建其他登錄名或委託訪問權;其他人將具有需要導航的複雜權限系統。就像這裡的許多答案一樣,這似乎取決於影響第三方安全協議以規避問題的能力。充其量,它可能會列在“在繼續操作之前先耗盡這些可能性”的列表中。
@IMSoP那裡確實有很多垃圾,當然,很難設置新用戶/帳戶的“雲” /網絡/任何服務(與網站集成的第三方服務)是一種特殊的垃圾。就像同時吸煙和抽氣。是的,您通常可以找到一種使其工作的方法,但您*確實*不應該這樣做。如果您的供應商如此糟糕,請運行。
我強烈反對@HopelessN00b。大多數係統的默認權限模型是您註冊一個帳戶,該帳戶“擁有”其中的所有內容。創建子帳戶或將對您的配置的訪問權限委派給其他帳戶的功能非常少見。如果您拒絕了某人選擇了一家不盡人意的供應商的每份合同,那將使您失業。
Falco
2016-06-24 13:59:42 UTC
view on stackexchange narkive permalink

我將情況總結如下

  • 您需要使用客戶帳戶訪問第三方服務
  • 親自見面並不容易
  • 不需要客戶端安裝軟件或遵循複雜程序的解決方案

我認為最好的解決方案是:向他們發送新密碼

您請以安全的方式向他們發送密碼,並給他們指示(通過電話?),以將他們帳戶上的密碼臨時設置為您建議的密碼。 -然後您可以使用它登錄頁面。完成後,他們可以將密碼重置為原始值。

一種簡單的方法是在郵件中建立一個一次性鏈接,該鏈接會導致顯示密碼的頁面。客戶端可以單擊它,複製密碼。攻擊者將無法訪問相同的密碼鏈接。 (通過更改郵件內容仍然可以進行有針對性的MitM攻擊,並且可以通過對郵件進行簽名來減輕這種攻擊)

您還可以通過電話告訴他們臨時密碼,然後寫下並更改密碼

這種向後的方式有很多好處:

  • 您的客戶可以遵守“永不共享密碼”規則
  • 您可以選擇一種安全的方式來中繼密碼,而不必教您的客戶一種安全的方法。
  • 您的客戶始終可以控制授予和撤消您的訪問權限
HashHazard
2016-06-23 17:02:31 UTC
view on stackexchange narkive permalink

從字面上看,有許多解決方案可以安全地傳輸數據(例如憑據)。

  • 如果客戶端支持PGP / GPG加密,則可以交換公鑰並加密電子郵件
  • 也有專門從事SecureMail(ZixCorp)的公司,或者您可以購買您自己的(Cisco Ironport)。
  • 如果您有協作網站(例如,客戶的客戶門戶),他們可以將憑據上載到門戶。 FYI Alfresco是一款出色的免費軟件應用程序。
  • 即使無法與人接觸,您也可以發短信嗎?也許他們可以發送密碼短信,並通過其他渠道提供用戶名。
  • 如果其他所有方法均失敗,則煙霧信號和蝸牛郵件仍然存在,但上述方法是最常見的媒介。
除非您通過Signal等應用程序進行操作,否則文本是不安全的
我確切地說@rhymsy為什麼只發送密碼。帶有混亂字符(通常通過MMS圖片而不是實際字符)且周圍沒有上下文的文本對攔截器沒有任何幫助。
@rhymsy-這尚不清楚。我們可以通過App Signal發送短信嗎?
@Hollowproc-如果攔截器想要攔截密碼,那麼無意義字符的文本對於攔截器來說是完全有意義的。對於密碼,我喜歡規則“永遠不要寫” **,我建議您使用電話。我們甚至可能會偏執,將通訊分為幾個電話。從/到不同的電話,從/到不同的人...
正如OP所說,@NicolasBarbulesco在這種情況下不能選擇電話。“信號”解決方案還意味著您正在信任第三方“正在加密”的SMS / MMS消息的內容;一條沒有上下文的簡單文本消息就足夠了,因為截取它們比您想像的要難,並且需要附加的內容和已經存在的危害程度,這可能會使通過其他方式獲取此密碼變得微不足道。誠然,沒有什麼是完美的,但這是計算得出的風險。在這種情況下,存在風險,但是恕我直言。
@Hollowproc-為什麼不能選擇電話?這很奇怪。
@NicolasBarbulesco擊敗了FOM,但這就是OP在“問題”下的評論中所說的: 人與人之間的接觸不合時宜嗎?– MadWard 6月23日11:49 是的,確實忘記了提及。– Wim Deblauwe,6月23日,11:50
@Hollowproc-什麼是FOM?
F ***離我遠點..哈哈
@Hollowproc-我知道“人際交往”是人類的會議。電話在公司業務中很常見。如果真的不能使用電話,那麼這是一個應該解決的問題,或者可以通過逃離那個噩夢計劃來避免。
@NicolasBarbulesco,我也對問題的周圍細節有自己的看法(所以+1),但是我試圖保持中立並指出所提出的問題。
Bill
2016-06-23 20:19:16 UTC
view on stackexchange narkive permalink

保持簡單,但只使用兩種通訊方式。例如,在一封要求提供憑據的電子郵件中,要求他們僅使用用戶名答复,然後在您的電話號碼中輸入臨時密碼。獲得憑據後,請盡快將臨時密碼更改為其他密碼。

是的,從理論上講,有人可以看到電子郵件並破解SS7來獲取密碼,但是如果他們能夠做到這一點,那麼在您更改臨時密碼之前,無論如何您都會被偽造。

我不明白你的最後一段。也許您應該重寫它。什麼是SS7?
@NicolasBarbulesco: google first hit = https://zh.wikipedia.org/wiki/Signalling_System_No._7是一種不太安全的協議,用於電話系統,包括處理短信的蜂窩/移動系統。因此,破解SS7(系統)以獲取文本(包含密碼)。
sidewaiise
2016-06-25 06:54:59 UTC
view on stackexchange narkive permalink

您不應該對響應特定的用戶名/密碼進行硬編碼的回調。如果您使用的是第三方工具,則應為其設置這些帳戶並通過API令牌與這些工具進行交互。更好的做法是創建帳戶,最後將所有帳戶憑據分配給客戶。

OP並非旨在將用戶名和密碼存儲在任何地方;他們旨在個人登錄,以便在應用程序部署的一部分中在某些第三方控制面板中配置技術細節。設置新帳戶並非總是一種選擇,因為這些帳戶可能是需要附加新功能的現有付費帳戶。
bortzmeyer
2016-06-27 00:18:22 UTC
view on stackexchange narkive permalink

奇怪的是沒有人提到 OAuth,乍一看,它是解決該問題的完美解決方案,正如更新後的措辭所述。

OAuth是需要第三方系統供應商部署的解決方案;OP並不希望訪問他們自己設計的系統。


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