Domanda:
A che punto qualcosa conta come "sicurezza attraverso l'oscurità"?
root
2013-03-06 13:52:39 UTC
view on stackexchange narkive permalink

Quindi, continuo a trovare la saggezza convenzionale che "la sicurezza attraverso l'oscurità non è affatto una sicurezza", ma ho il problema (forse stupido) di non essere in grado di dire esattamente quando qualcosa è "buona sicurezza" e quando qualcosa è solo "oscuro".

Ho controllato altre domande relative tangenzialmente a questo e non sono riuscito a capire la differenza precisa.

Ad esempio: qualcuno ha detto di usare SSH su una porta non standard conta come sicurezza attraverso l'oscurità. Stai solo contando che l'altra persona non lo controlli. Tuttavia, tutto ciò che SSH sta facendo è oscurare le informazioni. Si basa sulla speranza che un utente malintenzionato non pensi di indovinare la chiave crittografica corretta.

Ora, so che la prima circostanza (che qualcuno penserebbe di controllare le porte non standard per un particolare servizio) è molto di più probabilmente del secondo (che qualcuno indovinerebbe casualmente una chiave crittografica), ma la probabilità è davvero l'intera differenza?

E, se è così, come sono io (un infosec n00b, se non è già abbondantemente chiaro) dovrebbe essere in grado di distinguere il buono (cioè cosa vale la pena implementare) dal cattivo (cosa non lo è)?

Ovviamente, gli schemi di crittografia che si sono dimostrati vulnerabili non dovrebbero essere usati, quindi a volte è più chiaro di altre, ma quello con cui sto lottando è come so dove la saggezza convenzionale si applica e non si applica.

Perché, a prima vista, è perfettamente chiaro, ma quando io in realtà provo a estrapolare un algoritmo rigido e veloce e applicabile in modo coerente per esaminare le idee, mi imbatto in problemi.

