題:
最大密碼長度太短的技術原因是什麼?
enderland
2013-03-31 02:30:37 UTC
view on stackexchange narkive permalink

我一直想知道為什麼這麼多的網站對密碼長度(確切地說是8個字符,最多8個字符,等等)有非常嚴格的限制。這些往往是銀行或我真正關心其安全性的其他站點。強制這樣做的原因?使用1Password這樣的應用程序,幾乎我所有的密碼都是 fx9 @#^ L; UyC4 @ mE3<P] uzt 或其他隨機生成的不太可能猜到的長字符串。

  • 網站是否對密碼長度實施嚴格限制(是否更具體,例如8或10,我理解為什麼100000000可能是個問題...)?
我必須補充一點,安全密碼也可以是“正確的電池釘”。沒有任何理由,我只能告訴您與仍執行此規則的網站聯繫。
@s4uadmin不,“正確的胸式電池裝訂”是不安全的,因為它廣為人知,並且很可能存在於字典攻擊中。另外,嘗試在DropBox上使用此密碼嗎?
@AlvinWong我相信s4uadmin提供了一個眾所周知的示例,而不是建議有人實際上選擇“正確的馬電池釘”作為自己的文字密碼。
@JeffFerland是的,我的評論“字面意義上”回復了s4uadmin,而您的“形象化”回復中。我自己*使用*長密碼,但不使用“ correcthorsebatterystaple” ...
@s4uadmin:沒聽說過字典攻擊,是嗎?
@AlvinWong,來自Dropbox的javascript源代碼,這是一個東方蛋:`if(pwd =='correcthorsebatterystaple'|| pwd =='Tr0ub4dour&3'|| pwd =='Tr0ub4dor&3'){// Easteregg [...]`
Mehrdad,此處無法進行字典攻擊。除非您的字典中有諸如Correcthorsebatterystaple之類的詞
別忘了,黑客現在將“正確的馬力電池釘書釘”作為其蠻力清單上的“第一”條目:)
我並不是要說我贊成這個想法,而是要求我使用易於記憶的密碼,因為寫下來會帶來安全風險。這可能是使其簡短的技術/人為原因。我不同意,因為到了有人將您的書面密碼或可能保存了文本文檔的地方拿到手時,您的安全措施就已經失敗了。
一年前,我問一個這樣的機構,它的最大密碼長度很短。他們對我的回應:“在我們的風險管理部門進行評估時,確定最大10個字符的密碼就足夠了。”
同樣,為什麼網站會限制可以在密碼中使用的字符類型,例如,沒有標點符號“!@#%”等??
我的假設:因為密碼以明文形式存儲在“ varchar(10)”數據庫列中
@Ryan一個“暴力列表” ...所以至少他們必須在以前嘗試單詞列表(字典)。:-D
我的大學的密碼最大長度限制為16個字符。因此,當我到達時,我輸入了16個字符的密碼。然後我嘗試登錄到他們的VPS,但無法正常工作(每次都死了,沒有錯誤)。IT一直無法弄清楚。最終結果是因為他們用於VPS的Cisco路由器最多只能處理12個字符的密碼...因此,如果我想使用VPS,我的有效上限現在是12個字符。
剛在Dropbox上嘗試過“ correcthorsebatterystaple”作為密碼,它實際上讓我註冊了。傷心。
十四 答案:
Tom Leek
2013-03-31 02:48:46 UTC
view on stackexchange narkive permalink

取五隻黑猩猩。將它們放在一個大籠子裡。從籠子的頂部懸掛一些香蕉。為黑猩猩提供梯子。但是,還向香蕉添加了一個接近檢測器,以便當黑猩猩靠近香蕉時,水管被觸發,整個籠子都被完全浸泡。

很快,黑猩猩就會知道香蕉和梯子。最好忽略掉。

現在,刪除一隻黑猩猩,然後換上一隻新的黑猩猩。那隻黑猩猩對軟管一無所知。他看到了香蕉,注意到了梯子,並且由於他是一個靈巧的靈長類動物,他設想自己會踩在梯子上到達香蕉。然後,他巧妙地抓住了梯子……而另外四隻黑猩猩則向他撲來,並正直擊敗了他。他很快學會了不理梯子。

