it-swarm.dev

Perché non dovremmo fare il nostro?

Perché non dovremmo creare i nostri schemi di sicurezza?

Vedo molte domande qui intorno su crittografia personalizzata e meccanismi di sicurezza personalizzati, in particolare sull'hash delle password.

Con questo in mente, sto cercando una risposta canonica, con le seguenti proprietà:

  • Facile da capire per un principiante.
  • Chiaro ed esplicito in perché far rotolare la tua è una cattiva idea.
  • Fornisce esempi forti.

Xkcd obbligatorio.

255
Polynomial

Puoi farlo tu stesso, ma probabilmente commetterai un grave errore di sicurezza se non sei un esperto in sicurezza/crittografia o se il tuo schema è stato analizzato da più esperti. Sono più disposto a scommettere su uno schema di crittografia open source noto pubblicamente che tutti possono vedere e analizzare. Più occhi significa più probabilità che la versione attuale non abbia grandi vulnerabilità, a differenza di qualcosa sviluppato internamente da non esperti.

Da Phil Zimmermann (creatore di PGP) Introduzione alla crittografia (Pagina 54) :

Quando ero al college nei primi anni '70, ho escogitato quello che credevo fosse un brillante schema di crittografia. Un semplice flusso di numeri pseudocasuali è stato aggiunto al flusso di testo in chiaro per creare testo cifrato. Ciò sembrerebbe ostacolare qualsiasi analisi di frequenza del testo cifrato e sarebbe indistruttibile anche per le agenzie di intelligence governative più intraprendenti. Mi sono sentito così compiaciuto del mio successo.

Anni dopo, ho scoperto lo stesso schema in numerosi testi introduttivi di crittografia e documenti tutorial. Che carino. Altri crittografi avevano pensato allo stesso schema. Sfortunatamente, lo schema è stato presentato come un semplice compito di compiti a casa su come utilizzare le tecniche crittografiche elementari per rompere banalmente. Questo per quanto riguarda il mio brillante schema.

Da questa umiliante esperienza ho imparato quanto sia facile cadere in un falso senso di sicurezza quando si concepisce un algoritmo di crittografia. La maggior parte delle persone non si rende conto di quanto diabolicamente difficile sia escogitare un algoritmo di crittografia in grado di resistere a un attacco prolungato e determinato da parte di un avversario intraprendente.

(Questa domanda ha più discussioni sulla citazione sopra.)

Se non sei convinto di "Non arrangiare il tuo [crittografia/sicurezza]", allora probabilmente non sei un esperto e ci sono molti errori che probabilmente commetterai.

La tua applicazione è robusta contro:

  • Attacchi a tempo . Ad esempio, per i nanosecondi le chiavi completamente errate e le chiavi parzialmente errate impiegano lo stesso tempo nell'aggregazione per fallire? Altrimenti, queste informazioni di temporizzazione possono essere sfruttate per trovare la chiave/password corretta.

  • Trivial Brute Force Attacks ; ad esempio, ciò può avvenire in pochi secondi o anni (quando ti preoccupi che venga rotto in pochi anni). Forse la tua idea di sicurezza potrebbe essere una possibilità da 1 su un miliardo (1 000 000 000) di irrompere (e se qualcuno con una rete bot ci provasse qualche miliardo di volte?). La mia idea è quella di puntare a qualcosa come 1 in ~ 2128 (34.000.000.000.000.000.000.000.000.000.000.000.000), che è circa dieci milioni di miliardi di volte più sicuro e completamente al di fuori del regno di indovinare.

  • Attacchi su account utente in parallelo; ad esempio, è possibile eseguire l'hashing delle password con lo stesso (o peggio no) "salt" su tutti gli hash delle password nel database come quello che è successo con gli hash trapelati LinkedIn .

  • Attacca qualsiasi account specifico banalmente semplicemente. Forse c'era un unico salt casuale con ogni password con hash semplicemente (ad es. MD5/SHA1/SHA2), ma come puoi provare miliardi di possibili password su qualsiasi hash al secondo, quindi usando elenchi di password comuni, attacchi con dizionario, ecc. impiega solo pochi secondi per attaccare per decifrare la maggior parte degli account. Usa hash crittografici forti come bcrypt o PBKDF2 per evitare o rafforzare gli hash regolari con un fattore adeguato (in genere 10(3-8)).

  • Attacchi a numeri "casuali" indovinabili/deboli. Forse usi microtime/MT-Rand o troppo poche informazioni per seminare il numero pseudo-casuale come Debian OpenSSL ha fatto qualche anno fa .

  • Attacchi che aggirano le protezioni. Forse hai fatto hashing/input lato client di validazione nell'applicazione web e questo è stato aggirato dall'utente alterando gli script. Oppure hai un'applicazione locale che il client tenta di eseguire in una macchina virtuale o disassembla per decodificare/modificare la memoria/o in qualche modo imbrogliare.

  • Altri attacchi, incluso (ma non tentando di essere un elenco completo) CSRF , XSS =, SQL injection , intercettazione della rete, ripeti gli attacchi , attacchi Man in the Middle , buffer overflow , ecc. Le migliori protezioni sono state riassunte molto rapidamente.

    • CSRF: richiede token CSRF generati casualmente su POST; XSS: convalida/evita sempre l'input dell'utente non attendibile prima di immettere nel database e visualizzare all'utente/browser.
    • SQLi: utilizzare sempre i parametri associati e limitare il numero di risultati restituiti.
    • Eavesdropping: crittografa il traffico di rete sensibile.
    • Replay: inserisce nonces univoci in ogni transazione.
    • MitM: Web of Trust/Uguale all'ultima visita al sito/Certificato rilasciato da un'autorità di certificazione attendibile.
    • Buffer overflow: linguaggio di programmazione sicuro/librerie/protezione dello spazio eseguibile/ecc.).

