it-swarm-eu.dev

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

Quindi, sto progettando un sistema di autenticazione delle porte (non posso davvero entrare nei dettagli) per la nostra scuola, in modo che solo le persone autenticate possano passare attraverso una determinata porta interna. Ritengono che il suo funzionamento interno debba essere tenuto segreto, in modo che nessuno possa decodificarlo. Ritengo che questo sarebbe Sicurezza attraverso l'oscurità , il che è negativo. Ho progettato il sistema in modo tale che sapere come funziona non ti aiuterebbe ad entrare, solo avere la chiave ti aiuterebbe ad entrare, come secondo principio di Kerckhoff . Continuano a sostenere che invece di più persone che ne sono a conoscenza, meno dovrebbero.

È una buona idea seguire un design chiuso? In caso contrario, esattamente perché?

Post scriptum Mi dissero che era un segreto solo dopo che avevo disegnato la maggior parte e detto a un gruppo di persone, se questo faceva la differenza (non avevo idea che volessero che fosse un segreto).
P.P.S. Sebbene non sia aperto verso l'esterno, la stanza che protegge contiene più oggetti di valore rispetto al resto della scuola, quindi mi aspetto che gli avversari siano in grado di decodificarlo comunque se andiamo con un design chiuso anziché aperto , ma non sono sicuro di come comunicarlo.

108
PyRulez

L'oscurità non è una cattiva misura di sicurezza da attuare. Fare affidamento sull'oscurità, come unica o più sostanziale misura di sicurezza, è più o meno un peccato cardinale.

Principio di Kerckhoff è forse l'argomento più spesso citato contro l'implementazione della sicurezza attraverso l'oscurità. Tuttavia, se il sistema è già adeguatamente protetto in base a tale principio, ciò è errato.

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

Se il sistema è già ben progettato secondo il Principio di Kerckhoff, la cosa peggiore che si può dire sull'applicazione della sicurezza attraverso l'oscurità è che aggiunge poco o nessun valore. Allo stesso tempo, per un sistema di questo tipo, vi è ugualmente un danno minimo o nullo nel proteggere la riservatezza del suo design.

242
Iszi

Mantenere segreto il design non rende la porta insicura di per sé; tuttavia, credere che si aggiunge alla sicurezza è una pericolosa illusione.

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

In generale, i dettagli del sistema di pubblicazione promuovono revisioni esterne, che si traducono in un ciclo di correzione, che alla fine migliora la sicurezza. In un contesto scolastico, non pubblicare i dettagli del sistema danneggia la sicurezza, perché le scuole sono piene di studenti e si sa che gli studenti sono anarchici curiosi che saranno particolarmente attratti dall'ingegnerizzazione inversa di tutto ciò che viene tenuto segreto. È noto che in una sala computer dello studente, il modo migliore per mantenere bassi gli incidenti di sicurezza è 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, dettagliare il funzionamento interno di un sistema di sicurezza potrebbe essere uno sforzo altamente pedagogico. Ho sentito che in alcune scuole praticano la pedagogia, almeno occasionalmente. La tua scuola potrebbe voler provarci.

103
Tom Leek

Hai già ricevuto diverse risposte eccellenti, sebbene la risposta di @ TomLeek e @ Iszi (entrambe eccellenti tra loro) sembrano essere in diretta contraddizione.

Entrambi fanno punti eccellenti: da un lato, mantenere segreto il design non renderà sicuro il sistema, mentre rivederlo pubblicamente vi permetterà di (eventualmente) trovare alcune vulnerabilità che non avete considerato; d'altra parte, non fa davvero male mantenere segreto il design, purché questo non sia un fattore chiave nella sicurezza del design.

Entrambe le parti sono assolutamente corrette - a volte.