然後,移開另一隻黑猩猩,並換上一隻新的黑猩猩。該情況再次發生;當他抓住梯子時,就被另外四隻黑猩猩所傷-是的,包括以前的“新鮮”黑猩猩。他已經整合了“不要觸摸梯子”的概念。

迭代。完成一些操作後,您將有五隻黑猩猩準備打孔任何敢於碰梯子的黑猩猩-而且他們都不知道為什麼。


最初,某個地方的某個開發人員正在工作在上個世紀的舊Unix系統上,它使用了舊的基於 DES的“ crypt”,實際上是從DES分組密碼派生的密碼 hashing 函數。在該散列函數中,僅使用密碼的前八個字符(也僅使用每個字符的低7位)。後續字符將被忽略。那是香蕉。

互聯網上到處都是黑猩猩。

哦,我以為熊們正在接管互聯網...
我也喜歡這個故事。絕不讓事實妨礙良好的道德故事:http://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and-水噴霧condu :)
在做出此答案期間,幾隻黑猩猩受到了傷害。 (順便說一句,喜歡這個解釋!)
有沒有證據表明這確實是原因?例如。有沒有人真的問過設計密碼最大長度的系統的人為什麼這樣做呢?
根據答案的性質,黑猩猩開發人員應該不再在那裡。
簡單的解決方案...讓我將密碼設置為所需的密碼,然後在提交密碼時將其截斷。至少給我一種幻想,那就是我實際上是在選擇密碼。再說一次,您將無法執行數字和奇怪的字符規則(我認為這是件好事)
@Joe震撼了我對服務的信心。切勿以純文本形式存儲密碼。您願意看到這個嗎? http://thenextweb.com/microsoft/2012/09/21/this-ridiculous-microsoft-longer-accepts-long-passwords-shortens/
提交時@kush的截斷不會阻止哈希,儘管哈希確實刪除了提交時的截斷點。
..那就是香蕉……我還要指出,使用前8個字符的DES-crypt是水管。為了使故事更完整,您應該卸下水管,看看誰敢再挑戰一次...
換句話說,現代算法可以正確實施,並且除了使它不完全瘋狂之外,完全沒有理由要設置最大密碼限制(讓我們說一個1MB長的密碼?)。舊的Windows NT LANMAN散列也存在類似的問題,最多可以將14個字符分割成2x 7個字符的密碼,並且不加鹽地進行哈希處理。
這就是為什麼您不應該記錄如何的原因,而是為什麼的原因。這適用於所有規則。
我在@LarsH。我們確定所有這些實際上都可以追溯到crypt函數嗎?
@LarsH和Kevin,哇?!您實際上是在_思考嗎?不不不,您應該盲目投票並同意。有點諷刺意味,您會看到,您將無法獲得答案,您的行為會像答案中的黑猩猩一樣。
@LarsH:一天,我問了一個黑猩猩(電話上用於重設密碼的2級技術支持),為什麼密碼必須是6位數字且沒有更多(無字母),由系統生成並通過未跟踪的紙質郵件發送。答案是“我們是銀行,不能承擔任何安全風險”。放棄香蕉。
您甚至可以取下水管,黑猩猩仍會碰觸任何踩踏梯的人。
“那是香蕉。”香蕉是什麼,`crypt()`會在前8個字符後忽略任何字符的事實?這似乎與類推並不相符,香蕉是每個人都能看到的獎勵,但是傳統上黑猩猩已經學會了不要追隨。在我看來,香蕉就像是“通過允許更長的密碼來提高安全性”。傳統的“ crypt()”的局限性可能是“水喉”而不是香蕉。 (類比與現實之間的對應關係當然是假設的。)
@PPC傳聞證據FTW !!
黑猩猩如何進入管子?
天哪,網上到處都是黑猩猩。僅作記錄,我目前正在一個項目中,為擁有40,000個用戶和許多應用程序的客戶端刪除密碼的8個字符限制。事情並不像你們中許多人想的那麼簡單。是的,crypt()限制是8個字符限制的基本原因。需要Crypt才能支持舊版應用程序。最初施加8個字符的限制很有意義(CPU,網絡,I / O速度)。
我已經在此站點上創建了我的帳戶,只是為了支持您的回答。很棒的解釋!先生,您真是個天才!!
b ..但是,我以為我的銀行將我的字符數限制在8個以內
@LeoKing這是security.stackexchange,所以人們不僅止步於666,他們的目標是[強壯的素數](https://en.wikipedia.org/wiki/Strong_prime)。
相關:http://skeptics.stackexchange.com/questions/6828/was-the-experiment-with-five-monkeys-a-ladder-a-banana-and-a-water-spray-condu
與宗教的運作方式相似。讓我微笑。感謝您的驚人比喻。
+1;上次我聽到這種解釋時,它的結尾是“這就是我們所說的《公司政策》”。
Polynomial
2013-03-31 02:49:54 UTC
view on stackexchange narkive permalink

這些限制通常是出於各種原因而設置的:

  • 與不支持長密碼的舊系統的交互。
  • 公約(即“我們一直做到這一點”)。
  • 簡單幼稚或無知。

就安全性而言,無需限制密碼長度。無論如何,應該使用諸如bcrypt之類的KDF對它們進行哈希處理。為了提高性能,可能有必要對密碼長度設置一個非常大的限制(例如512個字符),以防止有人向您發送1MB密碼並在計算哈希值時拒絕您的服務器10秒鐘。

值得一提的是,良好的密碼哈希函數不會受到密碼長度的很大影響。對於與HMAC一起使用的PBKDF2,密碼為HMAC _key_,因此,通過應用HMAC,首先將其規範化為一個內部塊(通常為64個字節)以下的值。由於密碼非常長,要獲得10秒的額外CPU工作時間,該密碼應該大約為1.5 GB,而不僅僅是兆字節。
是的,可能會比CPU早得多地分配帶寬
沒有哈希函數可以使諸如“ asdfhjkl”之類的密碼安全。
-1
@Kaz如果加鹽怎麼辦?
@Polynomial bcrypt只會使密碼長度對第一次迭代IIRC上的CPU時間有任何影響,然後它只是1MB數據的單個哈希(您的服務器對1MB的哈希速度慢嗎?)。我認為帶寬更多是一個問題。
@JoePhilllips: Salting並不能從本質上提高密碼的安全性,只能防止離線攻擊。即使這樣,只要您知道密碼,只有八個字符的“ asdfhjkl”這樣的密碼也很可能會破解。 Salting根本不能幫助單個密碼,但是它使一次迭代就無法檢查一組密碼,從而極大地保護了整個數據庫-您需要為每個用戶進行檢查。單個密碼仍然很弱並且容易被破解,但是前提是它們足夠重要,可以打擾目標用戶。
談到Mega和Giga系列中的密碼問題,為什麼不僅僅使用文件作為密碼?我相信某些地方會用到它(truecrypt也會這樣做)
密碼短語中的每個字符都會對哈希值產生一定的熵。但是,如果散列最終是一些N位字符串,那麼如果密碼短語具有超過N位的熵,則它是多餘的。讓我們舉一個荒唐的例子。假設哈希為16位寬,您使用的是一個1兆字節的密碼。破解者很可能會發現一些很短的字符組合,它們會產生相同的哈希,因此可以代替您的一兆密碼。相對於哈希函數的強度,肯定會減少一些密碼長度以外的返回值。
@Kaz:您的語句“密碼短語中的每個字符都會對哈希值造成一定的熵”並不總是正確的:由於字典攻擊,與添加最後一個E相比,“正確的騎馬釘”是一個(不太糟糕的)密碼
@PPC密碼質量!=密碼熵。熵是純粹的統計量度。
什麼-沒有黑猩猩?
您可以在原因列表中添加“我們的客戶太愚蠢而無法記住長密碼”。並不是說他們是愚蠢的,只是這樣認為。
“就安全性而言,沒有必要限制密碼長度。無論如何,都應該使用諸如bcrypt之類的KDF對它們進行哈希處理。”請注意,bcrypt的上限為72個字符;它只是忽略了除此之外的任何事情。
SztupY
2013-03-31 02:52:09 UTC
view on stackexchange narkive permalink
  1. 如果他們將其存儲為純文本或加密的純文本,則可能是可以存儲在數據庫中的最大值。另一方面,應該盡可能遠離這些站點
  2. ,以避免DOS攻擊。通常,如果它們有一個很高的限制(例如512或1024字節)
  3. ,以遵守實際上不了解IT安全性的人們制定的法規
  4. 出於傳統原因,正如湯姆·里克(Tom Leek)指出的
  5. ol>

    順便說一句。這是具有最大密碼長度的高等級站點的(歷史)列表:

    http://web.archive.org/web/20130907182806/https://defuse.ca/password- policy-hall-of-shame.htm

基於此:密碼越長,散列的成本就越高。這是一個令人毛骨悚然的論點,因為使用[PBKDF2](https://en.wikipedia.org/wiki/PBKDF2)對128個字符進行哈希處理比對8個字符進行哈希處理所花費的成本微不足道,從而使任何[DoS](https:// zh_cn.wikipedia.org/wiki/Denial_of_service_attack)風險(僅從pw長度開始)。更糟糕的是將密碼存儲為純文本格式,儘管這可能會引起存儲問題。我全都限制密碼長度,但我認為沒有理由將密碼長度限制在一百以下。
順便說一句,值得指出的是,所有密碼的長度都是有限的。即使表單允許無限制的字符,Web服務器也幾乎可以設置為具有最大POST負載大小。即使未將Web服務器配置為拒絕請求,最終您的瀏覽器和/或PC也會用盡內存來存儲密碼。當然,大多數普通人都不會嘗試輸入超長密碼,但是-特別是對於像銀行這樣的高價值目標而言-值得他一籌莫展的開發人員應該能夠告訴您該限制是什麼,以及當發生什麼情況時它受到打擊。
Luc
2013-03-31 18:45:27 UTC
view on stackexchange narkive permalink

我在Bol.com(荷蘭最大的網上商店之一)問了這個問題。他們的回應是防止充斥有關忘記密碼的支持電子郵件。然後他們好奇地忽略了我對密碼重置功能的詢問,該功能只是在您忘記密碼後通過電子郵件發送給您重置密碼。

我得出的結論是,這很可能是管理團隊的決定。另外,也可能是他們不對密碼進行哈希處理,並使用此密碼來防止其數據庫被淹沒(即使您可以使用更長的用戶名,所以這似乎不太可能)。他們也沒有回答有關是否對密碼進行哈希處理的問題(您會認為,如果一切正常,將沒有理由不予答复)。

我的超市(網上購物)也以同樣的理由小跑。完全荒謬,並且由沒有安全概念的人清楚地實施。
看起來其中一些黑猩猩在Bol.com上找到了工作:-)
哈哈,德國公司Telekom:D基本相同
MDR
2013-03-31 03:56:48 UTC
view on stackexchange narkive permalink

我會嘗試減少與客戶服務相關的問題。

密碼越大越複雜,客戶輸入無效密碼,被鎖定然後聯繫客戶服務人員佔用該時間的可能性就越大。

令人驚訝的是,有多少人無法準確鍵入普通的弱密碼,更不用說密碼長了幾個字符或者必須輸入一個額外的字符或輸入2個字符才能獲得複雜性。

可能是OT,但是長密碼並不一定是真正的安全措施,因為在當今相當普遍的基礎上,密碼是被直接盜用的。

失敗的登錄嘗試和跟踪與正常登錄使用情況的地理距離是更準確的指標。如果屬於已知的高黑客/攻擊配置文件國家/地區的IP登錄到美國銀行,並且以前從未在該位置使用該登錄名.....

很多高知名度的地方,例如SF / bank通常失敗登錄嘗試次數很少,從而導致整個系統範圍內的鎖定。諸如SF之類的工具甚至可以進行單獨的IP分配,這意味著您不能未經授權就從新IP地址登錄。

這可能是這種想法,但是恕我直言,這種思維方式存在嚴重缺陷。為什麼因為某些用戶更喜歡短密碼,為什麼選擇使用長而安全的密碼呢?密碼重置通常不涉及客戶服務干預。另外,如果密碼*可能“被盜”(例如,它們以純文本格式存儲),那麼您這樣做是完全錯誤的。
根據我的經驗,沒有正確輸入/記住密碼的客戶確實會通過電子郵件和電話捆綁客戶支持。通過密碼被盜,我指的是數以百萬計的帶有特洛伊木馬程序/密鑰偵聽器以及大量網絡釣魚企圖的僵化計算機。賽門鐵克幾年前就發布了#個被盜密碼。
@MDR:如果不允許他們使用更長或更強的密碼,則很容易破解他們的密碼,並且他們會再次獲得客戶支持。而且,如果用戶“忘記”密碼,為什麼要尋求客戶支持,如果您的網絡服務提供了“忘記我的密碼”功能。
好的答案,但是為了取悅“即使長密碼也能發明長密碼的用戶,然後忘記密碼並打電話而不是使用密碼重置”的用戶,您將“使用長密碼的用戶拒之門外”在密碼管理器中”。愚弄一個無休止,毫無意義的任務,所以最好教育健忘的團隊並培養明智的團隊。這就是恕我直言,為什麼較小的密碼長度限制是一個嚴重缺陷的想法。
@SaiManojKumarYadlapati:如果密碼可以強制執行,則說明系統存在缺陷。此外,如果密碼可以通過鍵盤記錄器/僵化計算機竊取(這是非常有規律的),並且可以訪問“關鍵”信息,則這也表示系統存在缺陷。
@Anthony:不錯,但是我認為這是理論上的觀點。我知道我們公司為“客戶關係”工作了幾個人。我知道,客戶致電或發送電子郵件給我們的與業務特定問題無關的2大原因均與登錄有關。第一個原因是“他們使用錯誤的電子郵件地址註冊了”第二個原因是他們無法輸入密碼/忘記了密碼。而且,儘管我100%同意您所說的話,但我的專業經驗(在沒有任何大型銀行的情況下)表明,此問題可能會使企業主付出金錢。
@MDR:系統廣泛的鎖定和單獨的IP分配等功能不是功能,而是對某些試圖破解其帳戶的真實用戶的懲罰。抱歉,在之前完成我的評論之前,我失去了互聯網連接。
嗯“由於用戶太愚蠢而無法安全地完成密碼”是一個絕望的委員會。震驚地在銀行看到它。
還有一個問題:支持用戶需要花費金錢。我們知道這一點。但是您確定如果您允許使用更長的密碼會增加成本,還是只是迷信?有什麼證據?您正在做的事情是降低(也許)降低日常成本,但同時也增加瞭如果您的密碼數據庫被洩露,在黑客彩票中損失慘重的機率。您有一個儲蓄(也許),但是需要將其與其他成本進行權衡,否則這是虛假的經濟。
我已經在嵌入式註釋中解決了所有這些問題。
當然,不必減少最大大小。只是不要設置最小值。使用較長密碼的人大概可以更好地記住它們(例如,使用密碼管理器或某種模式)。我以為密碼較短的人會使用較短的密碼,以便更好地記住它們(不過,這確實使它們很容易受到蠻力攻擊)。
我看不出如何迫使用戶不要使用他們認為很容易記住的難忘密碼。
user2228243
2013-03-31 05:16:25 UTC
view on stackexchange narkive permalink

“與不支持長密碼的舊系統進行交互”。如上所述,這就是我工作的一家公司必須強制使用最大密碼長度的原因。

作為“網上論壇”的一種變體,“一個小組的行動與其最慢的成員一樣快”,使用了多個系統用戶必須有權使用相同的登錄憑據,這意味著必須將這些系統之一的任何限制應用於所有帳戶。

因此,如果一個應用程序沒有不喜歡^,那麼所有系統的所有密碼都不能使用^。如果一個程序不喜歡密碼> 8個字符,那麼所有帳戶都必須具有密碼< 9個字符。因此,在像BigCo這樣工作的複雜環境中,這可能涉及十幾個或十二個不同的軟件。 LCD是每個人都能得到的。

他們也使用IE6。

我大笑你的最後一句話。
成員較慢的團隊確實需要背後的獅子來保持動力。
IE6安全性在後面算得上是獅子嗎?
@SargeBorsch更籠統的說法是,對於某些x,y值,它確實在y中算作x。
-1
Omer van Kloeten
2013-03-31 12:30:28 UTC
view on stackexchange narkive permalink

我想解決的另一種尚未解決的可能性是,當密碼以純文本格式保存時,密碼有時會受到用於保存密碼的字段長度的限制。如果您的字段是VARCHAR(32),則最多可以保存32個字符。

但是,這意味著更糟糕的是-密碼以純文本格式保存。這就是為什麼我們在 plaintextoffenders.com上將這類違法行為作為(輕量級)證據接受的原因。

這個。如果它們對密碼進行哈希處理,則它們的長度都是相同的。因此,如果一個站點說“最大長度X個字符”,我認為它們要么是1)存儲純文本,要么是2)使用無意義的驗證。 #1似乎更有可能。
電子郵件證明中是否顯示密碼以純文本形式存儲?發送電子郵件後,他們不能散列並存儲它嗎?並不是說它們是當然的,而且我認為在電子郵件中發送密碼可能是不安全的,這是出於另一個原因,但至少看起來似乎不是確定的證據。
電子郵件從定義上說是一種不安全的媒體,因此不明智。更不用說人們可能永遠也不會刪除電子郵件,並且有權訪問其郵箱的任何人都可以查找“ password”一詞並立即訪問其帳戶。
dr jimbob
2013-03-31 04:22:25 UTC
view on stackexchange narkive permalink

