Names Given To Computers

[Mr. Analog]

True, and that is why it isn't the only security measure we utilize, just one of many.

Well if you can't trust a security measure it's not important, you could name your servers anything you want if you rely on something stronger.

[Cova]

Security didn't factor into our name choices at NAIT at all - nor would I ever recommend using "security through obscurity" for anything - even if only an additional layer.

We use random fictional names because it puts some enjoyment into what can be a boring/repetitive job.  Also - just because names are taken from say TV shows, doesn't mean the names don't carry any meaning.  For example, most of the servers involved in our Student-Admin system are named Todd, Rod, Jimbo, Nelson, etc. - the Student Admin system servers are students from the Simpsons.  The ESX farm is all Futurama names - when you see Leela on the network you have a pretty good idea what it's doing.  When I see a star-wars name, I know it's something Russ created.

Also - even in a large environment, "name" names have some advantages.  Though us sys-admins end up having a LOT of names to try and remember (good admin tools make that easy), the users/developers still typically only deal with a few machines (we often also let the developers pick names for the dev DB servers and stuff) and it makes it easier for them to not have to remember/type obscure abbreviations.

[Thorin]

So you make it harder for yourself to determine whether a compromised server is important or not, by naming it obscurely?  Really, as much as it makes it a smidgen harder for a hacker to figure out what the server does (although they typically compromise a server and then determine what they can do with it), it also makes your job harder.

Obscurity does not provide security.  "Security through Obscurity" is a misnomer and people relying even partially on that misnomer need to give their head a shake.  All obscurity does is make a security analyst's job harder, thereby making the whole of the security set-up more fragile.  After all, it's the security analyst who has to understand the entire system so that they can envision all possible attack vectors and remove or reduce them as much as possible.

If anything, I would define the "Security through Obscurity" that so many people refer to as Fuzzy Security:

Fuzzy security. Fuzzy security is actually the notion used by cryptographers throughout history until the last few decades. By fuzzy security I mean the following process: some guy comes up with some sort of cryptographic algorithm (let's think about an encryption scheme, but one can also think of other examples, such as hash functions or obfuscators). He then makes some vague claims about the security of this algorithm, and people start using it for applications of national or personal security of the utmost importance. Then, someone else (a hacker) manages to break this algorithm, usually with disastrous results to its users, and then the inventor or users either "tweak" the algorithm, hoping that the new tweak is secure, or one invent a new algorithm. The distinguishing mark of fuzzy security is not that it is often broken with disastrous outcomes. This is a side effect. The distinguishing mark is that there is never a rigorous definition of security, and so there is never a clearly stated conjecture of the security properties of this algorithm. Another common mark of fuzzy security is keeping the algorithm a secret. This is indeed unsurprising - if you don't know exactly what is the security of your algorithm, and you don't really understand what makes it secure, then keeping it secret seems like a good way to at least prolong the time it takes until a hacker finds a bug in it.

I want to stress that I do not intend to discredit the cryptographers throughout history that constructed "fuzzily secure" algorithms. Many of these people were geniuses with amazing intuitions, that paved the way for modern cryptography. However, this does not mean that we need to use their algorithms today. Today for most cryptographic tasks we do not need to use fuzzy security, since we have very good security definitions, and constructions that are reasonably conjectured to satisfy these definitions. One exception is indeed obfuscators, where so far no one has come up with a good definition for the security properties of obfuscators. Also (and this is not a coincidence) progress in obfuscator research seems to be of the sort mentioned above. One guy builds an obfusactor, an industry uses it, it gets broken, and then they build a new obfuscator (and/or try to pass laws making breaking obfuscators illegal..)

But hey, I know enough to know that none of us on this forum are security experts.  There are ninety-nine ways to do security wrong and only one way to do it right.  I know enough that I don't know for sure what that one way is.

[Melbosa]

Security didn't factor into our name choices at NAIT at all - nor would I ever recommend using "security through obscurity" for anything - even if only an additional layer.

We use random fictional names because it puts some enjoyment into what can be a boring/repetitive job.  Also - just because names are taken from say TV shows, doesn't mean the names don't carry any meaning.  For example, most of the servers involved in our Student-Admin system are named Todd, Rod, Jimbo, Nelson, etc. - the Student Admin system servers are students from the Simpsons.  The ESX farm is all Futurama names - when you see Leela on the network you have a pretty good idea what it's doing.  When I see a star-wars name, I know it's something Russ created.

Also - even in a large environment, "name" names have some advantages.  Though us sys-admins end up having a LOT of names to try and remember (good admin tools make that easy), the users/developers still typically only deal with a few machines (we often also let the developers pick names for the dev DB servers and stuff) and it makes it easier for them to not have to remember/type obscure abbreviations.

I stand corrected.  I was miss-informed.