Pete Finnigan's Oracle Security Weblog

I just saw a link to a post by Steve Karam on an ISACA list and went for a look. The post is titled "Password Verification Security Loophole". This is an interesting post discussing the fact that ALTER USER IDENTIFIED BY VALUES bypasses password management and specifically the password complexity function. Steves test shows this but to be honest I would say that this on balance is probably is not a security loophole and intended behaviour as it stands now as this is unsupported syntax so its hard to suggest that the password management should work when we are supposed to use the correct ALTER USER syntax or PASSWORD from SQL*Plus which uses the OCI function. It will be interesting to see if Oracle respond to Steves post and correct it or not. If we think about the logic of this, this is syntactic sugar for "update user$ set password='blah' where name='name'; should the password management also include this ALTER USER syntax and even UPDATE is another thing; for this second discussion "should" not "expected" is that it probably should include these two syntaxes also....but lets get to why it doesnt work....

To close the loop it may be possible to block this abuse with a DDL trigger, you could run the same veriifcation function in a DDL trigger that captures changes to the USER object but you would need the password first - i.e. the actual clear text password not the hash. This could work for simple passwords and my password cracker written in PL/SQL could help with this but it wont work for complex functions. Steve said:

"While Pete Finnigan has created a Password Audit tool to check for default passwords, I don’t believe there’s any method to check existing passwords for complexity."

The cracker doesn't just check default passwords, it aslo checks password=username, defaults (1475 defaults passwords known), a dictionary of words, brute force up to 2 characters and also it checks role passwords.

To be able to check an existing password for complexity you would need to crack that password first from its password hash so that you could analyse the clear text password. If the password were complex and 8 characters or longer that cannot be done with a simple password cracker written in PL/SQL or even in C in a reasonably short time - i.e. the time to run an ALTER USER IDENTIFIED BY VALUES command. This is why Oracle do not enforce the password management when this syntax is used; hence my statement that this is intended behaviour if not desirable. If the clear text password is known (which it is during a proper ALTER USER command to change clear text password) then a verification function can be used.

A program to test against complexity is only possible when you have the clear text password.

Interestingly there are two new password verification functions in 12c to choose from that are better than 11.2, one is more secure than the other. This is good but like 11.2 they are not enabled by default. Also it is interesting to think about a verify function that enforces complexity. This is worthless if the rest of the peofile is not set. i.e. a password complexity function where there is not life time is meaningless as the function may never fire. Or a user with a lifetime and no complexity function is also useless as when the password expires it can be reset to a weak value.

Nice post though Steve!