密碼長度限制是合理的,只要該限制仍允許使用強密碼短語;例如,限制不得少於64個字符。設置密碼時的聲音限制比靜默截斷密碼要好得多。

如果應用程序最終將密碼存儲為128位(希望添加了鹽和鍵值),則允許更長的密碼沒有任何好處超過64個字符。例如,如果Diceware密碼短語包含5個字符的單詞,單詞之間有空格,則64字符的密碼短語允許10個單詞的熵超過128位。

開發人員可能會擔心SQL注入或通過密碼字段注入的緩衝區溢出攻擊-應當使用標準方法來防止這些攻擊:始終將綁定參數與SQL結合使用(相對於字符串操作來構造查詢),並且始終正確地對字符串進行邊界檢查(可能使用安全編程)語言或帶有內置保護的安全庫)。您需要擔心所有用戶輸入上的這些攻擊。這不是密碼字段唯一的,因此通過最大密碼大小獲得的保護可能可以忽略不計。

限制也可能與切線原因有關。向用戶提供帶有PIN(個人識別碼)的ATM卡的銀行可以選擇強制用戶使用4到10位數之間的PIN。在實踐中,允許用戶設置和使用50位PIN的安全性可能比說8位PIN的安全性提高小-當攻擊者同時需要用戶的ATM卡(尚未被盜)時,請使用受監控的自動櫃員機,並在4次錯誤嘗試後被鎖定。 50位數的PIN可能會給您的銀行帶來更大的人工成本,因為它會更頻繁地被錯誤地忘記/輸入-可能會觸發員工進行調查(例如,檢查ATM視頻並與以前的成功交易進行比較)或員工引導客戶通過一些必定冗長的密碼重置機制(例如,重置機制必須昂貴,因此它並不是最薄弱的環節)。這整個過程可能導致不良的客戶用戶體驗,銀行希望避免這種情況。

