[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信息,内容一致。

时间: 2024-07-30 11:01:54

[20151007]关于11G密码.txt的相关文章

[20170607]10g dblink的密码.txt

[20170607]10g dblink的密码.txt --//10g下建立的dblink密码非常容易破解.只要能访问表sys.link$,做一个简单的测试来说明,实际上这个问题在11.2.0.1之前都是存在 --//的. 1.环境: SYS@orcl> @ &r/ver1 PORT_STRING                   |VERSION       |BANNER ------------------------------|--------------|-----------

[20160513]重温11g DRCP.txt

[20160513]重温11g DRCP.txt --以前做过一次测试,再也没有使用过. [20130730]11G的DRCP特性.txt => http://blog.itpub.net/267265/viewspace-767493/ http://www.oracle-base.com/articles/11g/DatabaseResidentConnectionPool_11gR1.php Database Resident Connection Pool (DRCP) in Oracl

[20151109]提升scn号11g测试.txt

[20151109]提升scn号11g测试.txt --以前的测试都在10g下进行的,在11.2.0.4下重复测试. 1.测试环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ------------------------------------------------------------

[20161115]11G pre-allocation.txt

[20161115]11G pre-allocation.txt --11GR2有1个pre-allocation的新特性,通过SMCO进程swap出Wnnn进程,来对空间进行预分配. --在windows下遇到1次ora-00445,当然不一定是这个问题,可能数据库其他问题死机,导致无法建立后台进程. --链接: http://blog.itpub.net/267265/viewspace-2120811/ 在这里有2个隐含参数: 1. _enable_space_preallocation

Oracle 11g 密码过期被锁报 ORA-28000 the account is locked

一.触发这个错误的原因及相关因素    是由于oracle11g中默认在default概要文件中设置了"PASSWORD_LIFE_TIME=180天"所导致,在Oracle 11g中是 存在密码过期问题的. 二.错误现象: 用户被锁定之后会报ORA-28000的错误,并提示无法登录到数据库 SQL> conn system/oracle ERROR: ORA-28000: the account is locked Warning: You are no longer conn

Oracle 11G密码180天过期后的修改方法_oracle

由于Oracle11G的新特性所致,经常会遇到使用sqlplus登陆oracle数据库时提示"ORA-28002: 7 天之后口令将过期"等情况. 在Oracle 11G 创建用户时缺省密码过期限制是180天, 如果超过180天用户密码未做修改则该用户无法登录,提示"ORA-28001: the password has expired" 密码过期后,业务进程连接数据库异常,必然会影响使用与登录. 解放方法: ****************************

Oracle 11g 密码设置为不过期

过期的原因一般有两种可能:一.由于oracle11g中默认在default概要文件中设置了"PASSWORD_LIFE_TIME=180天"所导致.二.由于oracle11g中默认在default概要文件中设置了"FAILED_LOGIN_ATTEMPTS=10次",当输入密码错误次数达到设置值将导致此问题. 如果是第一种情况解决方法如下: 1.查看用户的proifle是哪个,一般是default:     sql>SELECT username,PROFIL

[20151008]8i-10g口令密码的加密算法.txt

[20151008]8i-10g口令密码的加密算法.txt --昨天晚上写了1篇关于11g密码问题,想看看8i-10g口令密码的加密算法,google半天竟然没找到. --翻了一个电子文档找到相关内容做一个记录: Apress.Expert.Oracle.Practices.Jan.2010.pdf 1.  Concatenate the username and password while also making the string Unicode for instance, for SY

oracle 11g 使用 alter user identified by values password 恢复历史密码

在11.1之前的版本,很多人可能都知道,可以通过alter user identified by values password 来还原oracle 数据库历史密码,但是在11g中出现几个问题: 1. dba_users中无password记录(值为空),这个问题可以通过直接查询user$.password依然有记录 SQL> select password from dba_users where username='SYS';   PASSWORD ---------------------