¿Es más seguro programar un sistema cliente-servidor en un idioma que no sea el inglés?

Técnicamente un poco, sí. Pero:

• Sería security by obscurity , lo cual es una mala idea
• No aumenta la confianza en su producto
• Sería muy fácil averiguar qué hace qué, solo tomaría un poco de tiempo
• Google Translate, solo puedes usar nombres sin significado, aún así no serviría de mucho
• Haría más difícil el mantenimiento
• Haría las auditorías muy difíciles, ya que los auditores pueden no entender el idioma

A fin de cuentas, probablemente nunca valga la pena.

No sería apreciablemente más seguro. Los ingenieros inversos a menudo se ven obligados a trabajar con sistemas que no tienen intactos los nombres originales de ninguno (el software de producción a menudo elimina los nombres de los símbolos), por lo que se acostumbran a tratar con los nombres generados por una computadora. Un ejemplo , tomado de Wikipedia, de un fragmento del tipo de código C descompilado que se ve a menudo:

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

Las personas que están acostumbradas a trabajar con este tipo de representación no se dejan engañar por el uso de variables y los nombres que reciben nombres irrelevantes. Esto no es específico del código compilado , y el uso de C fue solo un ejemplo. Los ingenieros inversos en general están acostumbrados a entender el código que no es intuitivo. No importa si está utilizando JavaScript, Java o C. No importa si solo están analizando la comunicación con la API. Los ingenieros inversos no se dejarán engañar por el uso de variables o nombres de funciones irrelevantes o aleatorias.

En realidad no: todas las funciones integradas seguirán estando en inglés, por lo que no se necesitaría mucho esfuerzo para determinar qué representarán las variables. Puede ralentizar un poco a alguien, pero dado que las personas aún logran aplicar ingeniería inversa al código con variables de un solo carácter en todo el lugar, o que se ha ejecutado a través de ofuscadores, el intercambio del idioma utilizado por las variables y las funciones solo significa realizar una búsqueda y reemplazo. una vez que haya averiguado para qué se usa una de sus variables, repítalo hasta que tenga suficiente comprensión.

Eso es seguridad a través de la oscuridad y demorará a un atacante dedicado durante cinco minutos.

Si quieres confundir a un atacante, nombrar a las cosas como su opuesto o algo no relacionado tendría el mismo efecto. Por lo tanto, su función "crear usuario" podría denominarse "BakeCake". Ahora puedes responderte cuánta seguridad te da. En realidad, esto sería más seguro, ya que no puede ser derrotado simplemente usando un diccionario.

Sí, al principio se confundiría, pero un vistazo al sistema en funcionamiento y todo se vuelve muy claro de inmediato.

Su sistema DEBE estar seguro por sí mismo . Si se basa en que javascript del lado del usuario pasa un parámetro con el valor "abrir sésamo", lo estás haciendo mal.

Debería desarrollar el programa en el idioma que le resulte más conveniente (por ejemplo, en función de su competencia como codificador, la coherencia con su base de código o incluso con los términos que está utilizando).

Otras respuestas ya indicaron que realmente no proporciona seguridad. Si desea crear un programa seguro, en lugar de preocuparse por los posibles piratas informáticos que leen fácilmente su código y aprenden un agujero secreto, probablemente debería preocuparse más por hacerlo legible para las personas que lo auditan .

Si hay un parámetro de función llamado nonce, y un comentario que dice cómo nos aseguramos de que sea único en todas las solicitudes, pero no se envía en la solicitud, puede estar seguro de que se trata de un error. En realidad, tener ese código fácilmente legible disminuirá las posibilidades de que ese parámetro se descarte / vacíe (después de todo, todo funcionó sin él ...), o si eso realmente sucede, facilita que otro de tus desarrolladores se dé cuenta del problema.

(Los terceros también podrían sugerirlo al respecto. Probablemente, habrá más personas que lo vean de manera casual que los que realmente intentan romperlo. Es probable que un atacante aleatorio comience lanzando una herramienta automatizada y esperándolo encuentra algo.)

TL; DR: produce código legible. Para las personas que deben lidiar con ello. En caso de duda, debería preferir el que más conoce la gente.

