題:
大眾安全“邪教”
Rory McCune
2013-09-16 20:47:58 UTC
view on stackexchange narkive permalink

在信息和IT安全中,令人討厭的趨勢是特定的“最佳實踐”成為不可侵犯的黃金法則,這導致人們建議無論是否適合特定情況都應應用這些最佳實踐(類似於貨物崇拜編程

一個很好的例子是密碼策略的通用方法,該方法適用於所有8個字符長度的要求,並結合了高複雜性要求,12個以前的密碼的單一大小存儲在歷史記錄中以停止重複使用,3次不正確的嘗試鎖定和30天的輪換。

30天的輪換旨在降低攻擊者使用被盜密碼的機會,但是可能會導致用戶使用序列密碼,這意味著如果攻擊者可以破解一個實例,他們就可以輕鬆解決其他實例,從而實際上逆轉了預期的安全性好處。

高長度和復雜性的要求旨在阻止暴力行為。強行攻擊。結合明智的鎖定策略和入侵檢測,可以更好地緩解在線暴力攻擊,當攻擊者入侵了包含密碼的數據庫並使用良好的存儲機制(例如bcyprt,PBKDF2)可以更好地緩解離線暴力時,通常會發生脫機暴力),這也是一種意料之外的副作用,它會導致用戶找到一種有效的模式,並且還會增加用戶寫下密碼的風險。

3種錯誤的鎖定策略旨在阻止在線暴力攻擊,但是將其設置得太低會增加帳戶鎖定,並會使服務台超載,還會帶來拒絕服務的風險(許多在線系統很容易猜到用戶名這樣的結構,例如firstname.lastname,因此很容易將用戶拒之門外)

還有其他一些通常不適當地應用的Cargo-Cult安全性示例嗎?

這聽起來像是一個討論性問題,Rory。
對不起對不起這確實是一個討論問題。最接近的關閉原因是基於意見的。我可以看到的一種方法是充其量是CW。
@tylerl Adnan哎呀,住一點。打破規則,在淋浴時撒尿。
@Rook:全部都是管道!有什麼不同?!
@tylerl是的,但是是一個客觀(大部分)可回答的討論問題,對於人們在信息安全中陷入的陷阱有特別有用的答案。
八 答案:
dr jimbob
2013-09-16 22:08:19 UTC
view on stackexchange narkive permalink
  • 封閉源代碼比開放源代碼更為安全,因為攻擊者可以查看源代碼並查找和利用漏洞。雖然我並不是說這總是錯誤的,但是開源軟件,至少外部專家可以審查該軟件,以尋找巨大的漏洞/後門,然後公開修補它們。使用封閉源代碼軟件,如果不費勁地分解二進製文件就不可能實現。儘管您和大多數攻擊者可能無法訪問源代碼,但是可能存在強大的攻擊者(例如,美國政府),他們可能能夠獲取源代碼或向其中註入秘密漏洞。

  • 如果對數據進行加密,則通過網絡發送數據是秘密的。需要對加密進行身份驗證,以防止攻擊者更改您的數據。您需要驗證向其發送信息的另一方的身份,否則中間人可以攔截並更改您的流量。即使使用身份驗證和標識,加密也經常會洩漏信息。您通過HTTPS與服務器對話嗎?網絡竊聽者(ISP中的任何人)確切知道您發送了多少流量,發送到哪個IP地址以及每個響應的大小(例如,您可以根據所傳輸的所有資源的大小來對各種網頁進行指紋識別)。此外,尤其是在AJAX網站上,您鍵入的信息通常會導致服務器響應,該響應可以通過其流量模式來識別。請參閱 Web應用程序中的側通道洩漏

  • 弱密碼重置問題- Sarah Palin的電子郵件情況如何砍死?一個人經過了密碼重置程序,可以從公開信息中正確回答每個問題。 Facebook熟人可以找出哪些密碼重置問題?

  • 系統X堅不可摧-它使用256位AES加密,可能需要十億台普通計算機才能突破十億億億億年的時間。是的,它可以暴力破解,因為這需要〜2 256 sup>操作。但是密碼可以重複使用,也可以在常用密碼的詞典中重新使用。或者您將鍵盤記錄器卡在了計算機上。或者您用5美元的扳手威脅某人,他們告訴您密碼。存在旁通道攻擊。 隨機數生成器可能有缺陷。存在定時攻擊。存在社會工程攻擊。這些通常是最薄弱的環節。

  • 這種薄弱的做法對我們已經足夠了,我們沒有時間等待安全地做事。美國政府無需擔心從無人機上加密視頻輸入,後者會知道正確的載波頻率。除了加密盒之外,它們還會很笨重且成本很高-為什麼還要麻煩?

  • Quantum計算機可以快速解決指數時間問題,並且會破壞所有加密方法。人們在量子計算機上閱讀了流行科學文章,並聽到它們是這些神秘的超強大實體,它們將利用幾乎無限數量的並行宇宙的計算能力來執行任何操作。這只是部分事實。量子計算機將允許通過Shor的算法在多項式時間內O(n 3 sup>)進行因式分解和離散對數,從而使RSA,DSA和基於陷阱門功能的加密易於破解。類似地,量子計算機可以使用Grover算法對僅在O(2 N sup>)時間內應佔用O(2 N sup>)時間的密碼進行暴力破解。有效地減少了對稱密鑰的安全性-格蘭特·格羅弗(Grantr)的算法對於量子計算機來說是漸近最優的,因此不要期望進一步的改進。

