When designing software, the inclusion of sufficient security has always been vital. Hackers and thieves that want to steal data are constantly adapting and developing new ways to get into software and systems, usually by exploiting gaps or flaws in the design. There are a number of approaches web developers and software engineers can take in attempting to prevent this from happening.
Security through Obscurity
Imagine that you take all of your money and bury it under a tree. The only thing making it safe is that no-one knows it’s there.
This is an approach often adopted by engineers when it comes to developing software. By keeping the design of the software as secretive as possible, they believe known flaws can be left in. If nobody knows about them and they are hard to detect, the theory is that the software is less likely to be exploited by attackers. Instead of fixing problems, they are merely hid.
However, many weaknesses are frequently raised about this approach. Though a flaw may be well-hidden, attackers are so persistent that sooner or later it’s likely to be discovered. Indeed, the skill of attackers is often underrated; the sad truth is that if you are capable of discovering the flaw, it is likely they are able to as well. Simply put, it should never be used as an alternative to proper security techniques.
Security by Design
Instead of putting your money under a tree like in the above example, imagine putting it in a safe. You could put the safe anywhere you wanted – even on a street corner. People will be aware it’s there but you know the money is safe because only you can get inside.
This approach seems more logical than using obscurity. Rather than hiding a system, effort is instead made into keeping its contents safe. It revolves more around encryption of passwords and data, and extra care and time is spent designing the software in a secure way. It is vastly different to the security by obscurity approach in that its design is completely open because it is believed to be secure.
This approach can backfire, as attackers have easy access to the code to analyse for flaws. A developer needs to be very confident that the software they have built is secure to take this approach.
Which is best?
The harsh reality is that software can never really be made 100% safe. Attackers are too skilled and too abundant. Look at what happened to Sony and PlayStation Network recently – you’d expect a large system with millions of users to have top security – yet a team of dedicated attackers were still able to break through reasonably easily. All you can do as a developer is make the task as difficult and frustrating for an attacker as possible.
Because of this, in general, a ‘defence in depth’ approach is considered the best method. Obscurity has its place – but not as the sole line of defence. Instead, it should be used as an extra line of defence for software that has been designed and built in a secure way.