Il malinteso che stai avendo è che la sicurezza attraverso l'oscurità è cattiva. In realtà non è così, la sicurezza solo attraverso l'oscurità è terribile.

Mettilo in questo modo. Vuoi che il tuo sistema sia completamente sicuro se qualcuno ne conoscesse il funzionamento completo, a parte il componente segreto chiave che controlli. La crittografia è un perfetto esempio di questo. Se ti affidi a loro 'non vedere il tuo algoritmo' usando qualcosa come un codice ROT13 è terribile. D'altro canto, se riescono a vedere esattamente l'algoritmo utilizzato, ma non riesco ancora a fare praticamente 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 / utilizzare le chiavi per la mia connessione SSH? Assolutamente. Devo fare affidamento sul cambio del server dalla 22 alla 2222 per mantenere la mia connessione sicura? Assolutamente no. È male cambiare il mio server SSH sulla porta 2222 mentre si utilizza anche una password? No, semmai questa è la soluzione migliore. Cambiando ("Oscurando") la porta si limiterà a ridurre un mucchio di scanner di exploit automatici alla ricerca di porte normali. Otteniamo un vantaggio di sicurezza attraverso l'oscurità che è buona, ma non stiamo contando sull'oscurità. Se lo hanno trovato hanno ancora bisogno di rompere la password.