Steamstore的上限為63個字符。我想避免長/整數溢出
Joseph Scott
2013-03-31 10:38:59 UTC
view on stackexchange narkive permalink

正如其他人已經指出的那樣,出現8個字符或更少字符的主要原因是處理不支持更長字符的較舊系統。

然後,人們普遍認為為合理設置一些上限。可以說是500個字符。認為提供密碼超過500個字符的任何人都不是很好,這不是沒有道理的。

但是,即使您使用的是當前推薦的密碼哈希系統,仍然存在限制。 Bcrypt已被廣泛使用,據我所知,通常認為散列密碼是一個很好的選擇,但只能處理前72個字符。超過72個字符的所有字符都將被丟棄。如果我的密碼長度為100個字符,而您的密碼為150個字符,則如果它們以相同的72個字符開頭,則bcrypt會認為它們相同。

鑑於bcrypt中的特定限制,如果您使用的是bcrypt,則可能需要強制使用72個字符的限制,以確保您的身份驗證系統實際上將所有唯一密碼視為唯一。

“以確保身份驗證系統實際上將所有唯一密碼視為唯一。”抱歉,您不能。這就是為什麼我們使用加密強度高的哈希值。
我認為沒有任何理由執行一個規則,即每個用戶都應該具有唯一的密碼。兩個不同的用戶可以很好地擁有相同的密碼。bcrypt丟棄所有超出前72個字符的唯一缺點是,任何試圖破解密碼的人都只能嘗試最大長度為72的字符串,即,即使我將密碼設置為100個字符長,額外的28個字符也不會給出我還有其他安全措施。
sharp12345
2013-04-03 00:03:34 UTC
view on stackexchange narkive permalink