我會在您的第一篇文章中添加一個推論,那就是“開源比封閉源更安全,因為有很多人在審查問題代碼。”
@Xander-我不確定我是否願意走那麼遠(即使在實踐中,我也同意,如果我是出於高安全性而在開放源代碼和封閉源代碼之間進行選擇,我會盡可能選擇開放版本查看是否有重大漏洞)。多年來,開放源代碼中存在一些重大的安全漏洞示例。開源的真正缺點在於,攻擊者可能會故意引入巧妙的,有缺陷的代碼,這些代碼會滑過維護者。最好的辦法是由安全專家/審核員團隊開發內部封閉的源代碼(您可以查看,但沒有其他人可以查看)。
“我的計算機是不可侵犯的,因為它從未/從未/將永遠不會連接到互聯網。”
@drjimbob或具有開源功能但完全在內部開發而無需使用任何貢獻者的軟件(參見Red Hat Enterprise Linux)。
@Xander案例:[ProFTP](http://www.zdnet.com/blog/security/open-source-proftpd-hacked-backdoor-planted-in-source-code/7787)
我還要補充一點:*流行的*開放源代碼比封閉源代碼更安全,我可以創建自己的crypt套件並對其開放源代碼,但這可能是不安全的,因為沒有人會關心它來嘗試和改進它
“有效地將對稱密鑰的安全性減半”。不完全的。這是指數下降。 64位密鑰不僅僅比128位密鑰“安全一半”。 2048位密鑰的安全性也比4096位密鑰的安全性低得多,但是對於暴力破解而言,這仍然幾乎是不可能的。
@Anorov-對不起,我猜您對我可憐的單詞選擇感到困惑:“有效地將對稱密鑰的密鑰大小減半”。 Grover的算法允許量子計算機將AES-128的暴力破解減少到2 ^ 64次。因此,代替N = O(2 ^ 128)進行暴力破解,需要花費sqrt(N)= O(2 ^ 64)時間(二次加速)。其次,注意*對稱*關鍵部分(RSA是非對稱的)。由於Shor算法,針對量子計算機的2048位RSA / DSA密鑰僅比4096位密鑰強8倍。 Grover的算法對RSA沒有意義-您可以通過分解來蠻力-不用嘗試每個密鑰。
@Anorov-針對常規計算機,針對L(1/3)通用數字現場篩; 4096/2048/1024位RSA密鑰等效於156/117/87位對稱密鑰,因此RSA-4096的強度應比RSA-2048高約2 ^ 39倍。基於L(1/4)篩分,反對基於某些人認為不久之後會基於[近期離散日誌工作]公開發現的分解因子(http://eprint.iacr.org/2013/095); 4096/2048/1024位RSA減少為96/75/59位對稱密鑰。
@ratchetfreak您的意思是類似晦澀的OpenSSL之類的東西,不是嗎?
在過去的幾年中,一些較流行的開源已被證明儘管已經開放並且具有許多人對其進行審查的可能性,但仍然存在明顯的安全問題。其中一些甚至存在嚴重的問題,我們發現該問題已經存在十年或更長時間了。儘管發現問題後可以立即對其進行修補。**所有**開放源代碼軟件和封閉源代碼軟件都存在問題,這一事實永遠不會消失。
Tom Leek
2013-09-16 22:07:35 UTC
view on stackexchange narkive permalink

一些示例:

  • 更大的鍵。 4096位RSA,256位AES ...更多的位總是更好。 (請參閱註釋:密鑰的大小不能確保“完全無法破解”狀態是沒有意義的;但是較大的密鑰意味著網絡和CPU開銷,有時甚至很多)。

  • 自動執行“安全功能”,例如 snprintf()而不是 sprintf()(除非程序員測試可能的截斷,並且不會阻止使用用戶提供的字符串作為格式字符串)。 strncpy()的加分點並沒有像大多數人所認為的那樣(特別是,它不能確保最終的'\ 0')。

  • “安全管理器的純度”。作為職責和角色分離的一種應用,所有“與安全相關的”決定都應由安全專家做出,該專家不同於項目設計者和開發者。通常會誤入歧途,在那兒,決定應該在任何防火牆上打開哪些網絡端口的傢伙對項目一無所知,因此故意拒絕學習這方面的任何知識,因為獨立決策明智決策更重要。

您能否詳細說明為什麼較大的鍵可能不會比較小的鍵更好?
較大的密鑰表示較高的帶寬和CPU使用率,也可能表示互操作性問題;除了鍵本身是“用地球技術牢不可破”的尺寸以外,額外的長度只是自重。 RSA-2048和AES-128已經存在。
我懂了。如果我是你,我會將其添加到您的答案中。
我同意您的觀點,更多的位並不總是更好-[有時它更弱-​​因為在某些攻擊下,舍入式AES-256比AES-128弱一些](http://eprint.iacr.org/2009 /374.pdf)。但是當多餘的毫秒時間成為問題(例如加密幾個文件)時,更多的位並不一定會受到傷害,並且可能會阻止攻擊方法的發展。假設L(1/3)= e ^ O(N ^ 1/3)通用數字場篩,RSA-2048可以媲美112位強,儘管[最近的數學突破將其降低為L(1/4)= e ^ O(N ^ 1/4)for離散日誌](http://eprint.iacr.org/2013/095)。
有人希望將其擴展到分解,這將使RSA-2048僅具有約75位的等效強度(在我們的big-O分析中粗略地假設與112位分析相同的常數),而RSA-4096將為〜96位強。 RSA-768經過一次分散的努力就被​​破壞了,並且使用舊的L(1/3)篩網具有76位的安全性。同樣,如果您擔心對手會在某個時候建造一台量子計算機,並且能夠使用Grover算法在2 ^ 64時間內打破AES-128,則可以選擇AES-256。同樣,始終“同意”使用“更大”是錯誤的,但有時這是有道理的。
@drjimbob是貨運培訓的重點,忽略了使給定聲明有效的原因或上下文。...
這就是為什麼在復制整個字符串時,應首選`strlcpy`而不是`strncpy`的原因。
rook
2013-09-16 22:24:20 UTC
view on stackexchange narkive permalink

我將添加自己在諮詢時看到的appsec示例:

  • “我將通過電子郵件發送給您加密的zip,並將密碼包含在相同的電子郵件中...”我不止一次發生如果您將鑰匙留在門中,則鎖著的門將不會保持鎖定狀態。
  • “但是您無法忘記SQL注入 ,我們在所有內容上調用了 sanitize()!”。沒有辦法使變量每次使用都安全,您需要為作業使用衛生例程。
  • “我們不能被黑客入侵,因為我們只使用XXX平台/語言/操作系統”。每個平台都存在安全問題,期限
  • “我們進行年度安全評估,您將一無所獲。” 頻率!=質量。進行頻繁的評估是一件好事,但這並不能保證任何事情!
  • “我們擁有WAF,這意味著我們不必進行任何修補。”是的,所以這發生了……我的一個客戶端沒有修補已知的CSRF漏洞,因為他們認為WAF能夠阻止這些攻擊。 (沒有WAF可以做到這一點。我曾經找到一個WAF,聲稱它可以“阻止所有owasp前10名”,並且WAF的HTTP管理界面容易受到CSRF的攻擊。)
WAF是否有可能自動注入和驗證CSRF令牌?
@SLaks我還沒有看到這樣的東西。
我想知道為什麼...
關於您的第一點,我處理過的大多數公司都必須這樣做,以繞過其電子郵件系統中的篩選器。掃描儀(包括GMail)不允許您發送包含exe文件的zip文件,因此您需要對zip文件進行加密才能發送(儘管我個人只是將zip文件重命名為zop,然後GMail獨自處理了!) )
* WAF * = Web應用程序防火牆,對於那些不熟悉首字母縮略詞的人(如我)。
AviD
2013-09-17 02:33:56 UTC
view on stackexchange narkive permalink
  • 密碼必須先加鹽和散列,然後再存儲在數據庫中。 SHA-1非常適合,SHA-512非常適合。

我仍然聽到許多安全專家,安全培訓和最新的安全指南中的一位。

512> 1.越大越好吧?
如果我錯了,請糾正我,但是有了SHA-1中的碰撞漏洞,SHA-2算法(SHA-256,SHA-512等)中的任何一種都不會更好嗎?
-1
Shurmajee
2013-09-18 10:12:49 UTC
view on stackexchange narkive permalink

僅對登錄頁面使用SSL,而不對網站的所有已驗證區域使用

甚至更糟的是,登錄頁面使用http,但嵌入了https iframe或發佈到https目標。使用幾乎無法檢測到的SSL Strip很簡單。 (Stackexchange OpenID,我在看你)。
哦,這傢伙真讓我煩!我還看到了HTTPS網站,但登錄iframe是HTTP。像wtf一樣,什麼開發人員想出了那件出色的作品?
Graham Hill
2013-09-17 14:42:19 UTC
view on stackexchange narkive permalink

這只是一個大問題:“信息安全是一個技術問題,可以通過技術解決。”

Numeron
2016-04-28 06:00:57 UTC
view on stackexchange narkive permalink

為了防止人們發現系統中是否存在某些用戶-在嘗試登錄失敗期間隱藏密碼不正確或用戶名無效,...同時提供了一個密碼重置表,該信息確實洩漏了此信息。

void_in
2013-09-16 22:45:46 UTC
view on stackexchange narkive permalink

“因為我們正在使用SSL,所以我們的網站無法被黑客入侵”。主席先生,這會使漏洞更容易被利用,因為SSL流甚至使您的IDS / IPS也變得無用。

您的入侵檢測/預防系統可能擁有您的私鑰副本,並且能夠解密傳入/傳出的TLS流量。
@drjimbob在大多數情況下並非如此。即使使用私鑰,SSL也不能保護網站免受應用程序級別的任何利用。
好的,TLS可以防止網絡竊聽者監聽密碼,會話cookie以及正在訪問的URL /數據。許多聲稱“被黑客入侵”的網站僅讓某人使用具有捕獲的密碼的管理員帳戶來破壞內容。同意,TLS無論如何都不是萬能的-它只能防止網絡竊聽/篡改(確實應該使用TLSv1.2-儘管服務器可以接受來自舊瀏覽器的TLSv1.1很好;但是您確實不應該使用任何SSL或TLSv1.0)。同意,這不會阻止SQL注入,CSRF,XSS,緩衝區溢出等。


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