TL; DR - Il solo conteggio sull'oscurità è sbagliato. Desiderate che il vostro sistema sia sicuro con l'attaccante sapendo che è un funzionamento completo a prescindere dalle informazioni segrete controllabili (cioè le 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 di probabilità, sì in un modo in cui puoi guardarlo in quel modo, e tuttavia apprezzare le differenze. Le porte vanno da 1-65535 e possono essere rapidamente controllate entro 1 minuto con uno scanner come nmap. "Indovinare" una password casuale a 10 cifre per tutti i caratteri ascii è 1 / 1.8446744e + 19 e richiedere 5,8 milioni di anni per indovinare 100.000 password al secondo.

Modifica 2: per indirizzare il commento qui sotto. Le chiavi possono essere generate con entropia sufficiente per essere considerate veramente casuali ( link ). Se non è un difetto con l'implementazione piuttosto che con la filosofia. Hai ragione nel dire che tutto fa affidamento su hacker che non conoscono le informazioni (password) e la definizione del dizionario di oscurità è "Lo stato di essere sconosciuto", quindi puoi dire correttamente che tutto sta contando su un livello di oscurità.

Ancora una volta il valore si riduce alla sicurezza pratica, date le informazioni che sei in grado di controllare rimanendo sconosciuto. Le chiavi, che si tratti di password o certificati ecc., Sono (relativamente) semplici da mantenere segrete. Algoritmi e altri metodi facili da controllare sono difficili da mantenere segreti. "Ne vale la pena" si riduce a determinare cosa è possibile mantenere sconosciuto e giudicare la possibilità di un compromesso basato su tali informazioni sconosciute.

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

I buoni segreti sono:

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

Quando accusiamo qualcuno della sicurezza attraverso l'oscurità che stiamo realmente dicendo come pensiamo che il loro segreto potrebbe essere più piccolo, conosciuto da un minor numero di persone e / o più facile da cambiare .

Algoritmi, numeri di porta e password condivise non superano il secondo e il terzo punto sopra. Anche gli algoritmi non superano 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 più piccolo che è più facile da cambiare ed è conosciuto da meno persone.

Non sono d'accordo con l'affermazione che un'ulteriore oscurità non guasta mai.

Nel caso dei numeri di porta SSH, c'è una piccola quantità di tempo extra necessario 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 risulterebbe significativo. C'è il sovraccarico di ricordare che questo cliente è leggermente diverso e di insegnare nuovi assunti allo stesso modo. C'è il caso in cui si dimentica che questo client si trova su una strana porta e sprecano minuti a guardare le configurazioni del firewall e i monitoraggi del tempo di attività cercando di capire perché non è possibile connettersi.

Poiché 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 implementa qualcosa come il knock-out. Entrambi questi metodi possono essere superati e non aggiungere nulla di più dell'oscurità più , ma occupano il tuo tempo giocando a gatto e topo con il tuo aggressore.

La stessa quantità di tempo speso per il passaggio da login e password di root e il passaggio a chiavi avrà un impatto migliore sulla sicurezza. Perdere tempo a oscurare i dettagli toglie le vere misure di sicurezza.

Nel caso di un algoritmo segreto, l'algoritmo non tiene conto dello scrutinio aggiuntivo che molti ricercatori di sicurezza possono fornire. L'oscurità (o segretezza) dell'algoritmo potrebbe causarne una minore sicurezza.

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

However, all SSH is doing is obscuring information. It relies on the hope that an attacker won't think to guess the correct cryptographic key.

Quando viene discussa la frase " Sicurezza per oscurità ", spesso si riferisce ai processi coinvolti, piuttosto che alle informazioni segrete. Il problema di SSH è che come processo è stato pesantemente controllato per garantire che l'unica cosa che è necessario mantenere segreta sia la chiave crittografica. In linea di principio, l'attaccante non è in grado di "pensare e indovinare", perché lo spazio in cui vivono le chiavi di crittografia è vasto .

Bruce Schneier ha dimostrato che per forzare una chiave AES a 256 bit avresti bisogno di al minimo , a cattura l'energia prodotta dall'intero sole per 32 anni (!). Non importa quanto sia veloce il tuo computer. Questo è solo un risultato teorico delle informazioni che tiene a prescindere dal computer che usi (nonostante il calcolo quantistico).

Questo è totalmente impraticabile con la tecnologia attuale. Questo non vuol dire che SSH usi AES, ma è uno dei principi di buona crittografia.

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

È stato toccato in diverse altre risposte, ma ci sono tre pezzi per questo puzzle.

1. Meccanismi
2. Implementazione / Configurazione
3. Dati

Un esempio di meccanismo sarebbe AES, o SHA-1, o per il tuo esempio, SSH.
Un esempio di implementazione / configurazione sarà la porta su cui sta ascoltando SSH o quale algoritmo di crittografia hai scelto per crittografare i dati dell'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 poter essere esaminato nei minimi dettagli senza che le implementazioni siano sfruttabili in assenza di dati segreti.

Un'implementazione può o non può essere oscurata. Generalmente, non fa male né aiuta materialmente la sicurezza quando lo fai. Potresti vedere un minor numero di scansioni delle porte che identificano la tua porta SSH, oppure potresti essere in grado di nascondere l'algoritmo di crittografia usato per un particolare testo cifrato, ma per un meccanismo sicuro senza i dati segreti, non dovrebbe avere importanza. Il meccanismo dovrebbe essere ancora non sfruttabile. C'è una tesi che qui c'è un vantaggio marginale sulla sicurezza e un danno marginale all'usabilità. La tua milizia può variare.

I dati segreti dovrebbero sempre essere oscuri. Se qualcuno ottiene una sospensione delle tue chiavi o password private, le revochi, crei nuovi dati segreti e fai voto per proteggerli meglio la prossima volta.

La sicurezza verso l'oscurità si applica a tutto ciò che riguarda il non fissare la debolezza particolare a livello di codice / sorgente, invece di trovare una soluzione alternativa per coprire i buchi. Quando viene rimosso quel livello di protezione, la vulnerabilità è aperta per essere sfruttata.

Uno di questi esempi è il hook del programma che offre agli sviluppatori una sorta di mezzo segreto per connettersi alle applicazioni nell'ambiente di produzione. Questa è davvero una minaccia un mito della sicurezza; ma è rapidamente offuscato da qualcuno che ha abbastanza conoscenze da decodificare e talvolta semplicemente annusando la rete.

Di solito il motivo principale per cui queste minacce sfuggono allo scoperto quando mancano nella fase SDLC di progettazione di sistemi / applicazioni; quindi quando si va in un ambiente di produzione è troppo costoso per le cose da riparare da quel momento in poi. È qui che cominciano a emergere soluzioni alternative o di copertura.

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

Inoltre, come fattore di mercato dovresti sapere che tali pratiche sono normalmente seguite da fornitori / community a codice chiuso; per un progetto open source questo concetto non si applica a scopi pratici in quanto il codice viene rilasciato al pubblico per la revisione e quasi chiunque può affrontare le preoccupazioni attraverso tecniche come la revisione del codice. Il modo migliore e più affidabile per catturarlo.

Sconfiggi la sicurezza SSH tramite il concetto di oscurità esempi pratici

1. Esegui la scansione di nessus sulla rete mirata porterebbe i servizi vulnerabili e le porte mappate
2. Esegui scansione nmap su rete mirata per servizi aperti.

La sicurezza attraverso l'oscurità non è una sicurezza, forse è più precisamente indicato come "Un sistema di sicurezza è sicuro quanto i suoi segreti sono difficili da indovinare". In realtà, quando si arriva a questo, la crittografia potrebbe essere considerata come 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 difficile da indovinare. 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 mantenere il segreto.

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

I tasti d'altra parte dovrebbero essere casuali, sapendo che alcuni bit di una chiave crittografica, per esempio, non dovrebbero 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 è significativamente influenzata (o attendibilmente quantificabile) dalla segretezza dell'algoritmo, non aggiunge sicurezza statisticamente significativa.

Ciò che rende 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 forniscono generalmente una maggiore sicurezza nella sicurezza che forniscono.

Quindi, in chiusura, la maggior parte della sicurezza comporta un certo livello di oscurità, ma il trucco è di minimizzare la quantità e massimizzare la facilità di proteggere quei segreti mentre si cerca anche di assicurarsi che non ci siano difetti non rilevati che causeranno il sistema di comportarsi male e svela i segreti.

In ogni algoritmo di crittografia, ad ogni prompt di accesso 'sicurezza per oscurità' è un componente importante. Si basa sempre su qualche tipo di conoscenza segreta (ad eccezione dell'autenticazione a due fattori).

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

Un cattivo esempio è un sistema in cui è possibile 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 sonda il sistema e potrebbe determinare l'algoritmo di compressione dal momento in cui prende lo schema di crittografia per codificare diversi messaggi di testo. L'utente malintenzionato ha acquisito conoscenza del proprio sistema, conosce i componenti interni dell'algoritmo zip e potrebbe essere in grado di utilizzare questi dati per determinare la propria chiave. Dall'esterno sembra un algoritmo perfettamente valido, i dati compressi e xor saranno piuttosto casuali, ma rappresentano solo una piccola sfida per un aggressore sofisticato. La tua chiave potrebbe essere molto lunga ma ciò non ti aiuta a distinguere tra oscurità cattiva e buona. Hai incorporato per sbaglio un percorso per acquisire informazioni sulla 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 un altro grande numero primo. Ora, anche con l'algoritmo RSA ben noto, posso darti la mia chiave pubblica, puoi codificare qualunque dato tu voglia con esso ma non perde nessuna informazione sulla chiave segreta .

Per cui è importante distinguere il bene dalla cattiva sicurezza è il tempo necessario a qualcuno per accedere ai dati. Nel tuo esempio specifico che va dalla porta 22 alla 2222 fare è un altro bit di informazioni di cui ha bisogno l'utente malintenzionato, quindi questo è un plus di sicurezza. Poiché è 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 rimane costante la quantità totale di informazioni necessarie per conoscere la chiave segreta , per questo motivo non si ritiene che possa migliorare la sicurezza totale, quindi il detto comune che "sicurezza dall'oscurità" non aiuta.

"Obscurity" riguarda le ipotesi

Penso che "sicurezza per oscurità" sia in realtà su ipotesi errate.

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

• I sai può essere rotto da qualcuno che ha la chiave.
• I supponiamo che non possa essere rotto con altri mezzi. Questo probabilmente è falso.

Se utilizzo un metodo di crittografia comprovato:

• I sai può essere rotto da qualcuno che ha la chiave.
• I hanno una buona prova che non può essere rotto con altri mezzi.

Sto ancora facendo affidamento sull '"oscurità" della mia chiave. Ma questa è l'unica cosa che devo proteggere.

Quindi, per rilevare "sicurezza per oscurità", sfidare ipotesi. Se qualcuno dice "nessuno potrebbe indovinare o rilevare che stiamo facendo X", la risposta corretta è quante prove hai? Lo standard di sicurezza è molto, molto alto.

Lo avrei formulato in questo modo:

'Sicurezza attraverso l'oscurità' si riferisce a una situazione in cui un utente malintenzionato viene deliberatamente fornito con tutti i mezzi / le informazioni necessarie per infrangere il meccanismo di sicurezza, sperando o presumendo che l'attaccante non spenda lo sforzo per rivelalo.

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 decifrare i suoi dati "segreti"; e nessuno dei due sarà attaccante.

La sicurezza "reale" proverà a garantire che un utente malintenzionato non abbia mai tutte le informazioni necessarie a romperlo. Quando si utilizza la crittografia, in sostanza non importa se l'autore dell'attacco ha accesso sia al messaggio di cifratura che dell'algoritmo per crearlo fintanto che la chiave di di crittografia non gli viene rivelata . In questo modo, gli vengono negate le informazioni critiche e non è possibile ignorare le informazioni che ha semplicemente bypassato il meccanismo di sicurezza.

Puoi usare quello che vuoi per la "chiave segreta", ma le porte fanno una scelta sbagliata; ce ne sono solo 2 ^ 16, possono essere sniffati e sono (di solito) statici per la durata della connessione.

Tuttavia, sono stati usati come parte della chiave segreta in passato, quando non c'è altra scelta valida. In particolare, randomizzare la porta è stato utilizzato per contrastare l' attacco di avvelenamento della cache DNS di Kaminsky di alcuni anni fa. Combinato con la randomizzazione della query-ID a 16 bit, questo ci fornisce 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 sniffata, ma è considerata "non un grosso problema" poiché il DNS è sempre stato vulnerabile agli attacchi MITM comunque. C'est la vie.

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

Se possiedi un'intera suite di meccanismi di protezione, potresti dire che uno 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 oscurità" se quel meccanismo di protezione dipende da un attaccante che non aspetta qualcosa, o se quel meccanismo di protezione dipende dall'essere insolito piuttosto che crittograficamente strong. 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 prima ipotesi) e perché non è la porta normale. Tuttavia, proteggere SSH con una password ad alta resistenza è una vera sicurezza, perché è concepito per essere crittograficamente strong. Inoltre, cambiare il tuo nome utente da "root" a qualcosa che non può essere facilmente intuito è anche una vera sicurezza perché c'è una misura di forza crittografica lì: se l'utente malintenzionato non riesce a capire il nome utente, non può penetrare molto bene nel sistema anche se ottengono la password corretta.

Per oscurità, capisco che la tua sicurezza si basa sul fatto che l'hacker non è a conoscenza del tuo algoritmo di crittografia. Hai appena ripristinato i caratteri nelle tue parole, come PASS - > SAPP, o fare obfuscation più complesso, e si può comunicare fino a quando nessuno rileva l'algoritmo. Se svelare l'algoritmo di crittografia infrange tutta la tua sicurezza, allora è l'oscurità, non la sicurezza. La vera sicurezza inizia quando l'hacker non sarà in grado di decifrare il tuo messaggio, dati gli algoritmi di crittografia e decrittografia.

La sicurezza viene eseguita tramite l'autenticazione di essere il destinatario o l'utente previsto. Esistono 3 fattori di autenticazione

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

La maggior parte delle misure di sicurezza utilizza l'autenticazione a fattore singolo. Ad esempio SSH richiede la conoscenza di una password o di una chiave privata (credo si possa dire che richiedere una passphrase per la chiave sia l'autenticazione a due fattori).

