Il codice critico per la sicurezza deve essere riutilizzato o riscritto?

L'importante è manutenzione . Indipendentemente dal riutilizzo del codice esistente o da quello scritto, otterrete una sicurezza decente solo se c'è qualcuno, da qualche parte, che comprende il codice ed è in grado di tenerlo a galla per quanto riguarda, ad esempio, l'evoluzione di compilatori e piattaforme. Avere il codice senza bug è la cosa migliore, ma in pratica è necessario fare affidamento sulla cosa migliore successiva, vale a dire una rapida risoluzione dei bug (in particolare i bug che possono essere sfruttati per un uso dannoso, noti anche come vulnerabilità ), all'interno un breve periodo di tempo.

Se scrivi il tuo codice, il lavoro di manutenzione si affida direttamente alle tue spalle. E quel lavoro può richiedere molto tempo. Ad esempio, se si decide di scrivere e gestire la propria libreria SSL / TLS e utilizzarla in produzione, è necessario comprendere tutte le peculiarità dell'implementazione crittografica, in particolare la resistenza a attacchi ai canali laterali , e devi tenere d'occhio gli attacchi e le contromisure pubblicati. Se hai le risorse per questo, sia nel tempo che nella competenza, allora va bene! Ma il costo della manutenzione non deve essere sottovalutato. Riutilizzare una libreria esistente, in particolare una versione opensource ampiamente utilizzata, può essere molto più economica a lungo termine, poiché la manutenzione viene eseguita da altre persone e l'utilizzo diffuso garantisce un controllo esterno. Come bonus, non puoi essere incolpato dei buchi di sicurezza in una libreria esterna se metà del mondo li condivide.

Per riassumere, la domanda non riguarda in realtà il riutilizzo di codice , ma il riutilizzo di manutenzione .

(Scrivo tutto questo indipendentemente dalle grandi qualità pedagogiche di scrivere il tuo codice. Ti incoraggio a fare le tue implementazioni - ma certamente non per usarle effettivamente in produzione. Questo è per apprendimento ).

Ancora di più.

Il codice di sicurezza è ingannevole . Il codice di crittografia è decisamente difficile , anche se sei un crittografo esperto e impossibile da ottenere, se non lo sei.

Se ci sono così tanti bug critici in tanti grandi pacchetti software e aziende importanti - cosa ti fa pensare * potresti fare un lavoro migliore?

_{* A meno che non si tratti del tuo specifico ambito di competenza e la funzionalità di sicurezza è fondamentale per il tuo prodotto ...}

Domanda interessante! Vorrei rispondere più dal punto di vista delle probabilità che dal punto di vista delle migliori prassi correnti.

Mentre Thomas e altri forniscono grandi risposte, non credo che tocchino la domanda principale - che è "è un codice unico (o meno usato) più resiliente nella pratica di un codice popolare". Nota che non ho deliberatamente usato "più sicuro di un codice popolare". E quello che si riduce a è un caso speciale di "sicurezza attraverso il lavoro di oscurità"?

E (e so che questa non sarà una risposta popolare) Penso che quando sostituiamo "sicuro" con "resiliente" la risposta potrebbe non essere sempre comunemente accettata "mai!"

È probabile che sia meno sicuro (nel senso che è molto probabile che il tuo codice di sicurezza sia più facile / veloce da decifrare rispetto a quello diffuso attraverso molti attacchi precedenti, e risolto da persone più intelligenti di te).

Tuttavia, a meno che tu non sia un sito grande / popolare, significa anche che sei molto meno interessante ai potenziali cracker se non riescono a riutilizzare il codice / l'impegno speso per screditarti, e tale sforzo non è -trivial (ovvero, il tuo sito non si scomporrà alle automatiche non-validation / sonde di SQL injection). Questo ovviamente non funziona se sei specificamente mirato (spionaggio industriale, ecc.), Ma la stragrande maggioranza degli attacchi in quei giorni sembra in realtà essere sonde automatizzate per software popolari.

Quindi, se la domanda non è "che è più sicuro", ma "che è meno probabile che venga violato", la risposta potrebbe effettivamente essere "dipende". Ecco alcuni esempi:

Esempio 1: Immagina Microsoft Windows 8.1 (o qualunque cosa sia popolare oggigiorno) computer, con attualmente non noti buchi di sicurezza, acquistati ma mai aggiornati, connessi a Internet. Immagina anche il vecchio Windows 3.11 con winsock, mai rattoppato, con centinaia di falle di sicurezza, collegate a Internet. Entrambi sono usati nello stesso modo. Ignora a fini di discussione la qualità dell'accesso ... La domanda è, che sarà interrotta prima?

Mentre è ovvio che 3.11 è molto meno sicuro, non ci sono praticamente exploit in circolazione che lo bersagliano. Quindi potrebbe essere che ci sarebbe un exploit di 0-giorni massicciamente popolare per 8.1 che lo colpisse, prima che il 3.11 colpisca qualche exploit arcaico che riesca a farcela.

Esempio 2: Immagina di avere l'ultimo CMS Joomla su un server web senza exploit correnti noti e script perl fatti a mano che fanno cose CMS-ish, con noti bug sfruttabili (ma nessuno di essi sospetto ai test automatici attualmente disponibili). Dopo un anno, che ha maggiori possibilità di essere sfruttato?

