10g refers to 10.1 (10g Release 1), unless otherwise indicated. 1. Literal characters in wrapped PL/SQL code used to be shown in plain text (see groups.google.com/groups?selm=b3cb12d6.0205231329.6f0a4f5e%40posting.google.com). Not any more in 10g. (For more info, see http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Finnigan.pdf) 2. Unless a remote listener is protected by a password, you could remotely stop a listener even if you don't have access to the oracle account on the server (See item 15 at ../computer/OracleIdiosyncrasies.html). In 10g, this is not possible. 3. Before 10g, if you grant select any dictionary privilege to a user, that user can select everything in a table owned by SYS including LINK$ (somewhere between 9.2.0.1 and 9.2.0.5, select from LINK$ becomes prohibited). But in 10g, select any dictionary allows you to view everything in SYS except LINK$ (but DESCRIBE sys.link$ works). [Update for 10.2: SYS.LINK$ no longer has clear text passwords.] 4. (CREATE|ALTER) USER IDENTIFIED BY VALUES continues to work (even in 11g). But the DB link "version" changes behavior. Before 10gR2 including 10gR1, CREATE DATABASE LINK IDENTIFIED BY VALUES throws syntax error ORA-988 "missing or invalid password(s)" pointing to VALUES. Beginning with 10gR2, the syntax is accepted and the link is created. But when you use it, you get ORA-600 [kzdlk_zt2 err]. See Note:456320.1. [Update 2013-08] 12c no longers allows the syntax; it throws ORA-02153 5. Some privileges are granted to fewer users/roles in 10g on default installation. CREATE ANY PROCEDURE and EXECUTE ANY PROCEDURE are no longer granted to MDSYS, CTXSYS. (You could use these privileges to grant you any privilege/role you want!) CREATE ANY TRIGGER is no longer granted to XDB, MDSYS, CTXSYS. (You could use this privilege to capture data inserted into other users' tables.) DBMS_SYS_SQL is still granted to a user, XDB in 10g but MDSYS in 9i. (see http://downloads.securityfocus.com/library/oracle-security.pdf for some of these hacks) [Update for 10.2: CONNECT role contains only CREATE SESSION privilege, no more other privileges; But there's no change to RESOURCE role, including the behavior that granting RESOURCE also grants UNLIMITED TABLESPACE privilege behind the scenes.] [Note for 11gR2: Revoking UNLIMITED TABLESPACE will revoke already-granted unlimited tablespace quota from that user, too. Check dba_ts_quotas and alter user quota (either unlimited or some quota number) again as needed. Ref: http://www.itpub.net/viewthread.php?tid=1308626&pid=16038301&page=1&extra=#pid16038301 ] [Update for 12c] Granting RESOURCE role no longer grants UNLIMITED TABLESPACE privilege. 6. In early 9i versions, although you only see the first 20 characters[note] of ALTER USER username IDENTIFIED BY password in v$sql% views, you were able to see the full SQL text including password in a library cache dump at level 3 or above, unless the shared pool is flushed in between (Incidentally, this is why SQL*Plus PASSWORD command is better than SQL ALTER USER command except in a batch script). GRANT command has the same effect (only the first 20 characters are in v$sql). In 10g as well as later versions of 9i (9.2.0.5 e.g.), level 3 dump no longer shows the SQLs. A level 4 or higher dump is needed. But the dumped SQLs will replace each character in the new password with a *. So you only know how many characters are in the password but you don't know what they are. In fact, any SQL that has the IDENTIFIED BY clause behaves like this: CREATE USER ... IDENTIFIED BY ... CREATE DATABASE LINK ... IDENTIFIED BY ... CREATE ROLE ... IDENTIFIED BY ... GRANT TO ... IDENTIFIED BY ... In addition, in 10g, the out argument of function ora_sql_txt in the trigger fired on the above SQLs will contain asterisks for the password following IDENTIFIED BY. The number of asterisks indicates the number of the characters in the password. In 9i, the clear password is captured by ora_sql_txt without being replaced with *'s. SQL> create or replace trigger t 2 after grant on yhuang.schema 3 declare 4 thesql ora_name_list_t; 5 n int := ora_sql_txt(thesql); 6 begin 7 dbms_output.put_line(thesql(1)); 8 end; 9 / Trigger created. SQL> set serverout on SQL> grant create session to newuser identified by newuserpassword; grant create session to newuser identified by *************** Grant succeeded. The above test is done on 10g. In 9i through 12c, having a password_verification_function for the profile a user belongs to will reveal clear text password if the user changes the password while the DBA enables SQL trace with bind variable for the user's session: PARSING IN CURSOR #3 len=123 dep=1 uid=0 oct=47 lid=0 tim=591671736650 hv=669917137 ad='6ab351bc' declare n boolean; x number; begin n:=sys.VERIFY_FUNCTION(:1, :2,:3); if n = TRUE then x:=1; else x:=0; end if; :4:=x; end; END OF STMT ... Bind#1 oacdty=01 mxl=32(09) mxlc=00 mal=00 scl=00 pre=00 oacflg=10 fl2=0001 frm=01 csi=178 siz=32 off=0 kxsbbbfp=6ab0e822 bln=32 avl=09 flg=09 value="SECRETPASSWORD" Without password_verification_function in the user's profile, the password value would be the password hash value (or * in 12c). SEE ALSO: ./Security12cEnhanced.txt _______________________ [note] The 20 character limit due to security is mentioned in Bug 208503.