許多站點都認為不需要長密碼,因為有蠻力保護(例如限制每個IP的登錄嘗試次數),長密碼和短密碼的區別不大,在兩種情況下都需要年嘗試所有可能的組合。

一種建議是使用長字符為AZ 0-9的隨機字符(!@#$%^ & * -_ = + / \'“)。

根據RDBMS的不同,其中一些其他字符可用於SQL注入,並希望最終在清除輸入參數時將其省略,因此我在不提及允許的字符可能有所不同的情況下,不建議使用它們,而應與警告。
Joachim Wagner
2015-07-30 15:32:40 UTC
view on stackexchange narkive permalink

Jet的另一個原因是用戶界面設計和總體用戶體驗:對於許多用戶來說,當輸入字符達到可見長度時,由於每個字符都顯示為星號或大點,這並不怎麼回事。這可能會使用戶感到困惑並引起負面情緒(不太可能買東西,回來或將其推薦給朋友)。技術解決方案是可能的,但是限制長度例如,僅是更容易。最多20個字符,這樣光標就永遠不會到達輸入字段的末尾。

Daniel Miessler
2013-03-31 10:03:43 UTC
view on stackexchange narkive permalink

我要說的主要原因有三個:

  1. 舊版系統不支持特殊字符
  2. 希望減少支持開銷,並提高系統利用率,使用戶的密碼實際上可以記住。換句話說,如果您讓用戶製作和使用他們不記得的密碼,他們將因此而煩惱您,或者由於麻煩而停止使用該網站
  3. 開發人員不必擔心從不受信任的用戶那裡解析特殊字符,這可能很危險
  4. ol>

    在過去,最主要的原因可能是缺乏功能支持密碼(#1),今天可能缺少 desire 來支持它們-主要來自#2,但部分來自#3。

Christophe Franco
2013-03-31 10:20:44 UTC
view on stackexchange narkive permalink

受其他限制(通常僅接受數字)的限制,它也可以由以下事實激發:它允許(或可能允許,如果有一天需要的話)通過容量有限的某些界面輸入密碼...

這就是為什麼許多銀行都對Web訪問密碼設置了此類限制,以允許通過僅具有數字小鍵盤(ATM,電話...)的舊系統進行訪問的原因

HopefullyHelpful
2015-07-30 21:34:06 UTC
view on stackexchange narkive permalink

我所知道的所有銀行站點都有一個類似pin的系統,它在3次密碼嘗試失敗後會鎖定您的帳戶。這意味著長密碼會適得其反,因為它們更容易被錯誤鍵入或忘記,尤其是因為您看不到它們(如果可以看到它們,安全性甚至會更差)。

如果您使用例如。一個用於智能手機的密碼系統,您在其中輸入4個數字,在3次嘗試中猜中的機率是0.03%。如果使用8位數字,則正確猜中密碼的可能性(如果序列是隨機生成的而不是愚蠢選擇的)變得如此之小,以至於如果您嘗試猜測70億個人密碼,則平均只能猜對209個人密碼。如果允許使用字符和/或特殊字符,則猜測的機會會更小,分別乘以1 ^ -4或1 ^ -6的倍數。

即使允許用戶選擇密碼,並且以半預測的方式選擇它們,在3次嘗試中就不可能破解任何特定帳戶,即使您擁有大量數據(例如一家人的所有生日和每個人的名字),您的平均值也不會提高太多在這個人的家庭和每個朋友中。而且您也不大可能擁有針對大量人群的可靠而全面的此類清單。



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