Mentre prove aneddotiche, in alcune dozzine (fino a centinaia) di casi che ho avuto negli ultimi decenni, è stato nella grande maggioranza dei casi che il software popolare è stato sfruttato, mentre quelli obsoleti continuano a funzionare fino ad oggi indisturbati.

Un'altra cosa da prendere in considerazione:

• se il software più popolare esegue l'aggiornamento automatico (o ha sempre l'amministratore che lo aggiorna SEMPRE), allora i punti deboli di tale codice popolare sono molto ridotti (ma non eliminati, a causa di exploit di 0 giorni e non pubblicati) e quindi hanno un grande vantaggio
• al contrario, se il software non riceverà alcuna manutenzione, non popolare (come quello auto-scritto) uno potrebbe effettivamente essere meno sospetto di problemi
• colpa - potrebbe spesso essere vantaggioso utilizzare un software popolare. Se metà del mondo è colpita, non avrai la stessa colpa come se fossi un singolo programmatore su di esso. Questo è particolarmente importante se si lavora con denaro. Spesso è "meglio" essere meno sicuri, ma essere in grado di spostare la colpa, piuttosto che essere più sicuri, ma dover sostenere i costi da soli quando l'exploit colpisce.
• lavoro - già menzionato da altri, un software popolare nella maggior parte dei casi si risolve da solo, è sufficiente aggiornarlo - il che è molto meno lavoro di quello di trovare e correggere bug (ma richiede ancora alcuni manutenzione)
• un altro vantaggio per il software auto-scritto è spesso la riduzione del codice di massa (che porta a meno bug), dato che di solito non è necessaria la maggior parte delle funzionalità o personalizzazione. Ad esempio, le persone useranno Joomla anche se tutto ciò di cui hanno bisogno è un semplice "sito di notizie template" che potrebbe in pratica essere realizzato con poche dozzine di righe di codice. Anche se voi come programmatori non siete bravi a metà di quelli esperti che lavorano su un software popolare (quindi avete un numero notevolmente maggiore di bug per riga di codice), spesso potete vincere ancora con un ampio margine dovuto all'ordine di grandezza ( o pochi!) meno codice da scrivere / mantenere

La semplice risposta è: non lanciare la tua sicurezza.

Ci sono due parti in questo. Algoritmo e implementazione.

Per quanto riguarda l'algoritmo, creare il proprio algoritmo di crittografia è orrendo. Anche se sei esperto nel campo della crittografia, non sei ancora in grado di creare un nuovo algoritmo. A meno che tu non abbia un team di esperti nel campo che lavora su di esso, non giri il tuo algoritmo. Per riportare a casa questo punto, guarda alcuni dei recenti algoritmi che sono stati incrinati e come sono stati incrinati. Ciò che ha un bell'aspetto ha delle debolezze che non avrei mai concepito.

Per quanto riguarda l'implementazione, creare la tua implementazione di un buon algoritmo non è così orribile come creare il tuo algoritmo, ma a meno che tu non sia un professionista, non farlo. Un errore nell'implementazione e non importa quanto fosse buono l'algoritmo core. In questo caso, la domanda che devi porre è se sei migliore dei molti esperti che hanno lavorato per mettere insieme una libreria di sicurezza top di gamma.

Che cosa è più probabile. Che puoi implementare il tuo algoritmo e implementazione senza errori o punti deboli o che l'algoritmo e l'implementazione che utilizzerai avrà una backdoor inserita?

Se potessi creare un algoritmo perfetto con l'implementazione, il rischio di backdoor non sarebbe un problema. Ma non è realistico.

C'è anche la domanda su cui vuoi spiegare al tuo manager / azionisti / ecc.? Che ci fosse una backdoor inserita in un pacchetto software affidabile di alta gamma che ha a che fare con l'intero settore o che il tuo tentativo personale di sicurezza migliore è fallito in modo orribile. Personalmente preferirei spiegare piuttosto che ho fatto la scelta fatta da professionisti di tutto il settore e l'unica ragione per cui ha fallito è stata una questione di livello enorme che ha avuto un impatto anche sulle multinazionali.

Detto questo, sono d'accordo con Thomas che provare a farlo da solo è una buona esperienza di apprendimento finché non vede mai la luce della produzione.

La sicurezza non è necessariamente migliorata semplicemente se il codice viene compilato con istruzioni leggermente diverse. La sicurezza è:

1. Algoritmo
2. Attuazione
3. Controllo
4. Manutenzione

Se non stai scrivendo algoritmi migliori, più sicuri - che possono richiedere anni di ricerche - e il tuo codice non viene verificato, e le patch di conseguenza, allora è molto improbabile che un'implementazione leggermente diversa ti renda più sicuro.

Heartbleed, Shellshock, BEAST, POODLE e altri ultimi importanti problemi SSL / TLS si sono verificati a causa di problemi inerenti CRC e algoritmi autoreferenziali stessi e mancanza di audit del codice con esperienza, non a causa dell'implementazione.

Se non capisci veramente come hanno fallito, sicuramente non dovresti scrivere il tuo codice di sicurezza. Aggiungerai più problemi di quelli che risolverai.