43

I'm developing a system with communication via REST between front (JavaScript) and back end (Java/Spring) and this question popped up.

Does it makes this system more secure to name variables, URLs, etc in a language other than English?

I imagine it could because, since the most important programming languages are in English, it's likely most programmers know at least a bit of it. Naming our stuff in another language could make hacking more difficult because the attacker would have a harder time to understand what means and does what.

I couldn't find results on Google because "programming" an "language" together makes it impossible to find results about the other meaning of "language".

  • 8
    Related – Joe Apr 30 '18 at 14:02
  • 59
    Lots of JavaScript is already obfuscated/minified for sake of size/bandwidth usage. – multithr3at3d Apr 30 '18 at 15:27
  • 45
    @Joe Alternatively, related – JAB Apr 30 '18 at 19:47
  • 16
    if you consider time an aspect of security, then yes, bad code takes longer to hack, which makes it safer. – dandavis Apr 30 '18 at 22:49
  • 10
    Any good programming tool would allow someone to scopefully rename variables, so even if you're not initially sure what the variable gezhundheit means, you could rename it to Thing1 to make it readable in English (or your language of choice) until you've parsed that it should then be renamed BlessYou and move on from there. – FreeMan May 1 '18 at 11:27

10 Answers 10

174

Technically slightly, yes. But:

  • It would be security by obscurity, which is a bad idea
  • It does not boost confidence in your product
  • It would be very easy to figure out what does what, it would only take a bit of time
  • Google Translate, you can just use meaningless names, it would still not help much
  • It would make maintenance harder
  • It would make audits very hard, as the auditors may not understand the language

All things considered, it is probably never worth it.

  • 63
    To emphasize Peter's point on maintenance with some personal experience: it is already hard to work on old code or code that somebody else wrote. Adding a foreign language to the mix would be nightmarish. Doubly so if comments aren't in English. If your staff speaks a language besides English, OK, then do whatever you want. Otherwise, I'd give the idea a hard "No". – DoubleD Apr 30 '18 at 19:14
  • 57
    It's a common misconception that security through obscurity is a "bad idea" per se but that is not correct. What's a bad idea is to rely on security through obscurity. If you're following best practices elsewhere then it can be fine as an added component to defence in depth. Often such tactics are useless at worst and marginally useful at best. A good example is running SSH on a non-default port. (I'm not saying that the OP's example is justified however). – Jon Bentley Apr 30 '18 at 23:18
  • 21
  • 33
    I feel you're downplaying the last two points. Obscurity of this sort will make it harder for others to spot weaknesses in the system, no? Seems to me we can expect security to be actively weakened by this practice. – Max Barraclough May 1 '18 at 13:37
  • 18
    @dandavis Fixing vulnerabilities is an important part of the software lifecycle. Anything that complicates that process is generally bad, and this is especially true for zero-days. If you slow the development process, you extend the window of zero-day vulnerability. I don't see a significant improvement from such an approach. Plus, just because your programmers are unfamiliar with a language doesn't mean your adversaries are too. I would assume there are adversaries fluent in any given language, which is actually a handicap if your programmers are not. – DoubleD May 1 '18 at 15:15
63

It would not be appreciably more secure. Reverse engineers are often forced to work with systems that do not have any original names intact (production software often strips symbol names), so they get used to dealing with names that have been generated by a computer. An example, taken from Wikipedia, of a snippet of the kind of decompiled C code that is often seen:

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

People who are used to working with this kind of representation are not fooled by the usage of variables and such that are given irrelevant names. This is not specific to compiled code, and the use of C was just an example. Reverse engineers in general are used to understanding code that is not intuitive. It doesn't matter if you are using JavaScript, or Java, or C. It does not even matter if they are analyzing nothing but the communication with the API itself. Reverse engineers are not going to be fooled by the use of random or irrelevant variable or function names.

36