Vedi [La password non è una forma di sicurezza attraverso l'oscurità?] (Http://stackoverflow.com/q/4486171/632951)
Quindici risposte:
#1
+87
Peleus
2013-03-06 14:14:33 UTC
view on stackexchange narkive permalink

L'idea sbagliata che hai è che la sicurezza attraverso l'oscurità sia un male. In realtà non lo è, la sicurezza solo attraverso l'oscurità è terribile.

Mettila in questo modo. Vuoi che il tuo sistema sia completamente sicuro se qualcuno ne conosce il funzionamento completo, a parte il componente segreto chiave che controlli. La crittografia ne è un perfetto esempio. Se ti affidi a loro "non vedendo il tuo algoritmo" usando qualcosa come un cifrario ROT13 è terribile. D'altro canto, se riescono a vedere esattamente l'algoritmo utilizzato ma ancora non possono praticamente fare nulla, vediamo la situazione di sicurezza ideale.

La cosa da capire è che non vuoi mai contare sull'oscurità ma di certo non fa mai male . Devo proteggere con password / utilizzare le chiavi per la mia connessione SSH? Assolutamente. Devo fare affidamento sulla modifica del server dalla porta 22 alla porta 2222 per mantenere sicura la mia connessione? Assolutamente no. È sbagliato cambiare il mio server SSH sulla porta 2222 mentre si utilizza anche una password? No, semmai questa è la soluzione migliore. Cambiando ("oscurando") il port si ridurrà semplicemente un mucchio di scanner automatici di exploit che cercano le porte normali. Otteniamo un vantaggio in termini di sicurezza attraverso l'oscurità, il che è positivo, ma non contiamo sull'oscurità. Se l'hanno trovato, devono ancora decifrare la password.

TL; DR - Contare solo sull'oscurità è un male. Vuoi che il tuo sistema sia protetto con l'attaccante che sappia che funziona completamente a parte informazioni segrete specificamente controllabili (ad esempio password). L'oscurità di per sé, tuttavia, non è male e può effettivamente essere una buona cosa.

Modifica: per rispondere in modo più preciso alla tua domanda sulla probabilità, sì in un modo che potresti vedere in questo modo, ma fallo apprezzando le differenze. Le porte vanno da 1-65535 e possono essere controllate rapidamente entro 1 minuto con uno scanner come nmap. "Indovinare" una password casuale di 10 cifre di tutti i caratteri ASCII è 1 / 1.8446744e + 19 e richiederebbe 5,8 milioni di anni per indovinare 100.000 password al secondo.

Modifica 2: per indirizzare il commento di seguito. Le chiavi possono essere generate con sufficiente entropia per essere considerate veramente casuali ( http://tools.ietf.org/html/rfc4086). In caso contrario è un difetto con l'implementazione piuttosto che la filosofia. Hai ragione nel dire che tutto si basa sul fatto che gli aggressori non conoscano le informazioni (password) e la definizione del dizionario di oscurità è "Lo stato di essere sconosciuto", quindi puoi correttamente dire che tutto conta su un livello di oscurità.

Ancora una volta però il valore si riduce alla sicurezza pratica, dato che le informazioni che puoi controllare rimangono sconosciute. Le chiavi, siano esse password o certificati ecc., Sono (relativamente) semplici da mantenere segrete. Gli algoritmi e altri metodi facili da controllare sono difficili da mantenere segreti. "Vale la pena" si riduce a determinare ciò che è possibile mantenere sconosciuto e giudicare la possibilità di un compromesso sulla base di tali informazioni sconosciute.

`ma di certo non fa mai male` ** Assolutamente sbagliato **.Tutto ciò che modifichi, ogni bit di complessità che aggiungi a un sistema, comporta il rischio che introduca una vulnerabilità.In effetti lo stesso esempio che hai usato introduce una vulnerabilità.Esecuzione di SSH su una porta alta _hurts_.Le porte superiori a 1024 possono essere associate senza root, consentendo a un utente malintenzionato di impersonare un server SSH, ma se, e solo se, hai implementato la tua misura di oscurità "innocua".Ovviamente, l'utilizzo di una porta bassa non standard non fa male, ma è chiaramente qualcosa che non hai preso in considerazione!
@forest inoltre, se "nascondi" elementi da scanner automatici, includi scanner di vulnerabilità che gestisci tu stesso;per esempio.se viene rilevata una vulnerabilità SSH "Notizie principali", si rischia di non riuscire a identificare i sistemi da applicare.Rischi che i tuoi servizi vengano bloccati da addetti alla sicurezza troppo zelanti da entrambe le parti (un rischio per la sicurezza in sé).E oscurare gli algoritmi crittografici rischia anche di rompere le cose, è pericolosamente vicino al rollio della tua sicurezza.("Dividiamo la tua password in due blocchi di 6 caratteri e crittografiamoli separatamente", potrebbe suonare qualche campanello!)
#2
+42
Ladadadada
2013-03-06 15:15:24 UTC
view on stackexchange narkive permalink

I segreti sono difficili da mantenere segreti. Più grande è un segreto e più persone lo conoscono, prima è probabile che trapeli.

I buoni segreti sono:

  • Piccolo.
  • Conosciuto solo da una persona.
  • Facile da cambiare.

Quando accusiamo qualcuno di sicurezza per oscurità quello che stiamo dicendo in realtà come che riteniamo che il loro segreto possa essere più piccolo, conosciuto da meno persone e / o più facile da cambiare .

Gli algoritmi, i numeri di porta e le password condivise non soddisfano il secondo e il terzo punto di cui sopra. Anche gli algoritmi non soddisfano il primo punto.

La distinzione tra quando qualcosa è un segreto appropriato e solo oscuro è se conosciamo un modo per raggiungere lo stesso livello di sicurezza con un segreto che è più facile da cambiare ed è conosciuto da meno persone.


Non sono d'accordo con l'affermazione secondo cui l'oscurità aggiuntiva non fa mai male.

Nel caso dei numeri di porta SSH, ci è una piccola quantità di tempo extra richiesta per digitare -p 1234 ogni volta che usi SSH. Questo è solo un secondo o due, ma con il numero di volte che uso SSH, questo finirebbe per essere significativo. C'è il sovraccarico di ricordare che questo cliente è leggermente diverso e di insegnare lo stesso ai nuovi assunti. C'è il caso in cui ti dimentichi che questo client è su una porta strana e sprechi minuti a guardare le configurazioni del firewall e i monitor di uptime cercando di capire perché non puoi connetterti.

Dato che i numeri di porta sono così facili da scoprire con una scansione delle porte, dovrai anche implementare un IPS che rileva la scansione delle porte e impedisce alla porta corretta di rispondere quando viene controllata o implementare qualcosa come il port knocking. Entrambi questi metodi possono essere superati e non aggiungono altro che più oscurità, ma richiedono tempo a giocare al gatto col topo con il tuo aggressore.

La stessa quantità di tempo impiegata per disattivare i login e le password di root e passare alle chiavi avrà un impatto migliore sulla sicurezza. Perdere tempo nell'oscurare i dettagli sottrae misure di sicurezza reali.

Nel caso di un algoritmo segreto, l'algoritmo perde il controllo aggiuntivo che molti ricercatori di sicurezza possono fornire. È probabile che l'oscurità (o la segretezza) dell'algoritmo sia meno sicuro.

Non intendo sembrare difensivo, ma diresti che il sovraccarico di una porta diversa è davvero significativo? Per una semplice modifica della porta, evitare la stragrande maggioranza degli exploit scanner automatici alla ricerca di configurazioni errate. Direi che -p 2222 non è un overhead significativo in alcun senso reale.
Non lo discuterò con veemenza o per molto tempo. Stimo che aggiungerebbe fino a * minuti al giorno * nella mia situazione, ma il mio lavoro quotidiano è un amministratore di sistema per un'infrastruttura di medie dimensioni in cui l'uso di SSH è molto comune. Più grande * o * più piccolo comporterebbe un uso meno effettivo di SSH. * Vorrei * sostenere a lungo che lo stesso sforzo potrebbe essere speso meglio.
Se non sei in grado di modificare il tuo .ssh / config per aggiungere una porta diversa da quella normale, esiterei a ricevere qualsiasi consiglio sulla sicurezza da te.
@Ladadadada ha un punto completamente valido. Sebbene la modifica della porta SSH predefinita sia una pratica comune per prevenire gli strumenti automatici, presenta degli svantaggi. Ad esempio, le connessioni interne a porte diverse dalla 22 possono essere bloccate da un firewall lato client in un'altra azienda, ecc. A parte questo, gli strumenti automatici possono essere facilmente bloccati tramite un semplice divieto IP dopo 3 tentativi di accesso. Non è difficile aggiungere una nuova porta, è necessario che ogni dipendente (interno ed esterno) sia familiare e tutto questo sforzo non sembra valerne la pena.
In una situazione di altissima sicurezza, il punto 2 non è strettamente parlando vero, ci sono situazioni in cui nessuno conosce l'intero segreto, ogni persona conosce solo parti del segreto e dovevano essere tutti presenti per sbloccare il segreto.
@Ladadadada, _Potrei_ essere d'accordo con l'idea generale di overhead, ma il tuo esempio (scusami) è ridicolo. Il sovraccarico qui è un prodotto della tua incapacità di ottimizzare le tue attività. Ho un piccolo script della shell di una riga su cui faccio doppio clic ogni volta che voglio impostare il mio tunnel SSH (che utilizza un numero di porta insolito, protezione brute-force e autenticazione della chiave).
@Adnan Ho già detto che non discuterò con forza che si tratta di un * grande * overhead, (perché non lo è) ma ti sei concentrato su un solo aspetto di avere SSH su una porta non standard e ho menzionato parecchi. Sembra anche che tu voglia discutere su qualcosa che non ha nulla a che fare con la sicurezza. * Qualsiasi * tempo sprecato per gestire la porta non standard (inclusa l'aggiunta di righe a `~ / .ssh / config` e la scrittura di script per il login) è tempo che avresti potuto spendere per aggiungere una vera sicurezza.
@Ladadadada, se non vuoi che le tue opinioni vengano criticate, non pubblicarle su SE. Come utente del servizio (SSH in questo caso) c'è davvero molta sicurezza "reale" che puoi aggiungere. Cambiare la porta SSH dal valore predefinito 22 _ è_ una buona pratica, la mia tesi è che impedisce la grande percentuale di attacchi automatici. Dici che non è una buona pratica, la tua argomentazione è che si sprecano 10 secondi per scrivere uno script di shell e sostieni che in 10 secondi farai qualcosa per influire sulla sicurezza di SSH.
Dovrei ** solo ** cambiare la porta predefinita e usare "password" come password? Ovviamente no. Ma sicuramente è meglio fare entrambe le cose. Inoltre, nessuno di noi può avere un verdetto finale su questo, tutto dipende dal caso. Quando la modifica della porta predefinita è scomoda (richiede modifiche a un numero elevato di client), non va bene.
+1: Questa è fondamentalmente la versione più informata, intelligente e ragionata del mio commento sarcastico super-segreto-crittografico.
Bene, l'argomento `ssh -p 1234` _è_ non è valido perché abbiamo il file .ssh / config che ti permette di specificare che` ssh foo` si connette al server `bar` sulla porta` qualunque` e usando la chiave `foo_rsa`.
Le mie opinioni sono sempre criticate, ma la mia tesi è che ** l'affermazione che "l'oscurità aggiuntiva * non * fa mai * male" è falsa **. Il motivo per cui non discuterò su `-p 1234` è che non è una parte importante del mio argomento attuale. È semplicemente un esempio di oscurità che ferisce (per quanto minuscolo possa essere il dolore) ed è stato scelto solo perché è nella domanda originale, non perché è un buon esempio. Se assumiamo che tu abbia ragione e che cambiare la porta SSH * valga * tutto il tempo necessario, la mia tesi non è minimamente indebolita.
In un'accesa e futile discussione il commento di Lie Ryan è passato inosservato, forse potresti includerlo nella tua bella risposta?
#3
+21
pwaller
2013-03-06 18:24:48 UTC
view on stackexchange narkive permalink

La sicurezza per oscurità è dove ti affidi a qualche fatto che speri non sia noto a un utente malintenzionato. Un grosso problema con questo è che una volta che il fatto è stato rivelato, lo schema di sicurezza è reso inutile.

Tuttavia, tutto ciò che SSH sta facendo è oscurare le informazioni. Si basa sulla speranza che un utente malintenzionato non pensi di indovinare la chiave crittografica corretta.

Quando viene discussa la frase " Sicurezza per oscurità ", spesso si riferisce ai processi coinvolti, piuttosto che a informazioni segrete. L'aspetto positivo di SSH è che come processo è stato accuratamente controllato per garantire che l'unica cosa di cui hai bisogno per mantenere il segreto sia la chiave crittografica. In linea di principio, questo non è possibile per l'attaccante "pensare e indovinare", perché lo spazio in cui vivono le chiavi crittografiche è vast”.

Bruce Schneier ha dimostrato che per usare la forza bruta una chiave AES a 256 bit che ti servirà come minimo , per catturare l'intera produzione di energia solare per 32 anni (!). Non importa quanto sia veloce il tuo computer. Questo è solo un risultato teorico dell'informazione che vale indipendentemente dal computer che usi (nonostante il calcolo quantistico).

Questo è del tutto impraticabile con la tecnologia attuale. Questo non vuol dire che SSH utilizzi AES, ma è uno dei principi di una buona crittografia.

Un esempio potrebbe essere il caso in cui un bug viene scoperto in un pezzo di software in cui un utente (fidato) trova uno specifico input consente un bypass dell'autenticazione. Un povero manager potrebbe dire "ah, ma è davvero improbabile che qualsiasi utente non fidato lo scoprirà mai, perché preoccuparsi di aggiustarlo". Questa è sicurezza per oscurità.

L'oscurità si riferisce infatti a una procedura (algoritmo), piuttosto che a un pezzo di conoscenza condivisa (password). Spesso il motivo per cui la "sicurezza attraverso l'oscurità" è considerata negativa, è perché l'opposto (algoritmi pubblici, noti, provati, testati, comprovati) è considerato buono. Le persone che cercano di implementare un algoritmo "oscuro" spesso inventano il proprio, spesso trascurando alcune cose e creando enormi vulnerabilità.
* "Bruce Schneier ha dimostrato che per ottenere la forza bruta una chiave AES a 256 bit è necessaria come minimo, per catturare l'intera produzione di energia solare per 32 anni (!)" * - In realtà, era forza bruta * ( tutte le combinazioni di) * una chiave a 192 bit. Per la forza bruta una chiave a 256 bit richiederebbe più energia di quanta l'intero sole potrà * mai * produrre. In effetti, mostra che richiederebbe l'energia di circa 137 miliardi di supernove.
(@BlueRaja-DannyPflughoeft, è per questo che ho detto * al minimo * ;-)
#4
+5
Xander
2013-03-06 19:03:54 UTC
view on stackexchange narkive permalink

È stato accennato in molte altre risposte, ma ci sono tre pezzi in questo puzzle.

  1. Meccanismi
  2. Implementazione / Configurazione
  3. Dati

Un esempio di meccanismo potrebbe essere AES, o SHA-1 o, ad esempio, SSH.
Un esempio di implementazione / configurazione potrebbe essere la porta su cui SSH è in ascolto o quale algoritmo di crittografia hai scelto per crittografare i dati della tua applicazione. Un esempio di dati è una chiave privata o una password.

Un meccanismo non dovrebbe mai essere oscuro. "È sicuro perché non sai come funziona" non è sicurezza. Dovrebbe essere possibile esaminarlo nei minimi dettagli senza che le implementazioni possano essere sfruttate in assenza di dati segreti.

Un'implementazione può o non può essere oscurata. In generale, non danneggia né aiuta materialmente la sicurezza quando si esegue questa operazione. Potresti vedere un numero inferiore di scansioni delle porte che identificano la tua porta SSH, oppure potresti essere in grado di nascondere l'algoritmo di crittografia utilizzato per un particolare testo cifrato, ma per un meccanismo sicuro senza i dati segreti, non dovrebbe avere importanza. Il meccanismo dovrebbe essere ancora inutilizzabile. Si sostiene che qui ci sia un vantaggio marginale per la sicurezza e un danno marginale all'usabilità. La tua milage può variare.

I dati segreti dovrebbero sempre essere oscuri. Se qualcuno si impossessa delle tue chiavi private o password, le revochi, crei nuovi dati segreti e prometti di proteggerli meglio la prossima volta.

#5
+3
Saladin
2013-03-06 14:01:54 UTC
view on stackexchange narkive permalink

La protezione dall'oscurità si applica a tutto ciò che riguarda il non correggere la particolare debolezza a livello di codice / sorgente invece di trovare soluzioni alternative per coprire i propri buchi. Quando quel livello di protezione viene rimosso, la vulnerabilità è aperta per essere sfruttata.

Uno di questi esempi sono gli hook di programma che forniscono agli sviluppatori una sorta di mezzo nascosto per connettersi alle applicazioni nell'ambiente di produzione. Questa è davvero una minaccia, un mito sulla sicurezza; ma viene rapidamente offuscato da qualcuno che ha conoscenze sufficienti per decodificare e talvolta semplicemente annusando la rete.

Di solito il motivo principale per cui queste minacce scappano in libertà quando vengono perse nella fase SDLC di progettazione di sistemi / applicazioni; poi quando si passa all'ambiente di produzione è semplicemente troppo costoso per le cose da riparare da quel punto in avanti. È lì che stanno emergendo soluzioni alternative o insabbiamenti.

Un altro esempio Persone che scrivono la loro password su pezzi di carta e la mettono sotto la tastiera.

Anche come un fattore di mercato dovresti sapere che tali pratiche sono normalmente seguite da fornitori / comunità closed-source; per un progetto open-source questo concetto non si applica a nessuno scopo pratico in quanto il codice viene rilasciato al pubblico in generale per la revisione e praticamente chiunque può affrontare i problemi attraverso tecniche come la revisione del codice. Il modo migliore e più affidabile per coglierlo.

Sconfiggere la sicurezza SSH attraverso il concetto di oscurità esempi pratici

  1. Eseguire la scansione nessus sulla rete mirata sarebbe portarti i servizi vulnerabili e le porte mappate
  2. Esegui la scansione nmap sulla rete mirata per i servizi aperti.
Gli esempi hanno un senso. È ovvio che scrivere la tua password su qualcosa e mantenerla dal computer evita lo scopo della password. Ma che dire del caso di cambiare la porta di servizio? In modo dimostrabile, questo rende la cosa più sicura. Se viene trovato un difetto con SSH, potrebbe rimandare quando sarai fregato abbastanza a lungo da poter risolvere il problema prima che qualcuno lo trovi e lo sfrutti. Per quel genere di cose, a che punto sai "va bene, questo è semplicemente ridicolo".
Come ho detto, ad esempio si applica anche a ssh che è necessario risolvere il problema alla fonte. Aggiornando ssh crypt lib o qualsiasi altra cosa, un cambiamento nella porta significa che se l'attaccante ha uno sniffer distribuito nel tuo ambiente può annusare la stretta di mano e conoscere la porta oscura usata da te
Concedo che l'esempio della porta del servizio di commutazione è un po 'debole. Un esempio diverso, quindi; diciamo che stai usando un metodo di crittografia che, con il computer più veloce attualmente sulla terra, richiederebbe 10 anni per decifrarlo. Può essere rotto con la forza bruta, ma non facilmente. Hai oscurato le informazioni facendo l'equivalente computazionale di metterci sopra un divano. Ma è ancora ottenibile. È ragionevole, vista la legge di Moore? E se ci volessero 100 anni? 1000 anni? Supponendo che tu non sappia per quanto tempo le informazioni devono essere protette.
Immagino che il mio problema sia che, da quello che ho scoperto, ciò che è oscuro e ciò che non è oscuro dipende più dall'attaccante che dalla politica stessa. Se il tuo aggressore è più intelligente delle persone che hanno creato gli strumenti che stai utilizzando per proteggere te stesso / il tuo datore di lavoro / il tuo cliente / il tuo blog di gatti, la loro sicurezza è, dal punto di vista degli aggressori, solo tanti divani computazionali da spostare. Come faccio a sapere di aver accumulato abbastanza divani? O meglio, come posso sapere che la politica a cui ho pensato sarà adeguata anche nei confronti di qualcuno più intelligente di me? So che nessuno può invertire la sottrazione, per esempio. Ma una determinata politica di sicurezza?
È necessario comprendere che tutti gli algoritmi devono avere un particolare livello di sicurezza per il sistema o essere chiamati formalmente come target di valutazione (libro arancione). Molte volte questi algoritmi vengono esaminati come fatto dal NIST, infatti esiste una scienza completa per valutare gli algoritmi. Il problema è che solo gli algoritmi divulgati pubblicamente possono essere testati da terze parti. La possibilità del reverse engineering e di altre minacce è ciò su cui controlla il processo di valutazione. Quando utilizziamo, ad esempio, AES128, ci fidiamo dello standard di crittografia. Quella fiducia viene dalla valutazione. A volte la politica guida la valutazione.
Di nuovo, devo ammettere l'ignoranza: devo andare a leggere i libri dell'arcobaleno. Ma, per essere sicuro di capire correttamente quello che stai dicendo ... C'è una scienza per valutare la sicurezza degli algoritmi quando vengono sviluppati - non semplicemente per la crittografia - e, sebbene per l'uso quotidiano l'adagio 'sicurezza attraverso l'oscurità non è sicurezza "serve come un utile autocontrollo rapido, ci sono definizioni molto più rigorose di abbastanza sicuro, che sfortunatamente (ma comprensibilmente) richiedono l'enumerazione di interi libri. Analisi corretta?
@root vi consiglio di leggere questo link. http://csrc.nist.gov/groups/STM/cavp/index.html
Debitamente annotato. Sembra il tipo di documentazione in cui una persona potrebbe affondare i denti. Per fortuna, ho qualche giorno libero in arrivo ... Grazie.
@root ti consiglio di leggere questo link. http://csrc.nist.gov/groups/STM/cavp/index.html Le minacce che si applicano all'algoritmo crittografico sono molto diverse da ciò che chiami prescrittivo "sicurezza attraverso l'oscurità" controlla questo link per maggiori informazioni. http://www.giac.org/cissp-papers/57.pdf. L'uso dell'arco a chiave pubblica è uno di questi esempi di sicurezza attraverso l'oscurità; solo le chiavi private devono essere protette.
#6
+2
AJ Henderson
2013-03-07 04:08:52 UTC
view on stackexchange narkive permalink

La sicurezza attraverso l'oscurità non è una sicurezza forse è più precisamente dichiarata come "Un sistema di sicurezza è sicuro solo se i suoi segreti sono difficili da indovinare". In realtà, quando ci si arriva al punto, si potrebbe sostenere che la crittografia sia la sicurezza attraverso l'oscurità poiché la chiave di crittografia è oscura. La differenza è che è così oscuro che è matematicamente impossibile da trovare e quindi sicuro.

In qualsiasi sistema di sicurezza basato su segreti, vuoi che il segreto sia il più limitato possibile e il più difficile da indovinare possibile . Più un segreto è complesso, più è probabile che ci sia un difetto in esso. Inoltre, limitare la quantità che deve essere tenuta segreta rende più facile mantenerla segreta.

L'affermazione "la sicurezza attraverso l'oscurità non è sicurezza" deriva dall'idea che molte idee "intelligenti" stanno semplicemente emergendo con modi contorti di fare qualcosa per cercare di rendere più difficile per un attaccante capire qualcosa, ma spesso un dettaglio di questi approcci avrà un impatto su altri dettagli di altri passaggi, quindi è impossibile dire quanto sarà difficile per un attaccante con conoscenza parziale di un algoritmo segreto per determinare il resto dell'algoritmo.

Le chiavi d'altra parte dovrebbero essere casuali, conoscere ad esempio alcuni bit di una chiave crittografica non dovrebbe aiutarti a capire gli altri bit nella chiave. Allo stesso modo, la difficoltà nel capire la chiave è abbastanza ben compresa. Poiché la sicurezza relativa dell'algoritmo non è influenzata in modo significativo (o quantificabile in modo affidabile) dalla segretezza dell'algoritmo, non aggiunge sicurezza statisticamente significativa.

Che cosa ha un impatto statisticamente significativo nella sicurezza di un algoritmo è qualsiasi problema con l'algoritmo. In generale, gli algoritmi pubblicati sono stati esaminati in modo molto più approfondito per individuare eventuali difetti che li infrangono e quindi forniranno generalmente una maggiore fiducia nella sicurezza che forniscono.

Quindi, in chiusura, la maggior parte della sicurezza implica un certo livello di oscurità, ma il trucco è ridurre al minimo la quantità e massimizzare la facilità di protezione di quei segreti cercando anche di garantire che non ci siano difetti non rilevati che causeranno un comportamento anomalo del sistema e svelare i segreti.

#7
+1
Alexander
2013-03-06 19:03:55 UTC
view on stackexchange narkive permalink

In ogni algoritmo di crittografia, a ogni prompt di accesso "security by obscurity" è una componente importante. Si basa sempre su una sorta di conoscenza segreta (ad eccezione dell'autenticazione a due fattori).

La differenza tra una buona sicurezza e una cattiva sicurezza è collegata alle proprietà della conoscenza segreta : Rimane segreta?

Un cattivo esempio è un sistema in cui puoi ricavare informazioni su questo segreto da altri canali. Supponiamo che tu abbia inventato il tuo algoritmo di crittografia, ad esempio "zip poi XOR con la tua chiave". Un utente malintenzionato esamina il tuo sistema e potrebbe determinare l'algoritmo di compressione dal tempo impiegato dal tuo schema di crittografia per codificare diversi messaggi di testo normale. L'autore dell'attacco ha acquisito conoscenza del tuo sistema, conosce le parti interne dell'algoritmo zip e potrebbe essere in grado di utilizzare questi dati per determinare la tua chiave. Dall'esterno questo sembra un algoritmo perfettamente valido, i dati compressi e xor'ed appariranno piuttosto casuali ma rappresentano solo una piccola sfida per un aggressore sofisticato. La tua chiave potrebbe essere molto lunga, ma questo non ti aiuta a distinguere tra oscurità cattiva e buona. Hai accidentalmente incorporato un percorso per acquisire la conoscenza della tua chiave segreta nell'algoritmo:

Il controesempio è la crittografia a chiave pubblica RSA. Qui la chiave segreta è un numero primo grande. La chiave pubblica è il prodotto della chiave segreta e di un altro grande numero primo. Ora anche con l'algoritmo RSA ben noto posso darti la mia chiave pubblica, puoi codificare tutti i dati che vuoi con essa ma non perde alcuna informazione sulla chiave segreta .

È così importante distinguere una sicurezza buona da una cattiva è la quantità di tempo necessaria a qualcuno per accedere ai tuoi dati. Nel tuo esempio specifico, passare dalla porta 22 alla 2222 è un'altra informazione di cui ha bisogno l'attaccante, quindi questo è un vantaggio in termini di sicurezza. Poiché questo è facile da capire in breve tempo, aggiunge solo una piccola quantità ma non perde nulla sulla tua chiave. Poiché questa scansione delle porte è banale e un costo una tantum, solo la quantità totale di informazioni necessarie per conoscere la tua chiave segreta rimane costante, ecco perché non è considerato un miglioramento della sicurezza totale, quindi il detto comune che "la sicurezza attraverso l'oscurità" non aiuta.

#8
+1
Nathan Long
2013-03-06 23:21:55 UTC
view on stackexchange narkive permalink

"Obscurity" riguarda presupposti

Penso che "security by obscurity" in realtà riguardi presupposti errati.

Ad esempio, se uso ingenuamente la mia crittografia manuale, pensando "nessuno saprà come romperlo perché è unico":

  • so che può essere rotto da qualcuno che ha la chiave.
  • presumo che non possa essere interrotto con altri mezzi. Probabilmente è falso.

Se utilizzo un metodo di crittografia collaudato:

  • so che può essere violato da qualcuno che ha la chiave.
  • Ho buone prove che non può essere rotto con altri mezzi.

Mi affido ancora l '"oscurità" della mia chiave. Ma questa è l'unica cosa che devo proteggere.

Quindi, per rilevare la "sicurezza per oscurità", sfida i presupposti. Se qualcuno dice "nessuno può immaginare o rilevare che stiamo facendo X", la risposta corretta è quante prove hai? Lo standard di sicurezza è molto, molto alto.

#9
+1
JimmyB
2013-03-07 21:10:20 UTC
view on stackexchange narkive permalink

Lo formulerei in questo modo:

"Sicurezza attraverso l'oscurità" si riferisce a una situazione in cui a un aggressore vengono deliberatamente forniti tutti i mezzi / informazioni necessari per violare il meccanismo di sicurezza, sperando o assumendo che l'aggressore non spenda lo sforzo per rivelarlo.

A volte si può osservare che alcuni programmi cercano di raggiungere la sicurezza con uno schema di crittografia "automatico", dove alla fine, oltre all'algoritmo di crittografia, la chiave di crittografia è contenuta da qualche parte nel programma stesso. Il programma stesso non avrà bisogno di ulteriori informazioni per poter decriptare i suoi dati "segreti"; e nemmeno qualsiasi attaccante.

La sicurezza "reale" cercherà di assicurarsi che un attaccante non avrà mai tutte le informazioni necessarie per infrangerlo. Quando si utilizza la crittografia, fondamentalmente non importa se l'attaccante ha accesso sia al messaggio di cifratura che all'algoritmo per crearlo fintanto che la chiave di crittografia non gli viene rivelata . In questo modo, gli vengono negate informazioni critiche e non può dalle informazioni che ha semplicemente aggirare il meccanismo di sicurezza.

#10
  0
BlueRaja - Danny Pflughoeft
2013-03-06 23:06:36 UTC
view on stackexchange narkive permalink

Puoi usare qualunque cosa desideri per la "chiave segreta", ma i port fanno una scelta sbagliata; ce ne sono solo 2 ^ 16, possono essere rilevati e sono (di solito) statici per la durata della connessione.

Tuttavia, sono stati usati come (parte della) chiave segreta in il passato, quando non c'è altra buona scelta. In particolare, la randomizzazione della porta è stata utilizzata per contrastare l ' attacco di avvelenamento della cache DNS di Kaminsky di alcuni anni fa. Combinato con la randomizzazione dell'ID query a 16 bit, questo ci dà 32 bit di sicurezza, che è più che sufficiente per proteggerci per la durata di una tipica query DNS (~ 0,1 secondi). La chiave segreta può ancora essere rilevata, ma è considerata "non un grosso problema" poiché il DNS è sempre stato comunque vulnerabile agli attacchi MITM. C'est la vie.

Quindi, se il tuo esempio è "sicurezza per oscurità" o meno dipende dal contesto.

#11
  0
KyleM
2013-03-06 23:26:07 UTC
view on stackexchange narkive permalink

Se si dispone di un'intera suite di meccanismi di protezione, si potrebbe dire che ognuno di questi meccanismi di protezione è solo "sicurezza attraverso l'oscurità", ma è più importante considerare la sicurezza del sistema nel suo insieme.

Individualmente, un meccanismo di protezione è considerato "sicurezza attraverso l'oscurità" se tale meccanismo di protezione dipende dal fatto che un utente malintenzionato non si aspetta qualcosa, o se quel meccanismo di protezione dipende dall'essere insolito piuttosto che crittograficamente forte. In altre parole, mettere SSH sulla porta 2222 è sicurezza attraverso l'oscurità perché un utente malintenzionato non si aspetterebbe che sia lì (non sarebbe la loro prima ipotesi) e perché quella non è la porta normale. Tuttavia, proteggere SSH con una password ad alta sicurezza è una vera sicurezza perché è pensato per essere crittograficamente forte. Inoltre, cambiare il tuo nome utente da "root" a qualcosa che non può essere facilmente indovinato è anche una vera sicurezza perché c'è una misura della forza crittografica lì: se l'attaccante non riesce a capire il nome utente non può entrare molto bene nel sistema anche se ottengono la password corretta.

#12
  0
Val
2013-03-07 01:33:14 UTC
view on stackexchange narkive permalink

Per oscurità capisco che la tua sicurezza si basa sul fatto che l'hacker non è a conoscenza del tuo algoritmo di crittografia. Devi semplicemente ripristinare i caratteri nelle tue parole, come PASS -> SAPP, o eseguire un offuscamento più complesso e puoi comunicare finché nessuno rileva l'algoritmo. Se svelare l'algoritmo di crittografia rompe tutta la tua sicurezza, allora è oscurità, non sicurezza. La vera sicurezza inizia quando l'hacker non sarà in grado di decrittografare il tuo messaggio, dati gli algoritmi di crittografia e decrittografia.

#13
  0
Eric
2013-03-07 06:22:28 UTC
view on stackexchange narkive permalink

La sicurezza viene eseguita autenticando che sei il destinatario o l'utente previsto. Esistono 3 fattori di autenticazione

  • Qualcosa che l'utente conosce (ad esempio, password, PIN, pattern)
  • Qualcosa che l'utente ha (ad esempio, carta bancomat, smart card)
  • Qualcosa che l'utente è (ad esempio, caratteristica biometrica, come un'impronta digitale)

La maggior parte delle misure di sicurezza utilizza l'autenticazione a fattore singolo. SSH, ad esempio, richiede di conoscere una password o di avere una chiave privata (immagino si possa dire che richiedere una passphrase per la chiave sarebbe un'autenticazione a due fattori).

L'autenticazione a due fattori è stata implementata ultimamente da molti fornitori di servizi e software. Ciò richiede due qualsiasi dei fattori sopra elencati, di solito una password e un numero di telefono. Con l'autenticazione a due fattori, un utente malintenzionato può accedere a una delle credenziali di sicurezza e non essere ancora in grado di accedere al sistema protetto.

La sicurezza attraverso l'oscurità è un'autenticazione a fattori zero. Non sei tenuto a conoscere alcun segreto, possedere nulla o essere una persona in particolare. Senza autenticazione non c'è autenticazione e quindi nessuna vera sicurezza.

#14
  0
dr jimbob
2013-03-08 04:32:20 UTC
view on stackexchange narkive permalink

L'oscurità può ferirti solo se pensi che ti offra vera sicurezza e adotti pratiche deboli. Tuttavia, l'oscurità può aiutare leggermente in quanto ti fa guadagnare tempo da vulnerabilità future sconosciute, se cerchi di mantenere le migliori pratiche (passphrase forti, applicare aggiornamenti di sicurezza, utilizzare algoritmi e protocolli controllati dalla sicurezza, ecc.). L'oscurità non impedisce un attacco da parte di qualcuno che ti ha preso di mira se il tuo sistema è vulnerabile, ma non annuncia nemmeno il fatto che sei vulnerabile al mondo intero.

Se avevi un Ruby On Rails app e l'aveva pubblicizzato e lo scorso gennaio era stato in vacanza, le persone avrebbero potuto eseguire comandi arbitrari sul tuo server web. In effetti, la pubblicità consentirebbe agli aggressori di trovarti molto più velocemente che se dovessero indovinare a caso quale tipo di stack tecnologico stai utilizzando e provare ogni sito web a caso.

Oppure supponiamo che in SSH si trovi una debolezza zero-day; un po 'come il problema della generazione di chiavi SSH di Debian di qualche anno fa. Le persone inizieranno la scansione in modo casuale per trovare ssh in esecuzione sulla porta 22 su indirizzi IP casuali e quindi eseguiranno l'exploit. Sicuramente potrebbero prima fare un port scan per cercare ssh, ma gli aggressori prima cercheranno il frutto più basso. Una ricerca completa renderebbe la loro scansione più di 10000 volte più lenta. Si spera che a quel punto tu abbia risolto il problema. La maggior parte degli indirizzi IP casuali non avrà ssh o altro in esecuzione su di essi, quindi ha senso che gli aggressori interrompano la scansione dopo la porta 22 (e forse anche un paio di altri 222 e 2222 e 22222). Se il tuo server di casa non risponde ai ping e rilascia tutti i pacchetti alle porte ma tranne 39325, probabilmente andranno avanti prima di trovare il tuo server ssh. Questa è l'oscurità che ti aiuta. Sì, un intercettatore di rete potrebbe banalmente trovare la tua porta in ascolto su una connessione ssh. Ma per la stragrande maggioranza degli aggressori che ti hanno preso di mira in modo casuale, non avranno osservato una connessione ssh ascoltando il tuo traffico di rete. Inoltre, anche per quegli aggressori, il 99,9% delle volte ti aspetti che la tua configurazione ssh sia sicura e non presenti vulnerabilità.

E per la seccatura extra di digitare ssh -p 39325 -Y [email protected] , chiunque usi ssh spesso imposta un ~ / .ssh / config (insieme a authorized_keys e id_rsa.pub / id_rsa ) in modo che possano semplicemente digitare ssh foo per connettersi dopo aver digitato la passphrase delle chiavi private. Ora il tuo file di configurazione ricorda il nome di dominio completo, il tuo nome utente, la porta (se non 22) e qualsiasi altro flag. Per ssh, cambierò le porte se è rivolto a Internet e solo io lo uso (la mia macchina domestica, il mio VPS) perché è una seccatura convincere tutti a usare la tua stessa porta. Per le cose interne di più utenti al lavoro, mantengo il firewall su Internet esterno e richiedo l'accesso esterno per passare attraverso una VPN.

Per la cronaca, il mio VPS aveva ssh in esecuzione sulla porta 22 e ~ 10000 tentativi di autenticazione errati al giorno (tutti con nomi utente inesistenti) registrati nei file di registro. Negli ultimi tre mesi di file di registro, ho ottenuto esattamente zero in esecuzione su una porta diversa.

#15
  0
Spook
2013-03-10 20:22:25 UTC
view on stackexchange narkive permalink

Immagino che l'oscurità possa essere misurata confrontando il suo valore di sicurezza con quanto complicherà l'utilizzo del supporto protetto. Qualcuno ha già detto che cambiare la porta SSH aumenterà un po 'la tua sicurezza, ma allo stesso tempo complicherà molto l'uso della shell, perché dovrai ricordare su quale porta è, insegnare a tutti i nuovi dipendenti di questa sicurezza misura, e alla fine finirà come una nota adesiva allegata ai display dell'utente o script automatici con la porta codificata, annullando così il suo valore di sicurezza.

Allo stesso modo, puoi offuscare il codice sorgente per proteggerlo. Ma se qualcuno vi accede, è solo questione di tempo prima che ripristini i significati originali di funzioni e variabili (ad esempio mediante un attento debugging) rendendo inutile l'offuscamento. D'altra parte, devi ricordarti di eseguire un programma speciale prima di compilare il codice o (quel che è peggio, ma l'ho visto) lavorare semplicemente sul codice con una strana convenzione di denominazione.

Secondo me, perdi più di quanto guadagni usando l'oscurità ed è per questo che la sicurezza tramite l'oscurità è considerata una cattiva pratica.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...