For decades, inexperienced programmers have tried jury-rigging security
onto software by implementing simplistic tricks that rely on obscurity
rather than tried-and-true security measures. The assumption is that an
attacker won't know to try something, and thus would not be able to get
access to the software.

For example, lets say we have some fictitious Web-enabled device with
an administrative interface living at http://example.com/XXXXXXX/,
where XXXXXXX is the device's serial number. The manufacturer figures
that only the administrator would be able to look on the back of the
device and read the serial number, and thus this should be 'secure
enough'.

The Problem
An attacker could easily discover that the admin interface is based on
the serial number. Perhaps she has one of these units herself, or she
finds newsgroup message from someone asking a question about the
device. Regardless, the attacker need only whip up a quick 3 line shell
script to try all possible URLs until they stumble on the correct one,
and then there's nothing stopping them from taking over.

Had the manufacturer implemented some sort of password authentication,
then the URL could have been something standard, say '/admin/'. Knowing
the URL would do the cracker no good as she'd still need to know the
password.

Security Through Obscurity
This kind of 'security' is called 'Security through Obscurity' and it
is anything but. Ask any security guru and they'll constantly remind
you that relying on Security through Obscurity is a vulnerability
waiting to happen. To develop a solid security foundation, you must
determine exactly what bits need to be secret and make sure that they
are both secret and something that can be changed. In general, we're
talking about passwords, keys, certificates, etc

» posted by ITworld staff

ITworld

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine