One of my favourite security “tricks” used to be the following:

SQL> [create|alter] user MY_USER identified by values 'impossible';

Looks odd, but by setting the encrypted value of someone’s password to something that it is impossible to encrypt to, means you’ll never be able to connect as that account. (Think schema’s owning objects etc).

I hear you ask: “Why not just lock the account?”

Well…in my opinion, that’s a security hole. Let’s say Oracle publishes a security bug concerning (say) the MDSYS schema. As a hacker, I’d like to know if a database has the MDSYS schema. All I need do is:

SQL> connect MDSYS/nonsense

Why is that a security hole ? Because I wont get “Invalid username or password”. I’ll get “ORA-28000: the account is locked” and voila…Now I know that the MDSYS user is present in that database.

Setting a user password to a impossible encrypted value, means a hacker will never know if the user account exists at all, because the error returned is the familiar “ORA-01017: invalid username/password; logon denied”

But looked what’s happened in 12.1.0.2 😦

SQL> create user MY_USER identified by values 'impossible';
create user MY_USER identified by values 'impossible'
*
ERROR at line 1:
ORA-02153: invalid VALUES password string

A backward step in my opinion…

2 responses to “12.1.0.2 security grrr…”

  1. Kombajn zbożowy Avatar
    Kombajn zbożowy

    This should work 🙂
    CREATE USER my_user IDENTIFIED BY VALUES ‘S:000000000000000000000000000000000000000000000000000000000000;0000000000000000’;

  2. That is still possible, with the caveat that Oracle started enforcing to use valid hex characters (0-9, A-F) when you force a hash.

Got some thoughts? Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trending

Blog at WordPress.com.