it-swarm-eu.dev

Sicurezza popolare "Culti del carico"

In Information and IT Security c'è una brutta tendenza a che "best practice" specifiche diventino regole d'oro inviolabili, il che porta quindi le persone a raccomandare che vengano applicate indipendentemente dal fatto che siano appropriate per una determinata situazione (simile a Cargo Programmazione cult )

Un buon esempio di questo è l'approccio comune ai criteri password che applica un requisito di taglia unica per tutti gli 8 caratteri, combinato con requisiti di elevata complessità, 12 password precedenti memorizzate in una cronologia per interrompere il riutilizzo, 3 blocco dei tentativi errati e 30 rotazione del giorno.

La rotazione di 30 giorni ha lo scopo di abbassare la finestra di opportunità per un utente malintenzionato di utilizzare una password rubata, tuttavia è probabile che induca gli utenti a utilizzare password di sequenza, il che significa che se un utente malintenzionato può decifrare un'istanza può facilmente risolverne altre, in realtà invertendo il beneficio di sicurezza previsto.

I requisiti di elevata lunghezza e complessità hanno lo scopo di bloccare gli attacchi di forza bruta. Gli attacchi di forza bruta online vengono mitigati meglio con una combinazione di politiche di blocco sensibili e rilevamento delle intrusioni, la forza di forza bruta di solito si verifica quando un attaccante ha compromesso il database contenente le password e viene mitigato meglio utilizzando un buon meccanismo di archiviazione (ad esempio bcyprt, PBKDF2 ) anche un effetto collaterale non intenzionale è che porterà gli utenti a trovare un modello che funziona e aumenta anche il rischio che gli utenti scrivano la password.

La 3 politica di blocco errata ha lo scopo di bloccare gli attacchi di forza bruta online, ma impostandola su un valore troppo basso aumenta i blocchi degli account e sovraccarica gli helpdesk e pone anche un rischio di Denial of Service (molti sistemi online hanno facilmente intuito strutture di username come firstname.lastname, quindi è facile bloccare gli utenti)

Quali sono altri esempi di sicurezza Cargo-Cult che vengono comunemente applicati in modo inappropriato?

64
Rory McCune
  • L'origine chiusa è più sicura dell'open source poiché gli aggressori possono visualizzare il codice sorgente e trovare e sfruttare le vulnerabilità. Anche se non sto affermando che ciò sia sempre falso , con il software open source è almeno possibile per gli esperti esterni riesaminare il software alla ricerca di vulnerabilità/backdoor aperte e quindi correggerle pubblicamente. Con software chiuso che semplicemente non è possibile senza smontare scrupolosamente il binario. E mentre tu e la maggior parte degli aggressori potreste non avere accesso al codice sorgente, probabilmente esistono potenti aggressori (ad esempio, il governo degli Stati Uniti) che potrebbero essere in grado di ottenere il codice sorgente o iniettare vulnerabilità segrete al suo interno.

  • L'invio di dati su una rete è segreto se si crittografano i dati . La crittografia deve essere autenticata per impedire a un utente malintenzionato di modificare i dati. Devi verificare l'identità dell'altra parte a cui stai inviando informazioni oppure un man-in-the-middle può intercettare e alterare il tuo traffico. Anche con autenticazione e identificazione, la crittografia spesso perde informazioni. Parli con un server su HTTPS? Gli intercettatori di rete (chiunque nel proprio ISP) sanno esattamente quanto traffico ha inviato, a quale indirizzo IP e quale dimensione di ciascuna delle risposte (ad esempio, è possibile eseguire il fingerprinting di varie pagine Web in base alla dimensione di tutte le risorse trasferite). Inoltre, in particolare con AJAX, le informazioni digitate spesso portano a una risposta del server che è identificabile dai suoi schemi di traffico. Vedi Perdite del canale laterale nelle applicazioni Web .

  • Domande deboli sul ripristino della password - Com'è stato l'hacking dell'email di Sarah Palin ? Una persona ha seguito la procedura di reimpostazione della password e ha potuto rispondere correttamente a tutte le domande da informazioni pubblicamente disponibili. Quali domande di reimpostazione della password sarebbe in grado di capire un conoscente di Facebook?

  • Il Sistema X è infrangibile - utilizza la crittografia AES a 256 bit e richiederebbe un miliardo di computer ordinari un milione di miliardi di miliardi di miliardi di miliardi di anni probabilmente Sì, non può essere forzato brutalmente poiché ciò richiederebbe ~ 2256 operazioni. Ma la password potrebbe essere riutilizzata o in un dizionario di password comuni. Oppure hai bloccato un keylogger sul computer. Oppure tu hai minacciato qualcuno con una chiave da $ 5 e ti hanno detto la password . Esistono attacchi sul canale laterale. Forse generatore di numeri casuali difettoso . Esistono attacchi temporali. Esistono attacchi di ingegneria sociale. Questi sono generalmente i collegamenti più deboli.

  • Questa pratica debole è abbastanza buona per noi, non abbiamo tempo di aspettare per fare le cose in modo sicuro . Il governo degli Stati Uniti non deve preoccuparsi di crittografare i feed video dai loro droni - chi saprà ascoltare le giuste frequenze del corriere; oltre alle scatole di crittografia sarà pesante e costoso - perché preoccuparsi?

  • I computer quantistici possono risolvere rapidamente i problemi di tempo esponenziale e interromperanno tutti i metodi di crittografia . Le persone leggono articoli scientifici famosi su computer quantistici e sentono che sono queste mistiche entità superpotenti che sfrutteranno la potenza di calcolo di un numero quasi infinito di universi paralleli per fare qualsiasi cosa. È solo in parte vero. I computer quantistici consentiranno il factoring e i logaritmi discreti da eseguire in tempo polinomiale O (n3) tramite l'algoritmo di Shor che rende RSA, DSA e la crittografia basati su quelle funzioni della botola facilmente fragili. Allo stesso modo, i computer quantistici possono usare l'algoritmo di Grover per forzare una password che dovrebbe prendere O (2N) tempo solo in O (2N/2) tempo; dimezzare efficacemente la sicurezza di una chiave simmetrica: l'algoritmo di Grover concesso è noto per essere asintoticamente ottimale per i computer quantistici, quindi non aspettatevi ulteriori miglioramenti.