Sei forte solo quanto il tuo link sfruttabile più debole. Anche solo perché non stai realizzando il tuo schema, non significa che il tuo schema sarà sicuro, è molto probabile che la persona che ha creato ciò che hai lanciato non fosse un esperto o abbia creato uno schema altrimenti debole.

233
dr jimbob

C'è una casa nella mia zona con un mazzo davvero bello fuori dalla camera familiare del secondo piano. Sembra gonfio, finché non vai sotto e vedi come è stato costruito. Sembra che il proprietario della casa abbia deciso di non dover pagare un sacco di soldi a un costruttore o un architetto per dirgli come costruire un mazzo. L'ha costruito da solo e sembra una ragnatela caotica di 2x4 sotto. [~ # ~] probabilmente [~ # ~] andrà bene. Personalmente, preferirei non rischiare la vita e rinunciare a un lavoro di costruzione amatoriale come quello.

Penso che se vuoi sviluppare un algoritmo per eseguire la crittografia, dovresti farlo e divertirti. Non consiglierei di usarlo per nascondere i tuoi estratti conto online, ma se vuoi crittografare le lettere d'amore della tua ragazza sul tuo computer di casa, questo dovrebbe andare bene, a condizione che tua moglie non sia un crittografo.

C'è una storia in "The American Black Chamber" * sulla Marina che sviluppa i propri numeri. La Marina avrebbe mostrato il suo nuovo sistema crittografico, soddisfatta di se stessa e Yardley, l'analista dell'esercito, avrebbe prontamente infranto il codice, spiegando cosa avevano fatto di sbagliato. Offrivano di riparare il codice, ma Yardley ha sottolineato che, sebbene potessero correggere punti deboli specifici, senza una solida comprensione, avrebbero sempre avuto un problema. Il loro sistema era intrinsecamente difettoso. È un po 'come riparare un tetto che perde. Puoi rattopparti per sempre ma l'acqua sta ancora per entrare. Se non vuoi bagnarti, il tetto deve essere costruito da qualcuno che ne sappia più di un po 'sui tetti.

Ti ho mai parlato della chirurgia cerebrale fai-da-te che ho eseguito sulla mia suocera tardiva? Tutto è andato bene fino a quando non è andata e è morta. Seriamente, pochi di noi si fiderebbero della nostra salute per un medico dilettante; vuoi davvero fidarti dei tuoi segreti per il software amatoriale? Odio ammetterlo, ma compro un biglietto della lotteria ogni pochi mesi. Mi aspetto completamente di perdere, ma il potenziale pagamento è enorme. Posso giocare le probabilità e forse uscirò avanti. Se non lo faccio, sono fuori di testa. Perché giocare con le probabilità sulla crittografia? Il pagamento non è lì.

Saluti,/Bob Bryan

  • Consigliato: Herbert O. Yardley, "La camera nera americana" - Un libro interessante oggi come quando è stato scritto nel 1931. "La camera nera americana era piena di belle storie ben raccontate, nonché di descrizioni schiette dei successi di Yardley in crittoanalisi. È stato un best-seller nel 1932, oltre che all'estero. ” Da NSA: Pearl Harbor Review - The Black Chamber
63
Bob Bryan

Bruce Scheier scritto nel 1998:

Chiunque, dal dilettante più all'oscuro al miglior crittografo, può creare un algoritmo che lui stesso non può rompere. Non è nemmeno difficile. Ciò che è difficile è creare un algoritmo che nessun altro può rompere, anche dopo anni di analisi. E l'unico modo per dimostrarlo è sottoporre l'algoritmo a anni di analisi dei migliori crittografi in circolazione.

Cory Doctorow ha definito questo concetto "Legge di Schneier" in un 2004 discorso :

Chiunque può inventare un sistema di sicurezza così intelligente da non riuscire a pensare a come romperlo.

Come follow-up, questo , sempre da Schneier:

Quando qualcuno ti passa un sistema di sicurezza e dice "Credo che sia sicuro", la prima cosa che devi chiedere è: "Chi diavolo sei?" Mostrami cosa hai rotto per dimostrare che la tua affermazione della sicurezza del sistema significa qualcosa.

Phil Zimmerman ha anche scritto nei suoi documenti PGP originali :

Quando ero al college nei primi anni settanta, ho escogitato quello che credevo fosse un brillante schema di crittografia. Un semplice flusso di numeri pseudocasuali è stato aggiunto al flusso di testo in chiaro per creare testo cifrato. Ciò sembrerebbe ostacolare qualsiasi analisi di frequenza del testo cifrato e sarebbe indistruttibile anche per le agenzie di intelligence del governo più intraprendenti. Mi sono sentito così compiaciuto del mio successo. Così sicuro.

Anni dopo, ho scoperto lo stesso schema in numerosi testi introduttivi di crittografia e documenti tutorial. Che carino. Altri crittografi avevano pensato allo stesso schema. Sfortunatamente, lo schema è stato presentato come un semplice compito di compiti a casa su come utilizzare le tecniche crittografiche elementari per rompere banalmente. Questo per quanto riguarda il mio brillante schema.

59
tylerl

Il post originale ha chiesto un esempio:

Babington Plot è una buona storia di un cattivo sistema crittografico che causa problemi. Mary Queen of Scots è stata incarcerata da sua cugina Queen Elizabeth I e stava comunicando con le persone all'esterno tramite lettere crittografate. L'alfabeto è stato sostituito con un criptoalfabeto di scarabocchi, cerchi incrociati e triangoli con lettere extra assegnate a lettere comuni, come e, t, i e o, quindi il significato delle lettere non può essere trovato rapidamente dall'analisi di frequenza. Hanno anche aggiunto alcuni caratteri nulli che sono stati ignorati nella decrittazione per respingere gli analisti. Il problema era che la regina aveva un crittografo molto competente nel suo staff nella persona di Thomas Phelippes che era in grado di decifrare i messaggi mentre venivano intercettati.

Man mano che le cose procedevano, Mary seguì un complotto per sfuggire e conquistare il trono. Quando gli agenti della Regina intercettarono l'ultima lettera di Mary prima di trasmetterla, aggiunsero una frase crittografata che chiedeva i nomi di coloro che erano coinvolti nella trama "in modo che possano essere adeguatamente ricompensati". Il corrispondente di Mary rispose rispettosamente e gli agenti della Regina fecero giustiziare tutti gli attori coinvolti.

Quando i miei figli erano piccoli, inviavo loro i crittogrammi con il loro pranzo (con una chiave (usando un codice Vernam)). In generale, erano barzellette ma non avevano mai alcuna importanza. In un caso del genere, rollare il proprio va bene. Se stai pianificando di rovesciare la Regina d'Inghilterra (o lo Shah dell'Iran o la lenta criminalità in Myanmar), ti suggerirei di assicurarti che ciò che stai usando non possa essere facilmente decifrato. Come ha detto Bruce Schneier , chiunque può inventare un sistema crittografico che non può decrittografare, ma inventarne uno che nessun altro può decifrare è più difficile.

