I had a job where a manager said he liked naming servers after places because if they were named descriptively e.g. "passwords database server" they become obvious targets. I sort of generalized this concept and when I'm writing code I avoid naming variables things like "password". Does this help security or does this confuse people who I should be working with?
Giving non-obvious names to things is akin to security through obscurity which is usually frowned upon in these parts. Problem with that kind of security is not that it does not work; indeed, it has some value, which was demonstrated many times through History (e.g. that's why a tank is called "tank" and not "armored chariot"). But you cannot quantify security through obscurity. You cannot know "how much" security it buys you; and, in particular, you cannot know whether it works at all (and though it often works well, it also often fails spectacularly).
Therefore, when thinking about risk management, the value of non-standard names must be considered low. This would not be a problem if it could be done "for free"; but non-standard names have a huge hidden cost: if they confuse attackers, they are likely to confuse sysadmins too. It will siphon out thinking time and resources, and will increase reaction latency if trouble arises.
Really, in IT security and in IT in general, descriptive names are a must-have.
This would be a prime example of Security Through Obscurity. While this does provide some security value, the gain is generally very minimal and it should never be relied upon as an ultimate defense.
As with any security measure, how to balance security and usability here is one which your organization needs to decide. If you can come up with a convenient naming convention that would be reasonably obscure to outsiders, but easy to learn for you and your team, it may be a worthwhile consideration. If you're constantly running into significant problems because people can't remember, or can't easily find a list of, essential server or variable names then it might be time to re-consider whether or not this particular solution is right for you.
If you're writing a security-sensitive piece of code, it behooves you to use names which clearly spell out what all of the sensitive pieces of information are.
If a piece of text is a password, but you call it
string1, then the next programmer who comes in after you might write code that does not treat the variable with proper care.
For instance, he or she might add a debugging statement which spits out the contents of
string1 into a log, making passwords available to someone who can turn on debugging and gain access to the logs.
Anyway, the source code does not actually contain passwords, only variables called passwords, unless it is horribly insecure. Nobody is going to gain any passwords by looking for variables called
password in source code.
There is a big difference between selecting names for servers which do not identify their functionality, possibly making them more obvious targets for hackers and using obscure names in program code.
The names you use for variables in your code do not end up in the final binary/executable of the program. Those names only exist in your source code. If someone has access to the source code, obscure names will provide little protection. However, for those poor maintainers who follow you it will be really inconvenient. In fact, in the long term, it may even decrease the security of the program as later maintainers are more likely to misunderstand or misinterpret what the variable is used for.
When writing code, the first and most important objective is correctness. After that, it is communication of the algorithm and intent of the code. Using variable names which do not acurately reflect the purpose of the variable will detract from this and make maintenance harder. It isthe algorithm which will determine how secure your solution is, not what names you use for variables.
The primary gain you can get from server naming is increasing the need to guess and makes it easier to deploy something like a honeypot to try and identify attackers. It's still security through obscurity and doesn't provide any security in it's own right.
As for using obfuscation in programming code, it's important to consider that depending on the language, this may already be done for you. Many compiled languages will discard the names of methods and variables in releases and code obfuscation tools are available for many languages that either aren't compiled or keep track of variable names (such as .Net).
The main problem with obfuscating names in code is that it decreases security by decreasing readability. Complex, unmaintainable code is almost always less secure since added complexity increases errors and errors can lead to security holes. The best bet is to write very simple, very maintainable code when it is security critical and then if you want to, obfuscate it with a commercial package to make it harder for an attacker to analyze what they need to do to try and attack it.