Not really - all of the built-in functions will still be in English, so it wouldn't take much extra effort to work out what your variables are going to represent. It might slow someone down slightly, but given that people still manage to reverse-engineer code with single character variables all over the place, or which has been run through obfuscators, swapping the language used for variables and functions just means doing a find-replace once you've worked out what one of your variables is used for, then repeating until you have enough understanding.

  • 16
    To add, people can reverse engineer code from machine code. People have figured out how to hack complicated games by just looking at how their memory changes when they do actions. And that's without how the front end of the web forces you to give actual source code (even minimized, that's considerably higher level, and thus patterns are more evident). There's also anti-obfusification tools that try to somewhat undo some of the trickier obfusification techniques (and of course, code formatters also help). – Kat May 1 '18 at 22:30
  • While this is correct in the case of Java / JavaScript, there are also some programming languages that use a non-English language for their built-in functionality. Though the obscurity of those languages may be more relevant to security than their function names. – KWeiss May 3 '18 at 6:43
  • 1
    Not just reverse engineer games from runtime analysis, but even create completely working source code that compiles into exactly equivalent bytecode, turning a closed source game into a multiplatform game! – forest May 5 '18 at 7:29
21

That is security through obscurity and will delay a dedicated attacker all of five minutes.

If you want to confuse an attacker, naming things their opposite or something unrelated would have the same effect. So your "create user" function could be named "BakeCake". Now you can answer yourself how much security that gives you. Actually, this would be more secure, as it can't be defeated by simply using a dictionary.

Yes, at first it would confuse, but one look at the system in operation and everything becomes crystal clear immediately.

  • 3
    It wouldn't be more secure, especially as reverse engineers (for example) often don't even have the original symbol names to work with, so are already used to working with completely made-up names or identifiers. – forest May 1 '18 at 5:50
  • 1
    We are talking about a REST, i.e. a web application. An attacker is far more likely to analyse the web interaction than the Java bytecode. – Tom May 1 '18 at 6:00
  • 1
    My point is that reverse engineers are already used to this kind of thing, even if they're not doing actual decompilation. I wrote an answer to that effect, with C reverse engineering merely as an example. – forest May 1 '18 at 6:01
  • 2
    Naming things after their opposites would be more likely to introduce bugs than naming in a foreign language. "And then, we call create_user and... Wait, why does it keep saying 'account does not exist'? Of course it doesn't exist -- that's why I'm trying to create it!" But +1 for your more general point. – David Richerby May 1 '18 at 12:40
  • Of course it's a silly idea and I don't recommend it. But from a purely security perspective, it would be more secure. :-) (not every secure idea is a good idea) – Tom May 1 '18 at 20:51
9

Your system MUST be secure by itself. If it relies on user-side javascript passing a parameter with the value "open sesame", you are doing it wrong.

You should develop the program in the language that is more convenient for you (eg. based on your coder proficiency, consistency with your code base, or even with the terms that you are using).

Other answers already pointed out how it doesn't really provide security. If you want to make a secure program, rather than concerning about potential hackers easily reading your code and learning a secret hole, you should probably care more about making it readable to the people auditing it.

If there is a function parameter called nonce, and a comment saying how we are ensuring it is unique across the requests, yet it isn't sent on the request, you can be quite sure it is a slip-up. Actually, having that code easily readable will decrease the chances of that parameter being dropped/empty (after all, everything worked without it...), or if that really happens, make easier that another of your developers notices the problem.

(Third parties could hint you about it, too. Probably, there will be more people having a casual look at it than ones actually trying to break it. A random attacker will most likely start by launching an automated tool and hoping it finds anything.)

TL;DR: produce readable code. For the people that should deal with it. In case of doubt, you should prefer the one most people know about.

  • 1
    Sure, I never intended to use language as a security measure. I was just curious about the community's thoughts on the matter. – GuiRitter May 1 '18 at 22:24
  • This. Either your application is secure or it isn't. The language you use for naming parameters has zero effect on making it more secure. – Anentropic May 2 '18 at 12:59
7

It could even make things worse by making the system harder to maintain.