L'autenticazione a due fattori è qualcosa che è stato implementato da molti fornitori di servizi e software ultimamente. Ciò richiede due fattori sopra elencati, solitamente 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 può ancora accedere al sistema protetto.

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

L'oscurità può solo farti del male se pensi che ti fornisca una vera sicurezza e adotti pratiche deboli. Tuttavia, l'oscurità può aiutare leggermente perché ti fa guadagnare tempo da vulnerabilità future sconosciute, se cerchi di mantenere le migliori pratiche (passphrase forti, applicare gli aggiornamenti di sicurezza, usare algoritmi e protocolli controllati da sicurezza, ecc.). L'oscurità non impedisce un attacco da parte di qualcuno che ti ha bersagliato se il tuo sistema è vulnerabile, ma non promuove il fatto che tu sia vulnerabile al mondo intero.

Se avevi un'app Ruby On Rails e lo avevi annunciato pubblicamente e si trovava in vacanza lo scorso gennaio, le persone avrebbero potuto eseguire comandi arbitrari sul tuo server web. In effetti, la pubblicità avrebbe permesso agli aggressori di trovarti molto più velocemente di quanto avrebbero dovuto indovinare casualmente quale tipo di stack tecnologico stavi eseguendo e provare ogni sito web casuale.

Oppure diciamo che c'è una debolezza del giorno zero trovata in SSH; un po 'come il problema di generazione della chiave SSH di Debian di qualche anno fa. Le persone inizieranno la scansione a caso per trovare ssh in esecuzione sulla porta 22 su indirizzi IP casuali e quindi eseguire l'exploit. Certo, potrebbero prima eseguire una scansione delle porte per cercare ssh, ma gli attaccanti prima cercheranno il frutto basso. Una ricerca completa renderebbe la scansione più di 10000 volte più lenta. Spero che a questo punto abbia corretto il problema. La maggior parte degli indirizzi IP casuali non avrà ssh o altro in esecuzione su di essi, quindi è logico che gli hacker 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 su porte ma non su 39325, probabilmente passeranno prima di trovare il tuo server ssh. Questa è l'oscurità che ti aiuta. Sì, un intercettatore della rete potrebbe banalmente trovare la tua porta in ascolto su una connessione SSH. Ma per la stragrande maggioranza degli aggressori che ti hanno bersagliato in modo casuale, non avranno osservato una connessione SSH ascoltando il traffico di rete. Inoltre, anche per quegli aggressori, il 99,9% delle volte ti aspetti che la tua configurazione ssh sia sicura e non abbia vulnerabilità.

