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".

Script47
  • 217
  • 1
  • 11
GuiRitter
  • 565
  • 1
  • 4
  • 5
  • 8
    [Related](https://security.stackexchange.com/questions/35828/obfuscating-javascript-code) – 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](https://xkcd.com/257/) – 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 01 '18 at 11:27
  • Every day around the globe people learns how to code before learning english, so in a sense they work mostly with concepts and not with meaningful translatable words. – alo Malbarez May 02 '18 at 02:27
  • 1
    Are you suggesting Russian, Mandarin, Cantonese or Hindi? Anyway if the language is compiled without symbolic debugging information, what is the difference? Your code should be secure even though it is readable, you want it to be independently reviewed, right? – Jodrell May 02 '18 at 14:38
  • If you want to make the code really hard to read, use a common language but misname your functions, types and variables to give readable but incorrect, misleading names. My customers do it all the time (Joke, see previous comment.) – Jodrell May 02 '18 at 14:45
  • 1
    This would make things difficult for you just as much as for an attacker. To make it more difficult for the attacker only, you could use a tool (in your build) to rename items to meaningless names. Then the names would not be translatable using a language translator. That would be a small improvement in security. Of course, if you think that your code *needs* obfuscation to be secure, then it is inherently not secure. – John B. Lambe May 02 '18 at 16:05
  • 2
    @dandavis I don't agree with that statement. Bad codes usually contains more errors and thus it is *easier* to attack. If you find a vulnerable SQL injection point you don't care about the code anymore, just about exploiting it. Same with other command injections vulnerabilities: once you find them exploiting is a matter of trial & error. Understanding the limited portion of code that creates the security hole makes it simpler to understand how to exploit it, but just trial &error is enough. And bad code = more holes = faster to find an exploitable point. – Bakuriu May 02 '18 at 17:27
  • @dandavis - any reason to consider code written in non-English language bad besides your own bigotry? – Davor May 03 '18 at 13:58
  • 1
    @Davor: bigotry is untoleance of an _opinion_. OP is not suggesting coding in another spoken language, which is fine if consistent, the issue is about using obscure variable names, aka bad code. To wit: a french coder using Swahili names is bad code. – dandavis May 03 '18 at 21:59
  • @dandavis - you clearly wrote that using other languages besides English makes code bad. If you meant to say something different, you failed at it. – Davor May 04 '18 at 09:06
  • Dein attacker savoir każdy 語言. – hamena314 May 04 '18 at 10:56
  • As someone who has had to read code with Japanese comments, I found the Japanese comments easier to understand than their odd mixture of hungarian notation and stupidly short variable names. If the variable names had been in Japanese, I think it would have been much easier to read because I could just look the names up in a dictionary instead of trying to guess their intent from the initials. – Pharap May 06 '18 at 03:08

10 Answers10

172

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.

forest
  • 64,616
  • 20
  • 206
  • 257
Peter Harmann
  • 7,728
  • 5
  • 20
  • 28
  • 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
  • 1
    @DoubleD: you say it makes code manipulation (aka maintenance) "nightmarish", but then you say "hard no" on "is it more secure"? If i can't figure out how something works, or how to successfully modify it, isn't that by definition more secure, akin to adding spool pins to a tumbler lock to increase pick time? – dandavis Apr 30 '18 at 22:48
  • 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
    [*"The enemy knows the system."*](https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle) – anaximander May 01 '18 at 08:52
  • 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 01 '18 at 13:37
  • 3
    The biggest vulnerabilities I've seen are bugs or problems with the design of the application discovered through inspection of the code. If I have to deal with strangely named variables then it'll make it harder to find these vulnerabilities. If anything this approach makes it less secure IMO. – AaronLS May 01 '18 at 14:56
  • 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 01 '18 at 15:15
  • 3
    Actually, if someone could decode the raw datastream having them in a different language from the English most programming languages are based on would make it EASIER to pick out the variables. – Weckar E. May 01 '18 at 18:51
  • 1
    @Jon Bentley agreed: To most, opportunistic attackers are the far more likely problem than dedicated ones - and opportunists can be held at bay by being inopportune. – rackandboneman May 01 '18 at 21:30
  • 1
    @MaxBarraclough: "Obscurity of this sort will make it harder for others to spot weaknesses in the system, no?" - that, as well as the two last points stated in the answer, depend very much on whether the "others" that are most likely to see, audit, or maintain the code are fluent in the language used rather than in English. – O. R. Mapper May 02 '18 at 11:07
  • 1
    @JonBentley, `It's a common misconception that security through obscurity is a "bad idea" per se but that is not correct. ` Yeah, well, you know, that's just like your opinion, man! - The Dude. – AnoE May 02 '18 at 21:40
  • Well arguably security through obscurity is sometimes the only way, look at all DRMs. And it can be reasonably effective in those cases, but it should be avoided when it can be. And in this situation it can be. Again, pretty much all DRMs are broken sooner or later, if there is enough interest in breaking them. – Peter Harmann May 02 '18 at 21:51
  • +1 for the maintenance problem. It *may* slightly confuse would-be hackers; it *will* cause an irate code maintainer five years from now to want to hunt you down and kneecap you with a tire iron. Said irate maintainer may even be you. – Shadur May 03 '18 at 11:06
  • @JonBentley **You are demonstrating exactly why security through obscurity _is_ bad.** Running SSH on a non-default port can actually _actively reduce security_, if it is running on a highport (which most people seem to do). Your claim that it is at worst useless is simply incorrect. – forest May 04 '18 at 01:55
  • @forest 1. I said **often** it is at worst useless, not always. Obviously you have to decide any given case on its own merits. 2. Your counter-example demonstrates that implementing something **naively or incorrectly** is bad, not that security through obscurity **per se** is bad. The same principle applies equally to standard security measures. Many systems allow extremely common or easily brute forced passwords. That doesn't make passwords a bad idea. – Jon Bentley May 04 '18 at 02:21
  • @JonBentley Security through obscurity increases the chances of doing something incorrectly. Obviously the mere knowledge an attacker has of an algorithm or system does not and cannot improve security, but that doesn't mean trying to actively prevent them from gaining this knowledge doesn't come with it high risks of making things worse. – forest May 04 '18 at 02:23
  • I can't in good conscience upvote this as long as it begins with "technically slightly yes." Because that is simply not true. – jpmc26 May 04 '18 at 09:49
  • @jpmc26 As much as I discourage doing this, it is hard to deny it would have some benefit. While it does nothing against a determined attacker, most attacker are opportunistic. If one site is harder to hack because of different language then a similar other site, they may choose the other one. And most disadvantages I listed are a bit situational/can be avoided. So it does provide a very small benefit, if they can manage the drawbacks. I would be lying if I tried to deny that. – Peter Harmann May 04 '18 at 09:52
  • @PeterHarmann Are opportunistic attackers going to spend time on a custom web app that requires code in the first place? If the UI is in the attacker's language (or one in which they're fluent), it can't be very hard to glean what is related to the info they're looking for and what isn't. I simply don't see any evidence that there's any real improvement, even against opportunistic attackers. – jpmc26 May 04 '18 at 10:02
  • @jpmc26 Wall, that is why I always emphasize small, slight, not worth it and so on. Obviously it won't by far deter every opportunistic attacker, otherwise it could be worth it. About it being able to deter anyone, it is just my educated guess, that there may be someone who gives up because of it theoretically, although there obviously is no proper evidence for that. – Peter Harmann May 04 '18 at 10:06
  • @Shadur: "it *will* cause an irate code maintainer five years from now to want to hunt you down and kneecap you with a tire iron" - that is an awfully anglocentric point of view. – O. R. Mapper May 07 '18 at 05:15
  • I've chosen this as the answer because it summarizes most points discussed here, but I really liked the one that is not in this list about the system having to be secure even if the attacker knows all about it. – GuiRitter May 12 '18 at 18:54
62

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.

forest
  • 64,616
  • 20
  • 206
  • 257
35

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.

Matthew
  • 27,233
  • 7
  • 87
  • 101
  • 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 01 '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 03 '18 at 06: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 05 '18 at 07: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.

Tom
  • 10,124
  • 18
  • 51
  • 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 01 '18 at 05: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 01 '18 at 06: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 01 '18 at 06: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 01 '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 01 '18 at 20:51
8

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.

Ángel
  • 17,578
  • 3
  • 25
  • 60
  • 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 01 '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 02 '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)
Chris H
  • 4,185
  • 1
  • 16
  • 22
  • 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 01 '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 01 '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.

Paddy
  • 177
  • 4
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.

Gaius
  • 810
  • 6
  • 7
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”.

Julie in Austin
  • 382
  • 1
  • 6
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.

JoaoBotelho
  • 117
  • 2
  • 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 01 '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 03 '18 at 09: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 03 '18 at 14:23