Penso che sarebbe corretto affermare che entrambe le parti nell'argomentazione generale concorderebbero sul fatto che mantenere segreto il design non aumenta direttamente la sicurezza.
Nel peggiore dei casi, semplicemente nasconde punti deboli di sicurezza (che possono essere o meno una buona cosa, a seconda di chi lo consideri più nascosto).
Nel migliore dei casi (dove non ci sono vulnerabilità insignificanti che sarebbero esposte pubblicando il design), non aumenta ancora la sicurezza - ma lo fa minimizza 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 rispetto ai vantaggi della pubblicazione (vale a dire essere rivisto da ulteriori set di occhi) e al rovescio della medaglia di tenerlo segreto - ad es. la tentazione di fare affidamento su di esso come controllo di sicurezza (la sicurezza sempre popolare per oscurità), come una forma di teatro della sicurezza.

Vale anche la pena notare che, come accennato a @Tikiman, la sola pubblicazione del progetto non è sufficiente per garantire che sia recensione - soprattutto da coloro che sono in grado di trovare le vulnerabilità e che sono anche inclini per rivelarli a te. In molti casi, un progetto pubblicato verrebbe esaminato solo da quegli individui malintenzionati con intento illecito, quindi non otterresti il ​​beneficio atteso. Inoltre, spesso uno non lo sa nemmeno se il loro design rientra nel caso migliore di cui sopra o nel caso peggiore.

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

C'è un preciso compromesso da considerare: se si trattasse di un sistema crittografico complesso, la risposta sarebbe chiara; se si trattasse di un tipico sistema aziendale pesantemente implementativo, una risposta diversa sarebbe chiara.

La mia tendenza in questo caso è come diceva @ Tom, ma per le ragioni secondarie menzionate - in parte la base utenti anarchica e principalmente l'obiettivo pedagogico.

Si noti che queste non sono in realtà considerazioni sulla sicurezza, almeno non direttamente.

(Oh e per quanto riguarda il punto di @ Tikiman: la pedagogia qui implicata significa che puoi effettivamente assicurarti che il design sia rivisto, almeno da tutta la classe ;-))

29
AviD

Questo articolo di Daniel Missler è fantastico!

Lo afferma

La sicurezza di Obscurity è negativa, ma l'oscurità se aggiunta come livello sopra altri controlli può essere assolutamente legittima.

avendo questo concetto, sarebbe una domanda molto migliore

