[20151007]關於11G密碼.txt

[20151007]關於11G密碼.txt

--從11G開始密碼開始區分大小寫的，透過引數SEC_CASE_SENSITIVE_LOGON引數來控制的。該引數預設設定為true。
--我自己曾遇到升級後出現使用者程式不區分大小寫，導致在反覆嘗試後出現library cache lock，我記得當時自己也是手忙腳亂的，因為
--以前沒遇到過，好在當時開發及時發現問題。

-- http://blog.itpub.net/267265/viewspace-1479718/

--正好放假期間，別人的系統升級也遇到這個問題，打電話來問,提示事件出現library cache lock，猜測也是密碼問題。

--最簡單的方法統一密碼，修正程式錯誤，當然應急可以修改引數SEC_CASE_SENSITIVE_LOGON=false。
--我個人認為設定ALTER SYSTEM SET EVENT = '28401 TRACE NAME CONTEXT FOREVER, LEVEL 1' SCOPE = SPFILE最不可取。

--實際上還有最簡單的方法，就是讓這個使用者選擇10g的密碼方式,這也是目前最常用的方式。透過例子來說明：

1.測試環境：
SYS@test> @ver1
PORT_STRING                    VERSION        BANNER                                                                               CON_ID
------------------------------ -------------- -------------------------------------------------------------------------------- ----------
IBMPC/WIN_NT64-9.1.0           12.1.0.1.0     Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0

SCOTT@test01p> select name,password,spare4 from sys.user$ where name='SCOTT';
NAME                 PASSWORD                       SPARE4
-------------------- ------------------------------ ----------------------------------------------------------------------------------------------------
SCOTT                57964D8CE8DC6EB2               S:11492E95A3786A4EF1D415619AA186C2F560E811EF0D5FF99256EC6038E9;H:AFB3A8C4DBB1F9C3271E68E986F0772B
                                                   
SCOTT@test01p> select username,password_versions from dba_users where username='SCOTT';
USERNAME             PASSWORD_VER
-------------------- ------------
SCOTT                10G 11G

--可以發現目前的scott使用者支援10g 11G兩個版本。前面查詢到是10g，11g對應的口令加密串。
--如果查詢檢視定義：

select * from dba_views where view_name ='DBA_USERS';

...
decode(length(u.password), 16, '10G ', NULL) ||
              decode(REGEXP_INSTR(NVL2(u.spare4, u.spare4, ' '),
                                  'S:'), 0, '', '11G ') ||
              decode(REGEXP_INSTR(NVL2(u.spare4, u.spare4, ' '),
                                  'T:'), 0, '', '12C '),

--u 對應 sys.user$，可以發現判斷就是透過sys.user$欄位password,spare4.
--注意1個小細節，12C實際上開頭對應的是T:，我的測試是12c，而選擇的還是11G的口令方式，不知道存在什麼差別，或者將來12c會改變加密演算法。

2.如果執行如下：
SCOTT@test01p> alter USER SCOTT IDENTIFIED BY values '57964D8CE8DC6EB2';
User altered.

SCOTT@test01p> select name,password,spare4 from sys.user$ where name='SCOTT';
NAME                 PASSWORD                       SPARE4
-------------------- ------------------------------ ---------------------------------------------------
SCOTT                57964D8CE8DC6EB2

SCOTT@test01p> select username,password_versions from dba_users where username='SCOTT';
USERNAME             PASSWORD_VER
-------------------- ------------
SCOTT                10G

--這樣等於這個使用者的口令模式回到了10g的模式，依舊大小寫不區分，透過這個方式避免升級出現的問題。大家可以測試。
--如果執行如下，口令模式是11g。

SCOTT@test01p> alter USER SCOTT IDENTIFIED BY values 'S:11492E95A3786A4EF1D415619AA186C2F560E811EF0D5FF99256EC6038E9;H:AFB3A8C4DBB1F9C3271E68E986F0772B';
User altered.

--注：12c在口令串的最後還有1串';H:AFB3A8C4DBB1F9C3271E68E986F0772B',不知道表示什麼，也許PDB裡面的sid名之類的資訊。

SCOTT@test01p> column password format a30
SCOTT@test01p> column spare4 format a100
SCOTT@test01p> select name,password,spare4 from sys.user$ where name='SCOTT';

NAME                 PASSWORD                       SPARE4
-------------------- ------------------------------ ----------------------------------------------------------------------------------------------------
SCOTT                                               S:11492E95A3786A4EF1D415619AA186C2F560E811EF0D5FF99256EC6038E9;H:AFB3A8C4DBB1F9C3271E68E986F0772B

SCOTT@test01p> select username,password_versions from dba_users where username='SCOTT';
USERNAME             PASSWORD_VER
-------------------- ------------
SCOTT                11G

--如果想回到前面支援10g,11G兩種模式，可以使用password修改口令：

SCOTT@test01p> select name,password,spare4 from sys.user$ where name='SCOTT';
NAME                 PASSWORD                       SPARE4
-------------------- ------------------------------ ----------------------------------------------------------------------------------------------------
SCOTT                57964D8CE8DC6EB2               S:6567A66772519C8C47C2911405CCC9AE7C16D6E89F0801B3E91E4B17B607;H:AFB3A8C4DBB1F9C3271E68E986F0772B
                                                                                              ~~~~~~~~~~~~~~~~~~~~    

SCOTT@test01p> select username,password_versions from dba_users where username='SCOTT';
USERNAME             PASSWORD_VER
-------------------- ------------
SCOTT                10G 11G

--注意看我修改的口令還是原來的，PASSWORD還是一樣，SPARE4不同，因為後面slot(~部分每次生成都不一樣)。

3.簡單探究11G口令的加密：
--後面;H:AFB3A8C4DBB1F9C3271E68E986F0772B 對於密碼一樣都是不變的，不知道表示什麼？也許我使用的是12c，估計與pdb有關。密碼變化，這個串也不會邊。
--家裡僅僅有12c環境，上班看了11g確實沒有後面那一串。
--分號前面的20位是slot(佔用10個位元組),如~.
--知道這個9F0801B3E91E4B17B607，加上密碼明文，可以還原加密串。例子：

SYS@test01p> set serveroutput on
SYS@test01p> exec dbms_output.put_line('S:'||dbms_crypto.hash(utl_raw.cast_to_raw('btbtms')||'9F0801B3E91E4B17B607',dbms_crypto.HASH_SH1)||'9F0801B3E91E4B17B607');
S:6567A66772519C8C47C2911405CCC9AE7C16D6E89F0801B3E91E4B17B607
PL/SQL procedure successfully completed.
--對比前面的資訊正好對上。

4.既然使用sh1加密演算法，一些命令列工具也可以實現。
--建立一個檔案，執行openssl dgst -sha1就ok了，測試看看。

$ echo -n "btbtms" | xxd -c 16
0000000: 6274 6274 6d73                           btbtms

--建立檔案aa.txt,因為後面的ascii無法輸入，先輸入如下，後面的資訊是slot，透過xxd轉換就ok了。aa.txt內容如下：

0000000:6274 6274 6d73 9F08 01B3 E91E 4B17 B607

--另外我的測試不要空格也是ok的。

$ xxd -r aa.txt |  openssl dgst -sha1 | tr 'a-z' 'A-Z'
6567A66772519C8C47C2911405CCC9AE7C16D6E8

--對比上面可以發現如果包括slot資訊，內容一致。