45
Bob Bryan

Darò un esempio di qualcosa che è successo qui dove lavoro. Un mio collega era responsabile della progettazione di un sistema di archiviazione password (lunga storia, non chiedere) per gli account FTP dell'azienda. Mi è stato chiesto di subentrare e la prima cosa che ho visto è stata:

public string Encrypt(string rawText)
{
    // homebrew code here
}
public string Decrypt(string encrypted)
{
    // homebrew code here
}

Li ho immediatamente strappati, sostituendoli con chiamate di libreria crittografica standard - e quando sono stato interrogato, ho risposto:

"Tu mai esegui la tua routine di crittografia."

Il mio collega mi ha combattuto su questo per ore. Aveva speso molto di tempo su di esso, rendendolo perfetto, in modo che un attaccante non potesse possibilmente avere modo di romperlo . Ad un certo punto, hanno anche detto: "Questo è più sicuro di AES256, perché nessuno sa come funziona".

A quel punto, sapevo due cose:

  • Il mio collega è stato un perfetto esempio dell'effetto Dunning Kruger (una mancanza di conoscenza su un argomento che rende più probabile la sopravvalutazione delle proprie capacità)
  • Il mio collega doveva essere corretto. Non solo perché avevano "torto", ma perché erano responsabili della progettazione di sistemi altri, e non volevo che mantenessero la crittografia casalinga.