E per la seccatura in più di digitare ssh -p 39325 -Y [email protected] , chiunque usi ssh spesso imposta un file ~/.ssh/config (insieme a authorized_keys e id_rsa.pub / id_rsa ) in modo che possano semplicemente digitare ssh foo 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 la sua connessione internet e solo io la uso (la mia macchina a casa, il mio VPS) come una seccatura per convincere tutti a utilizzare la stessa porta come te. Per gli utenti interni multipli al lavoro, lo tengo protetto da firewall verso l'esterno di Internet e richiede l'accesso dall'esterno per passare attraverso una VPN.

Per la cronaca, il mio VPS era solito avere ssh in esecuzione sulla porta 22 e ottenere circa ~ 10000 / giorno tentativi di autenticazione errati (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.

Suppongo che l'oscurità possa essere misurata confrontando il suo valore di sicurezza con quanto complicherà l'utilizzo del mezzo 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 è attiva, insegnare a tutti i nuovi dipendenti di questa sicurezza misura, e alla fine finirà come una nota adesiva allegata ai display dell'utente o agli script automatici con la porta codificata, annullando quindi 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 significati originali di funzioni e variabili (ad esempio con un attento debugging) rendendo l'offuscamento inutile. D'altra parte, devi ricordare di eseguire un programma speciale prima di compilare il codice o (cosa ancora peggiore, ma l'ho visto) basta lavorare sul codice con una convenzione di denominazione strana.

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