Take an extreme example inspired by history, and communicate between front and back ends in Navajo. When (not if) you need to patch the code you need to either:

  • work with what to you is nonsense (with the extra chance of bugs/typos plus it takes longer to work on non-intuitive code), or
  • hire/keep programmers fluent in Navajo (a rare and potantially expensive skill combination, possibly impossible to find a contractor)
  • 1
    Your comparison has severe problems. Navajo was extremely rare and not a written language. The OP could simply be asking about a common language in his/her geographic location (i.e. the available dev talent pool speaks it). Also, translations could also be maintained on the dev end. – schroeder May 1 '18 at 14:21
  • 3
    @schroeder My choice of an oral language was perhaps poor, but the historical aspect made for an interesting analogy. I carefully read the question for any hint about the developers' language, but even then there are major business aspects in terms of future out- or even in-sourcing. e.g. take the stereotypical case of outsourcing to India, and use Hindi. Then when the bosses decide to bring the maintenance in house for political reasons you have to find fluent developers. I did say it was extreme, to make a point – Chris H May 1 '18 at 14:38
5

I would also note that in most instances for javascript on the client side, the script as developed (with meaningful variable names etc) would be 'minified' in order to increase performance on the client (smaller file size to download).

As part of this, most variable names are reduced to single characters and as much whitespace as possible is stripped out. This becomes just about as unreadable as anything else you might write.

I would also note that chrome (for example) has methods that take a 'less human readable' file like this and 'pretty print' it, making it a lot easier to figure out what is going on.

In short, the human language that you use to write your client side code really doesn't make a big difference.

4

If the mass media are to be believed, then the majority of hackers are Russian, Chinese, North Korean, so they are already operating under the “handicap” of having to hack Western systems in a non-native language. Therefore unless you choose something incredibly obscure, like in the movie Windtalkers it won’t make any difference to them. But the extra effort for you means less time for you to find and fix bugs, so if anything this strategy would make your security weaker.

2

Several responses have (rightly) pointed out that this is “security through obscurity”, which isn’t actually a form fo security. It is safest to assume that the attacker has fully annotated source code sitting in front of them while busily attacking away.

Software is “secure” when knowing everything which can be known in advance of a request / transaction / session is public knowledge AND this has no impact on the actual security of the product.

Source code must be assumed to be public knowledge, if only because disgruntled employees aren’t taken out back and shot when they are terminated. Or as is often said, “The only way for two people to keep a secret is if one of them is dead.” Thus any “special knowledge” which is being concealed by obfuscation of any sort must be assumed to have become “general knowledge” as soon as it is produced.

Security, at its core, is nothing more than “saying what you do, and doing what you say.” Security analysis — code auditing and formal evaluation schemes, such as are conducted under the Common Criteria — requires that the mechanisms for performing an action are well-documented and that all transitions from one secure state to another secure state are only possible when all the requirements are satisfied. One risk with obfuscation of all sorts is that these requirements are obscured by clever coding — see the example of “create_user()” failing because it is “secretly” the “delete user” or “rename user” or something else method. For a real-world example of how hard such renaming is on the brain, there are on-line tests in which you must read the name of a color which is printed on the screen in a different color. For example, the word “RED” written in a blue font will result in some number of people saying “BLUE” instead of “RED”.

0

It might be irrelevant. Consider the scenario where you're coding in (e.g.) Italian instead of English, but most of your customers are in Italy, naturally Italian-speaking hackers have a higher motivation/payoff from attacking you.

In this scenario, coding in another language has either no effect or it can even make it easier to hack.

  • 2
    This is just rules-lawyering. The scheme would so obviously be pointless if the language chosen was the one spoken by most of the users that we can be sure the asker meant to exclude that. – David Richerby May 1 '18 at 12:46
  • Yes, but presumably there are not many scenarios where the dev team can be relied on to always know the same non-English language and the community that uses the application don't know that language. – bdsl May 3 '18 at 9:38
  • 1
    Actually there are plenty of bilingual communities and markets. A lot of developers for the italian market are in Albania, so they can make the development in a different language. Same for developing in Hindu for an english speaking app, etc. All I wanted to point out is that the language of the users/targets will play a roll on how much "security" this factor can provide. – JoaoBotelho May 3 '18 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.