La mia scuola vuole mantenere segreti i dettagli del nostro sistema di autenticazione delle porte. È una buona idea?

L'oscurità non è una brutta misura di sicurezza da attuare. Affidare all'oscurità, in quanto misura di sicurezza esclusiva o più importante, è più o meno un peccato capitale.

Il principio di Kerckhoff è forse l'argomento più spesso citato contro l'implementazione della sicurezza attraverso l'oscurità. Tuttavia, se il sistema è già correttamente protetto in base a tale principio, questo è fuorviante.

Il principio, parafrasato, dice "supponiamo che il nemico sappia tutto sulla progettazione dei sistemi di sicurezza". Ciò non significa in alcun modo "dire al nemico tutto ciò che riguarda il tuo sistema, perché lo sanno comunque".

Se il sistema è già ben progettato in base al Principio di Kerckhoff, la cosa peggiore che si possa dire sull'applicazione della sicurezza attraverso l'oscurità è che aggiunge poco o nessun valore. Allo stesso tempo, per un sistema del genere, non c'è nulla di male a proteggere la riservatezza del suo design.

Mantenere il design segreto non rende la di per sé non sicura ; tuttavia, credere che ciò accresca la sicurezza è una pericolosa illusione.

Se rivelare i dettagli del sistema di autenticazione permetterebbe di romperlo, allora quel sistema è pura spazzatura e dovrebbe essere scartato. Pertanto, se hai svolto correttamente il tuo lavoro, rivelare i dettagli dovrebbe essere innocuo. Se hai non fai correttamente il tuo lavoro, quindi licenzia te stesso e assumi qualcuno competente.

In generale, i dettagli del sistema di pubblicazione promuovono le revisioni esterne, che determinano il ciclo di correzione delle interruzioni, che alla fine migliora la sicurezza. In un contesto scolastico, la pubblicazione dei dettagli del sistema non nuoce alla sicurezza, perché le scuole sono piene di studenti e gli studenti sono noti per essere anarchici ficcanaso che saranno particolarmente attratti dall'ingegneria inversa di tutto ciò che viene loro tenuto nascosto. È risaputo che in una sala computer per studenti, il modo migliore per mantenere bassi gli incidenti di sicurezza è di fornire la password di root / amministratore a un paio di studenti - quando uno studente vuole dilettarsi con la sicurezza del computer, dandogli pieno accesso rimuove tutti gli incentivi per cercare di rompere le cose, E lo trasforma in un ausiliario di polizia gratuito per monitorare gli altri studenti.

Inoltre, descrivere dettagliatamente il funzionamento interno di un sistema di sicurezza potrebbe essere uno sforzo altamente pedagogico. Ho sentito che in alcune scuole praticano effettivamente la pedagogia, almeno occasionalmente. La tua scuola potrebbe voler dare un colpo.

Hai già ricevuto numerose risposte eccellenti, anche se la risposta di @ TomLeek e @ Iszi (entrambe eccellenti) sembra essere in diretta contraddizione.

Entrambi costituiscono punti eccellenti: da un lato, mantenere il design segreto non renderà il sistema sicuro, mentre rivederlo pubblicamente ti consentirà di (eventualmente) trovare alcune vulnerabilità che non hai considerato; d'altra parte, non fa male a mantenere il design segreto, finché questo non è un fattore chiave nella sicurezza del design.

Entrambi i lati sono assolutamente corretti - a volte .

Penso che sarebbe corretto dire che entrambe le parti nell'argomento generale concorderebbero sul fatto che mantenere il segreto del design non aumenti direttamente la sicurezza.
Nel peggiore dei casi, si limita a nascondere i punti deboli della sicurezza (che possono o meno essere una buona cosa, a seconda di chi ritenete sia più nascosto).
Nel migliore dei casi (dove non ci sono vulnerabilità banali che verrebbero esposte pubblicando il design), non aumenta la sicurezza - ma fa minimizza la superficie di attacco .

Ridurre al minimo la superficie di attacco (anche senza la presenza di una vulnerabilità) è sicuramente una buona cosa; tuttavia, questo deve essere valutato e scambiato contro i benefici della pubblicazione (ovvero la revisione da parte di ulteriori gruppi di occhi), e il lato negativo di mantenerlo segreto - ad es. la tentazione di affidarsi ad esso come controllo di sicurezza (la sicurezza sempre più popolare per oscurità), come forma di teatro della sicurezza.

