Sicurezza popolare "Culti del carico"

• La fonte chiusa è più sicura di quella open source in quanto i malintenzionati possono visualizzare il codice sorgente e trovare e sfruttare vulnerabilità. Sebbene non sostenga che ciò sia sempre falso, con software open source è per lo meno possibile che esperti esterni riesaminino il software alla ricerca di vulnerabilità / backdoor e poi li aggiusta pubblicamente. Con software closed source che semplicemente non è possibile senza smontare accuratamente il file binario. E mentre tu e la maggior parte dei malintenzionati potresti non avere accesso al codice sorgente, probabilmente esistono potenti aggressori (ad esempio, US gov't) che potrebbero essere in grado di ottenere il codice sorgente o iniettare vulnerabilità segrete in esso.

• L'invio di dati su una rete è segreto se si criptano i dati . La crittografia deve essere autenticata per impedire a un utente malintenzionato di alterare i tuoi dati. È necessario verificare l'identità dell'altra parte alla quale si inviano le informazioni oppure un intermediario umano può intercettare e alterare il proprio traffico. Anche con l'autenticazione e l'identificazione, la crittografia spesso perde informazioni. Parli con un server su HTTPS? Gli intercettatori della rete (chiunque del tuo ISP) sanno esattamente quanto traffico hai inviato, quale indirizzo IP e quale sia la dimensione di ciascuna risposta (ad es. Puoi impronte digitali di varie pagine Web in base alla dimensione di tutte le risorse trasferite). Inoltre, specialmente con i siti Web AJAX, le informazioni digitate spesso portano a una risposta del server che è identificabile dai suoi schemi di traffico. Vedi Leaks canale laterale nelle applicazioni Web .

• Debole domande per la reimpostazione della password - In che modo posta elettronica di Sarah Palin è stata compromessa ? Una persona ha superato la procedura di reimpostazione della password e ha potuto rispondere correttamente a tutte le domande dalle informazioni disponibili pubblicamente. Quali domande di reimpostazione della password potrebbero essere in grado di capire da un conoscente di Facebook?

• Il sistema X è infrangibile - utilizza la crittografia AES a 256 bit e ci vorrebbe un miliardo di computer ordinari per un milione di miliardi di miliardi di miliardi di miliardi di anni ". Sì, può t essere brute-forzato in quanto richiederebbe ~ 2 ²⁵⁶ operazioni. Ma la password potrebbe essere riutilizzata o in un dizionario di password comuni. O hai bloccato un keylogger sul computer. O tu hai minacciato qualcuno con una chiave inglese da $ 5 e ti hanno detto la password . Esistono attacchi di canale laterale. Forse il generatore di numeri casuali era difettoso . Gli attacchi temporali esistono. Esistono attacchi di ingegneria sociale. Questi sono generalmente i link più deboli.

• Questa pratica debole è abbastanza buona per noi, non abbiamo il tempo di aspettare per fare le cose in sicurezza . Il governo degli Stati Uniti non deve preoccuparsi di crittografare i feed video dai loro droni - chi saprà ascoltare le frequenze portanti giuste; inoltre le scatole di crittografia saranno pesanti e costose - perché preoccuparsi?

• I computer Quantum possono risolvere rapidamente problemi di tempo esponenziale e infrangere tutti i metodi di crittografia . Le persone leggono gli articoli scientifici popolari sui computer quantistici e sentono che sono queste entità mistiche super-potenti che sfruttano la potenza di calcolo di un numero quasi infinito di universi paralleli per fare qualsiasi cosa. È solo una parte vera. I computer quantistici consentiranno il factoring e i logaritmi discreti da eseguire in tempo polinomiale O (n ³ ) tramite l'algoritmo di Shor che rende RSA, DSA e crittografia basati su tali funzioni trap-door facilmente infrangibili. Allo stesso modo, i computer quantistici possono utilizzare l'algoritmo di Grover per forzare una password che dovrebbe richiedere il tempo O (2 ^N ) solo in tempo O (2 ^{N / 2} ); dimezzare efficacemente la sicurezza di una chiave simmetrica - L'algoritmo di Grant Grover è noto per essere asintoticamente ottimale per i computer quantistici, quindi non aspettatevi ulteriori miglioramenti.

Alcuni esempi:

• Chiavi più grandi. RSA a 4096 bit, AES a 256 bit ... più bit sono sempre migliori. (Vedi i commenti: non ha senso avere chiavi più grandi della dimensione che garantisce lo stato "non può rompere tutto", ma le chiavi più grandi implicano un sovraccarico della rete e della CPU, a volte in grandi quantità.)

• Applicazione automatica di "funzioni sicure" come snprintf() invece di sprintf() (non farà molto bene a meno che il programmatore non verifichi il possibile troncamento e non impedirà l'utilizzo di un utente fornito stringa come stringa di formato). Punti extra per strncpy() che non fa ciò che la maggior parte delle persone sembra assumere (in particolare, non garantisce un '%code%' finale).

• "Purezza del responsabile della sicurezza". Come applicazione della separazione di compiti e ruoli, tutte le decisioni "relative alla sicurezza" dovrebbero essere prese da uno specialista in sicurezza, che è distinto dai progettisti e sviluppatori del progetto. Spesso portato all'estremo fuorviante, dove il tizio che decide quali porte di rete dovrebbero essere lasciate aperte su qualsiasi firewall non ha alcuna conoscenza del progetto, e rifiuta deliberatamente di imparare qualsiasi cosa a tale riguardo, perché la decisione indipendente è più importante di decisione informata .

Aggiungerò i miei esempi appecec che ho visto consultando:

• "Ti invierò un messaggio di posta elettronica crittografato e includerò la password nello stesso email ... "Mi è successo più di una volta: una porta chiusa a chiave non resterà chiusa se lasci la chiave nella porta.
• "Ma non potresti averlo ottenuto iniezione SQL e SMTP, abbiamo chiamato sanitize() su tutto! ". Non c'è modo di creare una variabile sicuro per ogni uso, è necessario utilizzare la routine di risanamento per il lavoro.
• "Non possiamo essere violati perché usiamo solo la piattaforma / lingua / sistema operativo XXX". Ogni piattaforma ha problemi di sicurezza, periodo .
• "Abbiamo una valutazione annuale della sicurezza, che non sarai in grado di trovare qualsiasi cosa. " Frequenza! = Qualità . Avere valutazioni frequenti è una buona cosa, ma questo non garantisce nulla!
• "Abbiamo un WAF, il che significa che non dobbiamo effettivamente applicare patch qualsiasi cosa. "Sì, così succede ... Ho avuto un client che non ha applicato patch alle vulnerabilità CSRF conosciute, perché presumevano che il WAF sarebbe stato in grado di fermare questi attacchi. (Nessun WAF può farlo. Una volta ho trovato un WAF che ha affermato che potrebbe "prevenire tutti i owasp top 10" e l'interfaccia di gestione HTTP WAF era vulnerabile a CSRF.)

• Le password devono essere salate e sottoposte a hashing prima di essere archiviate nel database. SHA-1 è una buona misura, SHA-512 è perfetto.

Ne sento ancora uno di molti professionisti della sicurezza, della sicurezza e delle attuali guide alla sicurezza.

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

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

Al fine di evitare che le persone scoprano se alcuni utenti esistono nel sistema - nascondendo se la password fosse errata o il nome utente non valido durante un tentativo di accesso fallito, ... Mentre allo stesso tempo offre un modulo di reimpostazione della password che < em> fa perde queste informazioni.

"Il nostro sito Web non può essere violato perché stiamo usando SSL". Signore, questo lo rende ancora più facile da sfruttare se è vulnerabile perché persino il tuo IDS / IPS è reso inutilizzabile dal flusso SSL.