While I will discuss APEX specifically later in this article, the content here really applies to any web based application.
Most of us as developers fall into a false sense of security when we establish our password policy. I too was guilty of this until I took the time to look into the subject more thoroughly.
Hopefully by the end of this article you will understand the issues with your current password policy and how it can lead to vulnerabilities. Remember that behind your application, there is a database that holds a lot of organisational data as well as client specific information that you are responsible to protect.
All the time in the news we hear of very large corporations that have experienced password breaches resulting in critical customer information being exposed. We are horrified by this and put the blame squarely on the company that we have trusted with our personal information regardless of their privacy policy. If big corporations can be hacked, then why can’t our simple user facing application be hacked.
It is a known fact that most users create very bad passwords.
I am not going to insult you by pointing out that the storage of passwords as a string in the database is a monumentally bad idea. None of us I hope would ever do this. In a moment we’ll discuss how to do this in a better way.
Clearly you do need a password policy, but you do need to think carefully about the components of that policy.
In terms of hacking passwords, I will really be discussing offline file hacking as opposed to online directly against your application. Hackers are very intelligent and sophisticated in their methods. The offline file approach would mostly be the method they would use to access your data.
An offline file simply means that your user passwords have been accessed as a file that the hacker can find and use to crack passwords. We'll look at some real examples of how this is done.
Obviously how you store the passwords in the database is a key issue. You absolutely must encrypt the passwords as first line of defense. You need to store the passwords as a hash value.
There are two kinds of hashes – a “one way” hash and a “two way” hash.
A two way hash means that you have some sort of key or function that allows you to unhash the value stored in the database. Some organisations use this to enable them to send an email to their user if the user has forgotten their password. This is an unforgivable mistake.
A one way hash means that you can never your self access the value in the database. The hash is created in the value of the hash can only be accessed by the end user. You do this by hashing values that only the user knows. One way of doing this is to hash the combination of the username and the password
So the point is here that you will always want to use a one way hash to ensure that it cannot be unhashed by any database administrator or developer.
Now that we have a good method to store the passwords in the database we can move on to looking at our password policies.
To assess the real strength of the passwords against an attack, I will use the following site:
http://www.howsecureis my password.net
These sorts of sites are not really accurate but it is at least a place to start.
First let’s consider the situation where we have no password policy at all. I’ll use the typical password below:
Password1
When we type this in to the password analysis on the site, this password can be cracked instantly. This is absolutely insecure.
Now what if we require the user to have at least one number and a special character. My password now will be:
p@word1
When we type this in we can see that this password can be cracked in only 2 seconds. Clearly we still have a huge risk.
Well we can changed our policy to require a length of 7 and two numbers and one uppercase letter and one special character. Here we go:
Or@cl3!
Probably looks familiar doesn’t it? A much more complex policy has been used here. When we type this into the site we see that it can be cracked in 7 minutes.
You might be very surprised that the complexity is not so important as is the length of the password. This time my password will only have lower case letters and nothing else.
Here we go:
iliketodrinkwineatlunch
A pretty simple password,right? Type it into the site and look at the result. This password will take 277 trillion years to crack.
So with an 11 or more length requirement really protects us much more and the vulnerability is significantly reduced.
Now it is time to see the really scary stuff.
I have installed a program called Hashcat that is a popular cracking program among hackers.
I will show you how a malicious hacker might actually crack your passwords.
I am going to assume that a list of our hashed passwords has been exposed and the hacker got a hold of this file.This could happen in a lot of ways such as sql injection against your application
The password file I am using contains around 6,500 md5 hashed passwords. You can create your own file by using one of the many online hash generators.
We will try and crack passwords using a number of different attacks.Be aware that I am doing this on my PC with only one GPU. Hashcat uses the GPUss to process. This should make things even a bit more scary.
The first attack we will perform is called a Brute Force attack. It is probably the simplest of all attacks and will deal with passwords that have letters and numbers and are of a length around eight digits.
The attack starts looping through the hashes by first guessing something like “aaaaaa: and then “aaaaaaab: and so on. It will iterate all of the possible combinations and compare them to the hashed password.
We call hashcat and give it the file.
It recovered 1020 hashed passwords at a rate of 139 million hashes attempts per second.
Here is an example of the passwords it recovered:
The cracked passwords appear after the “:” on each line. You can see that the passwords are not very long nor complex. But this is likely the first attack type a hacker will attempt. The attack completed very quickly and you can see that we matched and cracked a fairly large number of the hashed passwords.
The attack results were pretty good but we still have a ways to go.
Now using the same file we will use a dictionary attack.
A dictionary attack is much more sophisticated than the Brute Force attack
A dictionary may be a list or words in the English language or it may be a list of passwords that have already been cracked through previous breeches. Since hashes always are the same for a specific value, we can compare the hashes to previously cracked passwords against our current hash file. These lists of previously cracked passwords come from other very large hacks of large organisation. It is unlikely that a user’s password, or part of it, has been used by another user for another system.
But we don’t want to just use the dictionary. We want to also apply rules to the dictionary values.
For instance, we can toggle between lowercase and uppercase values. Or try using symbols to replace letters. Now the possible combinations greatly increases.
I am using a dictionary of about 12 million words and a rule set of a lot of different rules and combinations. Basically the attack tests each hash by comparing it to the dictionary and then applies the rules . It has a fair bit of work to do so it will take a bit longer.
Let’s run the dictionary attack against our hashed password file :
This time it recovered another 2,299 hashed at a rate of 20 million hash attempts per second.
Here is an example of the passwords it cracked this time.
You can see that the passwords are a lot longer and complicated.
I could keep going and use other dictionaries and rule sets. In a normal attack the password file may be a lot larger and the passwords more complicated.
Remember the speeds we are getting are based on only one GPU.
Scared yet?
When you use a crack time estimator like the site we have been using here, you should know that they are not entirely accurate. They indeed do give us an indication of how long it might take a hacker to crack our password, but it can only predict in a general way.
The estimators do not really consider the processing speed that may be available to the hacker. Hackers use some powerful tools but they all rely on GPUs or graphic cards. These GPUs are getting more powerful every day. Usually a hacker will have a machine made up of several GPUs rather than just one. The number of crack attempts could be up to several billion per second. The crack time estimators have no way of determining the exact hardware that a hacker might be using.
Another way that the estimators cannot really assess is the sophistication of some of the dictionary attacks is they don’t know the hashing algorithm that the developer has used to store the passwords.
Generally you should understand that md5 is no longer acceptable. There have been so many breeches based on md5 hashes, that it has become very easy to crack them if the dictionary is long enough. It is now best to use SHA256 or SHA512. Oracle 12c has support for using a SHA256 hash.
Here’s what I mean In the earlier dictionary attack we recovered the password “energizer000000”. It was recovered in the first 11 minutes of the attack.
Going back to our estimator site and typing in the password “energizer00000” the result is that it will take 175 thousand years. Not quite as we have seen.
If you consider the password “iliketodrinkredwine” it is made up of the following words:
I like to drink red wine
The phrase will not truly be that difficult to crack. There are several words that appear to be standard phrases:
I like red wine
In other words, these words would often follow each other in the English language. The associated familiarity of the phrase makes the dictionary attack easier.
But consider the following password:
drawerbufferturtlepalm
It consists of the following individual words:
drawer buffer turtle palm
These are not very common words and there is no real connection between the words. A dictionary attack is much harder as it would have to combine all four words in exactly this same order.
Now, let’s at this minor change:
draw@er!bufferturtlepalm
A slight change has been made here. Special characters have been added to the phrase but note that they are not used to replace characters but are inserted into the words. The dictionary attack becomes very difficult as the individual words won’t be found exactly as they appear here.
When you replace letters with special characters rather than inserting them into the word, you are not really fooling the hacker. Users, for instance, often replace “a” with @ or an “I” with 1. Hackers know these tricks and they software they use already evaluates in this way.
How then do I deal with things in an APEX Application?
This is exactly the same for APEX since it accesses key data from our Oracle database and uses public database connections to process data.
When it comes to APEX, the security of passwords really has to do with the authentication. The authentication we use is a way of identifying the user and ensuring the password they use is correct.
There are some preconfigured authentication methods available to us. One of them is to authenticate the user by reference to LDAP. This is a good method since as a user joins or leaves an organisation, the LDAP information is updated. The only issue here is that the user will be able to access all of your applications with the same credentials. You need to control this.
You can create your own custom authentication and this might work best for you as it is flexible and can validate the authentication of the user to address your specific needs including the method by which you encrypt the password for storage in the database.
Now this might be another surprise. As of Apex 18.1, we have another authentication method available to us. We can allow the user to be identified by way of their social media account such as Google or Facebook. In reality, this is a very secure method. In essence you are turning the issue over to them. Each of the social media accounts have really strong password policies and storage. They also, in some instances, use what is called “two factor verification". This means that they have used two ways to validate the user. Often it may be an OTP or an SMS with a verification code. Since only the user has this information, the validation of the user is much more secure. Generally, most social media accounts store their passwords in quite sophisticated ways and thus may be a good choice for your application.
In addition to your authentication scheme in APEX, you must also define an authorisation scheme. APEX does not require this as default, but you must never overlook the importance of defining an authorisation scheme.
You can think of authorisation in APEX as defining responsabilities or roles. Think about it. If you do not define specific authorisations, any user that is in LDAP account can access all of your APEX applications and view data or transact.
I usually use a custom authentication as it gives me more control over the password processing as well as an ability to do some fine grain authorisation.
But, here is where my approach is somewhat different and is based on all the information above.
Where I have a “change or reset password page”, I replace the the placeholder of the password field to “Passphrase”.
The password policy I implement is really quite simple :
-- It must be at least 14 characters long
-- It cannot contain the user's first or last name
-- The same passphrase cannot be used twice in a row
--The passphrase will expire every 30 days.
A lot of web applications are starting to use the concept of a “PassPhrase”. User’s need to be educated on what a passphrase is. So on the page I make sure there is a link that will help the user to understand what it is and how to select one.
The guidance I usually provide is something like this:
-- Your passphrase should be something that you can easily remember and type
-- Choose three or four words
-- Choose words that are unusual and really don’t belong together
-- You might want to use your favourite band name or something like that for one of the words
-- You can use symbols as part of the words but insert them rather than replacing letters with them
-- Here are a few examples but you are not allowed to use these exact ones:
b
eyelemonsink@level
tornattackfridgelink
· - Do not use the same phrase for any other application or web service
Next I maintain a blacklist of words that cannot be used as part of any passphrase. This list may include such words as:
Password
Apex
Login
,,, and so on.
When validating a user’s selected pass phrase, I first check that it does not contain any of the blacklist words, and then make sure that it complies with the policy.
Passphrases, if done correctly are very secure and are less prone to any kind of attack. They are very easy for the user to remember and less likely to be typed with any errors. It will just take a bit of time to educate the user but in my experience they really like it and have provided some very positive feedback on the concept.
Some people recommend that users make use of some sort of password manager in to manage the specific passwords for applications and only require the user to remember one master password. Users can then create very random strings that are difficult to crack. This is a pretty good idea but with APEX I do not use a password manager.
It is my view that with APEX a password manager makes it very difficult, if not impossible, to access a APEX Workspace or an Apex application from any other machine than yours. I often do training and consultation where it is not always possible to use my own machine. If an APEX application is truly a web application, you should be able to access it from anywhere and from any machine.
I hope that at at the very least this article has got you thinking and reassessing how you store passwords in the database and how you set a policy that will be secure now and going forward.
Hackers get more and more advanced in their techniques all the time. We owe it to our users and our customers to protect their access security now and tomorrow. Secure access to your application is a constant process of evaluating your current measures against the current advances in password cracking across the internet.'
Want to see if you have been hacked?
Many applications set your email address as the username for your account. And, sadly, a lot of users tend to use the same password on more than one site.
You can check if your email address has ever been subject to a password crack on any site by going to the following URL:
https://haveibeenpwned.com/
Just type in your email addressed and it will show you if any password associated with the email addressed has ever been compromised.
Now provide a name for the new table to be created. The Error Table Name will be used to create a second table: This error table will be used to store rows, which cannot be inserted into the target table.
Why? 
