Remember how above I stated that you really shouldn't be using the Authentication Scheme "as is" because it really isn't that secure?
I am admittedly not a security expert, so normally I would engage someone who is to make sure anything that was going into production was air tight. Back at Oracle there was a whole process we had to go through that reviewed all security aspects of our applications before they were put live. And there were accepted patterns for things like Authentication.
The code in this blog post would not pass muster! And with the help of Christian Neumueller of the APEX Team, here's why.
The HASH_PASSWORD function is vulnerable to a "rainbow table attack." We hear all the time in the news about stolen user/password tables. If somone were able to get ahold of your USERS table, an attacker can build a table that contains username/likely-password/pre-computed-hash and compare the computed values with the stolen hashes. Once they have a match, they know the actual password. The solution is to salt the hashes and repeatedly apply the hash, e.g. using the PBKDF2 algorithm.
Agreed. although there are many things you should be doing to make sure no one is able to get ahold of the underlying USERS table, if they were to get the data, this is a very valid point.
The AUTHENTICATE_USER function is susceptible to a "Timing attack". The HASH_PASSWORD function does not get called when the user does not exist. Therefore, the code path for an invalid username is faster than the one for a valid user. Attackers can use statistical methods to determine whether they guessed a correct username. Your HASH_PASSWORD is fast, because it is simplistic and therefore inadequate - this algorithm MUST be expensive to make it harder for password crackers. In the real world this is a problem.
Again, agreed. The authentication function does the bare minimum in my example and that's on purpose. I wanted something simple that didn't get in the way of the real meat of this article, which was the Authorization Schemes.
BUT what this does prove is what I stated above ... That the authentication scheme is very basic** and is really here for demo purposes only**. It's not really meant for use in a production system. You'd likely want something far more robust such as a Single Sign On, Social Sign on or SAML based Authentication scheme.
Thank you Christian for your excellent explanations.
Doug Gault
Watch Fanatic, Geek, Foodie, Dry Drinker, Traveler, Classic Car Nerd, Techie, Developer, Author, APEX Aficionado.