47
dr jimbob

Qualche esempio:

  • Chiavi più grandi. 4096-bit RSA, 256-bit AES ... più bit sono sempre migliori. (Vedi i commenti: non ha senso avere chiavi più grandi delle dimensioni che assicurano lo stato "impossibile romperle"; ma chiavi più grandi implicano un sovraccarico di rete e CPU, a volte in grandi quantità.)

  • Applicazione automatica di "funzioni sicure" come snprintf() anziché sprintf() (non farà molto bene a meno che il programmatore non verifichi l'eventuale troncamento e non impedirà l'utilizzo di un utente - stringa fornita come stringa di formato). Punti extra per strncpy() che non fa ciò che la maggior parte della gente sembra assumere (in particolare, non garantisce un '\0' Finale.

  • "Purezza del responsabile della sicurezza". Come applicazione della separazione di compiti e ruoli, tutte le decisioni "legate alla sicurezza" dovrebbero essere prese da uno specialista in sicurezza, che è distinto dai progettisti e dagli sviluppatori del progetto. Spesso portato all'estremo fuorviato, in cui il ragazzo che decide quali porte di rete dovrebbero essere lasciate aperte su qualsiasi firewall non ha alcuna conoscenza del progetto e rifiuta deliberatamente per imparare qualcosa al riguardo, perché - decisione indipendente è più importante di decisione informata.

29
Tom Leek

Aggiungerò i miei esempi di appsec che ho visto durante la consulenza:

  • "Ti invierò per email una zip crittografata e includerò la password nella stessa email ..." Questo mi è successo più di una volta. Una porta chiusa non rimarrà chiusa se si lascia la chiave nella porta.
  • "Ma non avresti potuto ottenere SQL Injection e iniezione SMTP, abbiamo chiamato sanitize() su tutto !". Non c'è modo di rendere una variabile sicura per ogni uso, è necessario utilizzare la routine di risanamento per il lavoro.
  • "Non possiamo essere hackerati perché utilizziamo solo piattaforma/lingua/sistema operativo XXX". Ogni piattaforma ha problemi di sicurezza, periodo.
  • "Abbiamo una valutazione annuale della sicurezza, non sarai in grado di trovare nulla". Frequenza! = Qualità. Avere valutazioni frequenti è una buona cosa, ma questo non garantisce nulla!
  • "Abbiamo un WAF, il che significa che non dobbiamo effettivamente correggere nulla". Sì, quindi questo succede ... Avevo un client che non correggeva le vulnerabilità CSRF note, perché presumevano che il WAF sarebbe stato in grado di bloccare questi attacchi. (Nessun WAF può farlo. Una volta ho trovato un WAF che affermava che poteva "prevenire tutti i primi 10 di Owasp" e l'interfaccia di gestione HTTP del WAF era vulnerabile a CSRF.)
23
rook
  • Le password devono essere salate e hash prima di essere archiviate nel database. SHA-1 ha una buona vestibilità, SHA-512 è perfetto.

Ho ancora sentito quello da molti professionisti della sicurezza, formazione sulla sicurezza e attuali guide di sicurezza.

19
AviD

Utilizzo di SSL solo per la pagina di accesso anziché per tutte le aree autenticate di un sito Web.

15
Shurmajee

Solo uno, ma è un grosso problema: "La sicurezza delle informazioni è un problema tecnologico, che può essere risolto con la tecnologia".

11
Graham Hill

Al fine di impedire alle persone di scoprire se esistono determinati utenti nel sistema - nascondendo se la password era errata o il nome utente non era valido durante un tentativo di accesso fallito, ... Mentre allo stesso tempo offre un modulo di reimpostazione della password che fa perde queste informazioni.

5
Numeron

"Il nostro sito Web non può essere violato perché stiamo utilizzando SSL". Signore, ciò rende più semplice lo sfruttamento se è vulnerabile perché anche il tuo IDS/IPS è reso inutile dal flusso SSL.

2
void_in