App Security: To Build or To Buy? – Part 1: Protecting The Front Door To Your App: The Login

This is the first article in the 3-part series: App Security: To Build or To Buy? 

When building any software application, making it secure is a top priority. But security software is very complex and very risky to build yourself. Do you task your development team to design their own? Or do you buy it from a vendor?

Asking your team of developers to build the security that protects and powers your solution is risky, not to mention an unnecessary time and resource drain, taking your team away from their core value.

Be Massively Scalable & API-driven

You may be experts in the financial, social, gaming or other industry specific features of your software. But are you well versed in, or up to date on, implementing important security mechanisms? Security requires an expertise of its own. It is a critical piece in the construction of applications, and unless you already have a team of highly trained security developers, you don’t want to be taking the risks of building your own solution, keeping it current and monitored.

Many people think that buying a solution means building a server, installing software and configuring it, which results in costly long-term maintenance of the operating system, database and vendor’s software. While this was true in the 1990’s, it doesn’t accurately describe today’s massively scalable and API-driven cloud services.

Investing in software exposed via a cloud API allows you to buy and THEN build. You have full control over how the technology integrates into your application, without the headache of running and maintaining the infrastructure.

Username + Password ≠ Protection

Everyone knows that requiring just a username and password is not enough to secure application access and yet this is still the most commonly used method. The problem is not the idea of passwords, but rather that people choose to use passwords that are appallingly vulnerable or use the same password across many accounts.

Passwords can however still be effective when paired with other information and protocols. In the security industry, we refer to these extra pieces of information as factors, and they break down into three main categories:

• Something you know, i.e. something knowledge-based; like your password, username, PIN, and security question responses.
• Something you have, i.e. a device, smart card, or USB token.
• Something you are, i.e. a trait of your human self. This is usually in the form of biometrics, like iris scanning or fingerprints.

Username + Password ≠ Protection + 2FA  = Better Protection

Using more than one piece of information to secure access to applications is called two-factor (2FA) or multi-factor authentication (MFA). 2FA technologies have been around for a while, in the 80’s and 90’s they typically involved an expensive 2FA device that was shipped to every employee.

Nowadays the common smartphone can perform the same 2FA role. Many 2FA projects begin under the belief they can be integrated for free and/or are trivial to build. In practice, neither is true, making the age-old question of whether to “Buy or Build” more critical than ever.

Get Our Free White Paper

Learn more about the most common and immediate problems any developer faces protecting the front door to an application:  Why You Can Buy Your Application Security And The Build With It

Next week: Part 2 – The Pitfalls Of Developing Your Own 2FA