Vale anche la pena notare che, come alludeva @Tikiman, la semplice pubblicazione del design non è sufficiente per garantire che sia recensito , in particolare da coloro che sono in grado di trovare le vulnerabilità e che sono anche propenso a rivelarli a voi. In molti casi, un progetto pubblicato verrebbe esaminato solo da persone malintenzionate con intenti illeciti, pertanto non si otterrebbe il beneficio atteso. Inoltre, spesso uno non sa nemmeno se il suo design rientra nel caso migliore o nel caso peggiore sopra menzionato.

Quindi, linea di fondo - come in così tante cose in sicurezza, la risposta diretta è ancora: Dipende .

Qui c'è un compromesso definitivo - se questo fosse un criptosistema complesso la risposta sarebbe chiara; se si trattasse di un'implementazione tipica del sistema aziendale, una risposta diversa sarebbe chiara.

Il mio pendente in questo caso è come @Tom ha detto, ma per le ragioni secondarie menzionate - in parte la base di utenti anarchici, e principalmente l'obiettivo pedagogico.

Si noti che queste non sono realmente considerazioni sulla sicurezza, almeno non direttamente.

(Oh e per quanto riguarda @ punto di Tikiman - la pedagogia qui coinvolta significa che puoi effettivamente assicurarti che il design sia rivisto, almeno per l'intera classe ;-))

Questo articolo di Daniel Missler è fantastico!

Si afferma che

Security by Obscurity is bad, but obscurity when added as a layer on top of other controls can be absolutely legitimate.

avendo questo concetto, una domanda molto migliore sarebbe

Is adding obscurity the best use of my resources given the controls I have in place, or would I be better off adding a different (non-obscurity-based) control?

Possiamo anche usare l'anologia di camouflage come obscurity as another layer of security

A powerful example of this is camouflage. Consider an armored tank such as the M-1. The tank is equipped with some of the most advanced armor ever used, and has been shown repeatedly to be effective in actual real-world battle.

So, given this highly effective armor, would the danger to the tank somehow increase if it were to be painted the same color as its surroundings? Or how about in the future when we can make the tank completely invisible? Did we reduce the effectiveness of the armor? No, we didn’t. Making something harder to see does not make it easier to attack if or when it is discovered. This is a fallacy that simply must end.

When the goal is to reduce the number of successful attacks, starting with solid, tested security and adding obscurity as a layer does yield an overall benefit to the security posture. Camouflage accomplishes this on the battlefield, and PK/SPA accomplish this when protecting hardened services.

Enfasi sulla mia.

Anche il commento di Iszi è grandioso, afferma che è molto meglio se cambiamo la parola adding a enforcing , quindi in sintesi sembrerà come questo

Riepilogo:

La sicurezza di Obscurity è negativa, ma la sicurezza imposta con oscurità come livello sopra altri controlli può essere assolutamente legittima. Supponendo di essere al sicuro sul campo di battaglia perché pensi che il tuo carro armato sia dipinto con lo stesso colore dell'ambiente è semplicemente un non senso . Ma fare in modo che la difesa dei tuoi carri armati sia grande e far rispettare la vernice che ti garantisce l'abilità di mimetizzazione come un altro livello di protezione è fantastico!

Anche se non rispondi veramente alla tua domanda, questo potrebbe servire come argomento per la tua scuola.

Considererei il rischio reale che qualcuno acceda a una chiave / identità autorizzata. Le persone sono sciatte, usano password sbagliate e scrivono segreti in continuazione. Un insegnante della mia scuola, molto tempo fa, una volta ha lasciato le chiavi di tutta la scuola in un bagno per studenti.

Se volessi entrare in quella stanza non mi preoccuperei nemmeno di cercare di trovare un buco di sicurezza nel software; Potrei rubare la chiave, provare a manomettere il blocco fisico o qualche altro metodo esterno.

Oppure, come ha detto un mio amico mentre gli chiedeva il preside come avrebbe fatto a hackerare il sistema scolastico per distruggere i dati; "Userei una mazza da baseball".

Ho una lunga spiegazione che potrebbe sembrare vagare, quindi darò una risposta abbreviata, quindi giustificarla. Risposta breve, questa è sicurezza attraverso l'oscurità, ma questo probabilmente non è un problema a causa del numero di persone che entrano in contatto con il sistema. Quindi probabilmente non vale la pena discutere di un argomento.

Hai ragione nella tua asserzione, che mantenere segreto il design del sistema è la sicurezza attraverso l'oscurità (STO). La ragione principale per cui la STO è una cattiva idea è che un sistema i cui meccanismi interni non sono inizialmente noti può essere decodificato in tutti i casi attraverso un'attenta osservazione e la corretta applicazione dell'ingegneria sociale. Se sei l'unica persona che capisce come funziona un sistema, sei l'unica persona in grado di verificarne l'integrità. Pertanto, se nel tuo progetto esiste un difetto potenzialmente accettabile e qualcun altro invertire i tuoi progetti e scoprirlo, possono sfruttarlo più facilmente rispetto a se non avessi nascosto i tuoi progetti. Sono anche più propensi a mantenere segrete le loro scoperte e usi illeciti.

Questo perché se rendi pubblico il tuo progetto, più persone lo esamineranno, più persone esaminano un progetto più è probabile che qualcuno scoprirà un difetto esistente e te ne parlerà. Un difetto di progettazione potrebbe anche non essere nel concetto generale, ma l'implementazione specifica, come l'opportunità di un buffer overflow nell'implementazione di un algoritmo altrimenti sicuro. Il concetto principale dei primitivi della crittografia pubblica è quello di rendere tutti consapevoli dei propri algoritmi primitivi crittografici, altri possono esaminarli. Dopo che un gran numero di persone lo ha fatto, puoi essere ragionevolmente sicuro che il tuo design è sicuro. La difficoltà è che, poiché stai realizzando un progetto per una scuola, è probabile che solo un numero molto esiguo di persone visualizzi i tuoi disegni, molti dei quali sono suscettibili di capirli. Meno persone guardano i tuoi progetti, più è probabile che tutti quelli che scoprono un difetto non segnalino il difetto.

A meno che tu non abbia accesso a una vasta comunità di professionisti della sicurezza disposti a rivedere il tuo progetto, lasciare che abbiano la loro strada potrebbe essere approssimativamente uguale in termini di sicurezza effettiva.

Un obiettivo ovvio sarebbe che il sistema di autenticazione della porta non può essere violato dagli studenti.

Se ipotizziamo che il sistema di autenticazione sia leggermente ma non molto difficile da hackerare e che ci siano studenti con alcune ma non capacità avanzate di hacking, allora è abbastanza probabile che la difficoltà aggiunta impedisca di rendere i dettagli del sistema non disponibili è appena sufficiente per metterlo fuori dalla portata di quel gruppo (gli studenti).

D'altra parte, una volta che il sistema è così sicuro che crackare è molto più difficile che trovare o decodificare il funzionamento del sistema, mantenere i dettagli segreti non è più molto utile.

Se fossi responsabile della porta, avrei lo stesso requisito sulla riservatezza. Se il mondo (e il tuo lavoro) fossero perfetti, l'oscurità sarebbe davvero inutile.

Ma pensa a cosa succede realmente in un mondo reale. Immagino che tu abbia fatto il tuo lavoro al meglio, usando algoritmi allo stato dell'arte. Ma il diavolo si nasconde nei dettagli e un dettaglio di implementazione può indebolire la sicurezza. È successo alla libreria SSL non molto tempo fa, anche se gli algos erano davvero sicuri.

Quello che vuoi quando divulghi i dettagli del tuo sistema di sicurezza è che i peer riesaminano la tua implementazione e ti avvisano di possibili difetti prima che vengano scoperti e usati dagli autori di attacchi. Se conosci esperti nel sistema di sicurezza e chiedi loro di rivedere il tuo lavoro, penso che sarebbe visto come una buona pratica anche nella tua scuola - IMHO che dovrebbe almeno. Ma se lo pubblichi, più probabilmente i tuoi primi lettori saranno quelli contro cui è stata costruita la sicurezza della porta! E certamente non vuoi che siano i primi a recensire il tuo lavoro per possibili difetti.

TL / DR: se costruisci un sistema di sicurezza generale, che potrebbe avere un vasto pubblico e non lo usi immediatamente in produzione, dovresti pubblicarlo nel modo più ampio possibile per ottenere recensioni positive. Ma se costruisci un'implementazione dedicata che verrà immediatamente utilizzata per la sicurezza reale, rivelare i dettagli agli esperti di fiducia per evitare di aiutare gli aggressori a trovare possibili difetti.