Database Reference
In-Depth Information
7 rows selected
SQL> alter user pwtest identified by asecure12password replace a;
User altered.
SQL> alter user pwtest identified by asecure12password replace asecure12password;
alter user pwtest identified by asecure12password replace asecure12password
*
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20010: Password should differ from the old password by at least 3
characters
But note that the profile restrictions do not apply to SYS on 12c:
SQL> alter user sys identified by a;
User altered.
This has been the case in 11g and is a bug bear for security folks. Why omit the most powerful account from
password control? Surely it is the account that needs the most protection? There is some good news in that a
new
_sys_logon_delay
parameter introduces a one-second delay after failed logon attempts for SYS, partially
counterbalancing the lack of enforced SYS password complexity via profiles, but that is not good enough on its own.
As a security auditor I want to check that the password value for SYS is secure and force it to stay that way.
There has been some improvement in that the verification function has a more sophisticated method of
calculating how unique password updates are by using the Levenshtein Distance between two strings.
Rem Function: "string_distance" - Calculates the Levenshtein distance
Rem between two strings
The main reason for enforcing variety in subsequent passwords is because an attacker that has gained the
previous plaintext may be able to guess subsequent plaintexts; for example consider this sequence of passwords:
Password1, password2, password3 etc. (short Levenshtein distance).
This password history is enabled by the historic record of old passwords in
sys.user_history$
SQL> SELECT name, password_date
2 FROM sys.user$, sys.user_history$
3 WHERE sys.user$.user# = sys.user_history$.user#;
no rows selected
But by default password history is not turned on in 12c as indicated by the UNLIMITED value for
password_reuse*
parameters. I think this should be turned on otherwise users will simply “ping pong” between two passwords as below.
SQL> alter user pwtest identified by asecure123456password replace asecure12password;
User altered.
SQL> alter user pwtest identified by asecure12password replace asecure123456password;
User altered.
