Tecnicamente leggermente, sì. Ma:

• Sarebbe sicurezza per oscurità, che è una cattiva idea
• Non aumenta la fiducia nel tuo prodotto
• Sarebbe molto facile capire cosa fa cosa, ci vorrebbe solo un po 'di tempo
• Google Traduttore, puoi semplicemente usare nomi privi di significato, non sarebbe comunque di grande aiuto
• Renderebbe più difficile la manutenzione
• Renderebbe molto difficili gli audit, poiché gli auditor potrebbero non capire la lingua

Tutto considerato, probabilmente non vale mai la pena it.

Non sarebbe sensibilmente più sicuro. I reverse engineer sono spesso costretti a lavorare con sistemi che non hanno alcun nome originale intatto (il software di produzione spesso rimuove i nomi dei simboli), quindi si abituano a gestire i nomi che sono stati generati da un computer. Un esempio , preso da Wikipedia, di uno snippet del tipo di codice C decompilato che si vede spesso:

  struct T1 * ebx; struct T1 {int v0004; int v0008; int v000C;}; ebx->v000C - = ebx->v0004 + ebx->v0008;  

Le persone che sono abituate a lavorare con questo tipo di rappresentazione non si lasciano ingannare dall'uso di variabili e simili a cui vengono dati nomi irrilevanti. Questo non è specifico per il codice compilato e l'uso di C era solo un esempio. I reverse engineer in generale sono abituati a comprendere il codice che non è intuitivo. Non importa se stai usando JavaScript, Java o C.Non importa nemmeno se non stanno analizzando nient'altro che la comunicazione con l'API stessa. I reverse engineer non si lasceranno ingannare dall'uso di nomi di funzioni o variabili casuali o irrilevanti.

Non proprio: tutte le funzioni integrate saranno ancora in inglese, quindi non ci vorrà molto sforzo in più per capire cosa rappresenteranno le tue variabili. Potrebbe rallentare leggermente qualcuno, ma dato che le persone riescono ancora a decodificare il codice con variabili a carattere singolo ovunque, o che è stato eseguito attraverso offuscatori, scambiare il linguaggio utilizzato per variabili e funzioni significa semplicemente fare una ricerca e sostituzione una volta che hai capito a cosa serve una delle tue variabili, poi ripeti finché non hai abbastanza comprensione.

Questa è sicurezza attraverso l'oscurità e ritarderà di cinque minuti un attaccante dedicato.

Se vuoi confondere un attaccante, nominare le cose il loro contrario o qualcosa di non correlato avrebbe lo stesso effetto. Quindi la tua funzione "crea utente" potrebbe essere chiamata "BakeCake". Ora puoi rispondere a te stesso quanta sicurezza ti dà. In realtà, questo sarebbe più sicuro, in quanto non può essere sconfitto semplicemente utilizzando un dizionario.

Sì, all'inizio confonderebbe, ma uno sguardo al sistema in operazione e tutto diventa immediatamente cristallino.

Il tuo sistema DEVE essere sicuro da solo. Se si basa sul javascript lato utente che passa un parametro con il valore "open sesame", stai sbagliando.

Dovresti sviluppare il programma nella lingua che ti è più conveniente (es. Basata sulla tua competenza di programmatore, coerenza con la tua base di codice, o anche con i termini che stai usando).

Altre risposte hanno già sottolineato come non fornisca realmente sicurezza. Se vuoi creare un programma sicuro, piuttosto che preoccuparti di potenziali hacker che leggono facilmente il tuo codice e apprendono un buco segreto, dovresti probabilmente preoccuparti di renderlo leggibile alle persone che lo controllano .

Se c'è un parametro di funzione chiamato nonce e un commento che dice come ci assicuriamo che sia unico tra le richieste, ma non viene inviato sulla richiesta, puoi essere certo che si tratta di un errore. In realtà, avere quel codice facilmente leggibile ridurrà le possibilità che quel parametro venga eliminato / vuoto (dopotutto, tutto ha funzionato senza di esso...), o se ciò accade davvero, renderà più facile che un altro dei tuoi gli sviluppatori notano il problema.

(Anche terze parti potrebbero suggerirti di farlo. Probabilmente, ci saranno più persone che lo guardano casualmente di quelle che stanno effettivamente cercando di romperlo. Molto probabilmente un attaccante casuale lo farà inizia lanciando uno strumento automatico e sperando che trovi qualcosa.)

