OWASP exposure - Authentication
What is OWASP?
Open Web Application Security Project is a non-profit organisation founded in the US to analyse, document and share information pertaining to the most common and severe vulnerabilities in today's web applications. Their goal is to educate us - should we fail to do it ourselves - on the security weaknesses that we emply unknowingly in our applications, how to identify them, and how to prevent them. Put simply, they're a bunch of nights in shining armor helping us write more secure web applications.
Their mission, as they state it, is:
The Open Web Application Security Project (OWASP) is a 501c3 not-for-profit worldwide charitable organization focused on improving the security of application software. Our mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. Everyone is free to participate in OWASP and all of our materials are available under a free and open software license.
Each year, OWASP publish a list of the web's top 10 vulnerablities that are found across the globe in an effort to educate and strengthen the applications made available to us all.
It's our job as programmers to take heed of the advice and understand what we're doing wrong and to improve on it.
Top 10 – Authentication
In many web applications these days, authentication is a no-brainer requirement. Or at least that's what you think it is. I'd hazard a guess that most sites out there have some form of authentication – be it login or otherwise – and with that comes a hidden set of requirements that must be fulfilled for you, the owner, to not be lulled into a false sense of security (in every sense of the word).
The typical scenario is one where a user of a website must be logged in to access a particular resource. Simple. So here there's two requirements already;
A registration section for creation of new users
A login section for existing users to be authenticated
Given that the above is so typical, you'd think that this was quite an easy think to implement. Your next steps, you might say, would be to analyse and 'flesh out' a design both for the UI and the back-end aspects of this application. Put simply, we'd need a bare minimum of two web pages: a login form, a registration form. Each of these forms have a destination outside of these requirements – 'home' or 'my account'.
The other component we'd need is somewhere to store the information our registration users give us, and therefore somewhere to look when a user needs to login; a database! Here's where our insecurities start. Not choosing the right storage mechanisms, formats and read/write access for components in your store can render any and all other security paradigms useless. Let's take the most common bits of information in this scenario and look at how we might store it them.
Peeling back the insecurities
The basics here are easy - storing of passwords should be done using a strong encryption algorithm plus 'salt'. You should have a basic set of expectations from the user – minimum length of 6 or 8, 1 number and one uppercase letter. Once you've got this from the user, it should be stored securely.
I've seen numerous times the use of a hashing algorithm – such as MD5 – to ignorantly protect passwords. Whilst on the face of it MD5 seems just fine as it obscures the information, it is also only a hashing algorithm and not encryption. Algorithms like MD5 are good for digesting input to generate the same output; checking file integrity and the like is what it's meant for. If you are using it, at a bare minimum you should introduce password salts, which are hidden bits of information that are added to the password at storage time to ensure dictionary attacks are even more improbable. The best salts are those not known widely or easily within your organisation and even better - generated at runtime – their user ID, password plus first name and a secret token is as great way to make them unique and harder for an attacker to run dictionary attacks.
Are they who they say they are?
You'll often see a bank requiring two different types of 'passwords' in their login forms: passwords and a code, and in some good cases a hidden phrase. For the two banks I use online, a unique identifier is needed to identify me, and then two further unique – known only to me – authentication tokens are asked of me, in randomised form, when logging in. So typically I need to enter a user ID or name, parts of my passcode/password and a secret question or other passcode (of which only sub-parts are required). The best example is having to put in runtime information – such as a code text to me or a number from a public/private key device provided by your bank.
Multi-factor authentication can best be explained by OWASP, thus:
Something you know (account details or passwords)
Something you have (tokens or mobile phones)
Something you are (biometrics)
In all honesty, authentication can be difficult to get right even by the most seasoned professionals. You need to take so much into account.
OWASP has done a really good job on their cheat sheet page to highlight the biggest problems here; everything from session timeout, account lock-out (max retries for login failure), TLS for login and interestingly how you respond to your users when a password or other token is incorrect. Take a look, it's an enlightening read.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)