Quindi ho messo da parte il codice. E invece, ho provato a rompere il codice della routine semplicemente chiamando la funzione Encrypt () ed esaminando l'output. Sono un novizio - non sono un crittografo - ma mi ci sono volute solo 4 ore. Ho dimostrato loro il crack, li ho guidati attraverso i miei passi e ho ribadito: non eseguire mai la tua crittografia. Spero che lo prendano a cuore e non lo faranno mai più.

Quindi si riduce a:

  1. Quanto sei sicuro della sicurezza della tua crittografia no dipende dalla sua sicurezza.
  2. Non rotolare mai la tua crittografia (non può essere ripetuta abbastanza spesso ...)
13
Kevin

Nella crittografia non hai un solo avversario che ti attacca nel modo in cui ti aspetti. Questo è ciò su cui è difficile ragionare, perché devi pensare a TUTTO.

Ma davvero, nessuno può superare in astuzia ogni possibile avversario. Il meglio che possiamo fare è utilizzare il più possibile le nostre conoscenze comuni e la ricerca esistente e fare piccoli passi per costruire da lì, vettore di attacco da vettore di attacco.

Ecco come vengono affrontati molti problemi sull'orlo dell'abilità umana, sia che si tratti di ricerca in fisica o di giocare a scacchi al più alto livello.

In queste aree puoi anche ignorare ciò su cui altre persone stanno lavorando e ideare le tue strategie e teorie, e se incontri il tuo primo avversario esperto, verrai cancellato dallo stato dell'arte in più modi in cui puoi contare.

TL; DR
Gli umani sono troppo stupidi per fare la crittografia da soli.

13
mschwaig

È generalmente impossibile garantire che qualcuno che progetta un sistema crittografico non lascerà l'azienda per la quale è stato creato, e utilizzare la propria conoscenza di tale progetto a danno del suo ex datore di lavoro, tranne progettando il sistema crittografico in modo tale che tale conoscenza che un avversario può acquisire potrebbe essere resa inutile.

Se uno ha un sistema crittografico che è sicuro anche contro gli aggressori che conoscono tutto tranne una chiave e uno cambia la chiave in un nuovo valore generato casualmente, allora il sistema sarà sicuro contro tutti gli attaccanti che non hanno la nuova chiave. Anche se gli aggressori avessero abbastanza informazioni per compromettere il sistema prima che la chiave fosse cambiata, non sarebbero in grado di rompere il sistema in seguito.

A meno che un sistema non debba proteggere dati insolitamente preziosi, probabilmente non è troppo difficile progettare un cryptosystem per essere abbastanza buono che, senza una conoscenza approfondita, il costo del cracking supererebbe qualsiasi valore che si potrebbe ottenere facendo così. Non perché progettare una buona crittografia è facile, ma perché la maggior parte dei sistemi non viene utilizzata per proteggere qualsiasi cosa possa avere un grande valore per un attaccante (anche se un esperto crittografo potrebbe facilmente rompere un sistema in 58 minuti, non sarebbe molto di un rischio a meno che il valore di tali informazioni per un attaccante non superi il costo del tempo del crittografo).

Progettare un sistema in modo che possa essere reso robusto contro qualcuno con dati privilegiati, tuttavia, è molto più difficile e ci sono pochissime persone con competenze sufficienti per progettare un sistema che, modificando una chiave, potrebbe essere reso robusto da qualcuno che aveva una conoscenza approfondita del design e delle competenze nella crittografia. Un esperto di crittografia senza conoscenza degli addetti ai lavori potrebbe dover controllare per centinaia o migliaia di potenziali errori che un progettista avrebbe potuto fare, ma la conoscenza degli addetti ai lavori potrebbe consentire a quella persona di identificare e sfruttare immediatamente un errore.

1
supercat

In realtà, lancia la tua criptovaluta, quindi gettala via.

Come Crypto Fails chiama, è un po 'difficile dire che non è possibile scrivere alcun codice crittografico. Il problema principale è non prendere quel codice e usarlo ovunque (nel software rilasciato).

Dovresti assolutamente provarlo e usarlo come esperienza di apprendimento. Ancora meglio se sei amico di un crittografo e puoi ottenere il loro feedback su ciò che hai scritto. Se valgono la pena, anche loro ti diranno di non usare il codice nella vita reale, ma dovrebbero essere in grado di darti alcune informazioni che ti aiuteranno ad imparare e crescere.

0
NH.