Incluso podría empeorar las cosas al hacer que el sistema sea más difícil de mantener.

Tome un ejemplo extremo inspirado en la historia y comuníquese entre las partes delantera y trasera en Navajo . Cuando (no si) necesita parchear el código que necesita para:

• trabajar con lo que para usted es una tontería (con la posibilidad adicional de errores / errores tipográficos, además de que lleva más tiempo trabajar en código no intuitivo), o
• contrata / mantiene a los programadores con fluidez en Navajo (una combinación de habilidades rara y potencialmente costosa, posiblemente imposible de encontrar un contratista)

También observaría que en la mayoría de los casos para javascript en el lado del cliente, la secuencia de comandos desarrollada (con nombres de variables significativos, etc.) se 'minimizaría' para aumentar el rendimiento en el cliente (menor tamaño de archivo para descargar).

Como parte de esto, la mayoría de los nombres de variables se reducen a caracteres individuales y se elimina todo el espacio en blanco posible. Esto se vuelve casi tan ilegible como cualquier otra cosa que puedas escribir.

También observaría que Chrome (por ejemplo) tiene métodos que toman un archivo 'menos legible por humanos' como este y que 'lo imprimen', lo que hace que sea mucho más fácil averiguar qué está pasando.

En resumen, el lenguaje humano que usa para escribir el código del lado del cliente realmente no hace una gran diferencia.

Si hay que creer a los medios de comunicación, entonces la mayoría de los hackers son rusos, chinos, norcoreanos, por lo que ya operan bajo la "desventaja" de tener que hackear los sistemas occidentales en una lengua no nativa. Por lo tanto, a menos que elija algo increíblemente oscuro, como en la película Windtalkers , no habrá ninguna diferencia para ellos. Pero el esfuerzo adicional para usted significa menos tiempo para que encuentre y solucione errores, por lo que, en cualquier caso, esta estrategia debilitaría su seguridad .

Varias respuestas han señalado (con razón) que esto es "seguridad a través de la oscuridad", que en realidad no es una forma de seguridad. Es más seguro suponer que el atacante tiene un código fuente completamente anotado sentado frente a ellos mientras ataca de inmediato.

El software es "seguro" cuando se sabe que todo lo que se puede saber antes de una solicitud / transacción / sesión es de conocimiento público Y esto no tiene ningún impacto en la seguridad real del producto.

Se debe asumir que el código fuente es de conocimiento público, aunque solo sea porque los empleados descontentos no son retirados y fusilados cuando son despedidos. O, como se suele decir, "la única forma en que dos personas pueden guardar un secreto es si una de ellas está muerta". Por lo tanto, se debe asumir que cualquier "conocimiento especial" que se oculta por ofuscación de cualquier tipo se ha convertido en "conocimiento general". "Tan pronto como se produzca.

La seguridad, en su esencia, no es más que "decir lo que hace y hacer lo que dice". El análisis de seguridad (auditoría de código y esquemas de evaluación formal, como los que se llevan a cabo bajo los Criterios comunes) requiere que los mecanismos para la realización de una acción está bien documentada y que todas las transiciones de un estado seguro a otro estado seguro solo son posibles cuando se cumplen todos los requisitos. Un riesgo con la ofuscación de todo tipo es que estos requisitos están ocultos por una codificación inteligente; vea el ejemplo de "create_user ()" que falla porque es "secretamente" el "eliminar usuario" o "cambiar el nombre de usuario" o algún otro método. Para un ejemplo del mundo real de cuán difícil es el cambio de nombre en el cerebro, existen pruebas en línea en las que debe leer el nombre de un color que se imprime en la pantalla en un color diferente. Por ejemplo, la palabra "ROJO" escrita en una fuente azul hará que varias personas digan "AZUL" en lugar de "ROJO".

Puede ser irrelevante. Considere el escenario en el que está codificando (por ejemplo) italiano en lugar de inglés, pero la mayoría de sus clientes están en Italia, naturalmente, los piratas informáticos que hablan italiano tienen una mayor motivación / recompensa al atacarle.

En este escenario, la codificación en otro idioma no tiene ningún efecto o incluso puede facilitar la piratería.