L'aggiunta dell'oscurità è il miglior uso delle mie risorse dati i controlli che ho in atto, o sarebbe meglio aggiungere un controllo diverso (non basato sull'oscurità)?

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

Un potente esempio di ciò è camouflage . Considera un carro armato corazzato come l'M-1. Il carro armato è equipaggiato con alcune delle armature più avanzate mai usate , ed è stato più volte dimostrato efficace nella battaglia nel mondo reale.

Quindi, data questa armatura altamente efficace, il pericolo per il carro armato aumenterebbe in qualche modo se dovesse essere dipinto dello stesso colore dei suoi dintorni? O che ne dici di in futuro quando potremo rendere il serbatoio completamente invisibile? Abbiamo ridotto l'efficacia dell'armatura? No, non lo abbiamo fatto. Rendere qualcosa di più difficile da vedere non rende più facile attaccare se o quando viene scoperto. Questo è un errore che deve semplicemente finire.

Quando l'obiettivo è ridurre il numero di attacchi riusciti, a partire da una sicurezza solida e testata e l'aggiunta di oscurità come livello offre un vantaggio generale alla postura di sicurezza. Camouflage realizza questo sul campo di battaglia e PK/SPA lo realizza proteggendo i servizi potenziati.

Enfasi mia.

Anche il commento di Iszi è ottimo, afferma che è molto meglio se cambiamo la Parola adding in enforcing, quindi in sintesi sarà simile a questo

Sommario:

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

14
Cary Bondoc

Pur non rispondendo davvero alla tua domanda, questo potrebbe servire come argomento per la tua scuola.

Considererei qualcuno ottenere l'accesso a una chiave/identità autorizzata il rischio reale. Le persone sono sciatte, usano password sbagliate e scrivono segreti per tutto il tempo. Un insegnante della mia scuola, anni fa, una volta ha lasciato le chiavi di tutta la scuola nel bagno di uno studente.

Se volessi entrare in quella stanza non mi preoccuperei nemmeno di cercare un buco nella sicurezza del software; Ruberei la chiave, proverei a manomettere il blocco fisico o qualche altro metodo esterno.

Oppure, come ha detto un mio amico quando gli è stato chiesto dal preside come farebbe per hackerare il sistema scolastico al fine di distruggere i dati; "Userei una mazza da baseball".

8
axl

Ho una lunga spiegazione che può sembrare vagare, quindi darò una risposta abbreviata, quindi la giustificherò. 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.

Hai ragione nella tua affermazione, che mantenere segreto il progetto del sistema è sicurezza attraverso l'oscurità (STO). La ragione principale per cui STO è una cattiva idea è che un sistema i cui meccanismi interni non sono inizialmente noti può essere retroingegnerizzato in tutti i casi attraverso un'attenta osservazione e la corretta applicazione dell'ingegneria sociale. Se sei l'unica persona a capire come funziona un sistema, sei l'unica persona che può verificarne l'integrità. Pertanto, se esiste un difetto potenzialmente passabile nel tuo progetto e qualcun altro decodifica il tuo progetto e lo scopre, possono sfruttarlo più facilmente che se non avessi tenuto segreti i tuoi progetti. È anche più probabile che siano in grado di mantenere segreta la loro scoperta e l'uso illecito.

Questo perché se rendi pubblica la tua progettazione, più persone lo esamineranno, più persone esamineranno un progetto, più è probabile che qualcuno scopra un difetto esistente e te ne parli. Un difetto di progettazione potrebbe non essere nemmeno nel concetto generale, ma l'implementazione specifica, come l'opportunità di un overflow del buffer nell'implementazione di un algoritmo altrimenti sicuro. Il concetto principale di utilizzo di primitive crittografiche pubbliche è che, rendendo tutti consapevoli dei propri algoritmi primitivi crittografici, altri possono esaminarlo. Dopo che un gran numero di persone lo hanno fatto, puoi essere ragionevolmente certo che il tuo design è sicuro. La difficoltà è che, poiché stai realizzando un progetto per una scuola, è probabile che solo un numero molto limitato di persone visualizzi i tuoi progetti, pochissimi dei quali sono in grado di capirli. Meno persone visualizzano i tuoi progetti, più è probabile che tutti coloro che scoprono un difetto non lo segnalino.

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

3
Tikiman163

Se fossi responsabile della porta avrei gli stessi requisiti in materia di riservatezza. Se il mondo (e il tuo lavoro) fossero perfetti, l'oscurità sarebbe davvero inutile.

Ma pensa solo a ciò che accade realmente nel mondo reale. Presumo che tu abbia svolto il tuo lavoro nel miglior modo possibile, utilizzando algoritmi all'avanguardia. 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.

Ciò che si desidera quando si rivelano i dettagli del proprio sistema di sicurezza è che i peer riesaminano l'implementazione e avvertono di possibili difetti prima che vengano scoperti e utilizzati dagli aggressori. Se conosci esperti nel sistema di sicurezza e li fai rivedere il tuo lavoro, penso che sarebbe visto come una buona pratica anche nella tua scuola - IMHO esso dovrebbe almeno. Ma se lo pubblichi, molto probabilmente i tuoi primi lettori saranno quelli contro i quali è 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 si crea un sistema di sicurezza generale, che potrebbe avere un vasto pubblico e non lo si utilizza immediatamente in produzione, è necessario pubblicarlo il più ampio possibile per ottenere buone recensioni. Ma se si sviluppa un'implementazione dedicata che verrà immediatamente utilizzata per la vera sicurezza, divulgare i dettagli solo a esperti di fiducia per evitare di aiutare gli aggressori a trovare possibili difetti.

0
Serge Ballesta

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

Se assumiamo che il sistema di autenticazione sia leggermente ma non molto difficile da hackerare e che ci siano studenti con alcune ma nessuna abilità di hacking avanzata, allora è del tutto possibile che l'ulteriore difficoltà posta rendendo i dettagli del sistema non disponibili sia sufficiente per metterlo fuori dalla portata di quel gruppo (gli studenti).

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

0
gnasher729