TL; DR: produce codice leggibile. Per le persone che dovrebbero affrontarlo. In caso di dubbio, dovresti preferire quello di cui la maggior parte delle persone conosce.

Potrebbe persino peggiorare le cose rendendo il sistema più difficile da mantenere.

Prendi un esempio estremo ispirato alla storia e comunica tra il fronte e il retro in Navajo. Quando (non se) hai bisogno di patchare il codice devi:

• lavorare con ciò che per te non ha senso (con la possibilità in più di bug / errori di battitura più ci vuole più tempo per lavorare su non -codice intuitivo), o
• assumere / mantenere fluenti programmatori in Navajo (una combinazione di abilità rara e potenzialmente costosa, forse impossibile da trovare un appaltatore)

Vorrei anche notare che nella maggior parte dei casi per javascript sul lato client, lo script così come sviluppato (con nomi di variabili significativi, ecc.) verrebbe "minimizzato" per aumentare le prestazioni sul client (file di dimensioni inferiori da scaricare).

Come parte di questo, la maggior parte dei nomi delle variabili viene ridotta a singoli caratteri e viene eliminato il maggior numero di spazi bianchi possibile. Questo diventa quasi illeggibile come qualsiasi altra cosa che potresti scrivere.

Vorrei anche notare che chrome (ad esempio) ha metodi che accettano un file "meno leggibile dall'uomo" come questo e lo "stampano abbastanza" rendendo molto più facile capire cosa sta succedendo.

In breve, il linguaggio umano che usi per scrivere il codice lato client non fa davvero una grande differenza.

Se si deve credere ai mass media, la maggior parte degli hacker sono russi, cinesi, nordcoreani, quindi già operano con l '"handicap" di dover hackerare i sistemi occidentali in un lingua non nativa. Pertanto, a meno che tu non scelga qualcosa di incredibilmente oscuro, come nel film Windtalkers , non farà alcuna differenza per loro. Ma lo sforzo extra per te significa meno tempo per trovare e correggere i bug, quindi semmai questa strategia renderebbe la tua sicurezza più debole .

Diverse risposte hanno (giustamente) sottolineato che questa è "sicurezza attraverso l'oscurità", che in realtà non è una forma di sicurezza. È più sicuro presumere che l'aggressore abbia del codice sorgente completamente annotato di fronte a sé mentre attacca attivamente.

Il software è "sicuro" quando sa tutto ciò che può essere conosciuto prima di una richiesta / transazione / la sessione è di dominio pubblico E questo non ha alcun impatto sulla sicurezza effettiva del prodotto.

Il codice sorgente deve essere considerato di pubblico dominio, se non altro perché i dipendenti scontenti non vengono presi sul retro e sparati quando vengono eliminati. O come si dice spesso, "L'unico modo per due persone di mantenere un segreto è se una di loro è morta". Pertanto, si deve presumere che qualsiasi "conoscenza speciale" nascosta da offuscamento di qualsiasi tipo sia diventata "conoscenza generale" non appena viene prodotta.

La sicurezza, in sostanza, non è altro che " dire quello che fai e fare quello che dici ". L'analisi della sicurezza - controllo del codice e schemi di valutazione formale, come quelli condotti in base ai Common Criteria - richiede che i meccanismi per eseguire un'azione siano ben documentati e che tutte le transizioni da uno stato protetto a un altro stato protetto siano possibili solo quando tutti i requisiti sono soddisfatti. Un rischio con offuscamento di tutti i tipi è che questi requisiti sono oscurati da una codifica intelligente - vedere l'esempio di "create_user ()" che fallisce perché è "segretamente" il metodo "cancella utente" o "rinomina utente" o qualcos'altro. Per un esempio reale di quanto sia difficile tale ridenominazione sul cervello, ci sono test in linea in cui è necessario leggere il nome di un colore che è stampato sullo schermo in un colore diverso. Ad esempio, la parola "ROSSO" scritta in un carattere blu farà sì che un certo numero di persone dica "BLU" invece di "ROSSO".

Potrebbe essere irrilevante. Considera lo scenario in cui stai programmando in (ad esempio) italiano invece che inglese, ma la maggior parte dei tuoi clienti è in Italia, naturalmente gli hacker di lingua italiana hanno una maggiore motivazione / ricompensa dall'attaccarti.

In questo scenario, la codifica in un'altra lingua non ha alcun effetto o può persino rendere più facile l'hackeraggio.