密码过期导致的用户锁定问题

第一章  数据安全:巧妙解决由密码过期导致的用户锁定问题

 数据库安全问题一直是人们关注的焦点。oracle数据库使用了多种手段来保证数据库的安全,如密码,角色,权限等等。今天我们来讨论一下关于oracle的密码问题。然而,我在这里要讲的并不是oracle的安全密码机制有多么的强大,恰恰相反,我教大家的是,在oracle密码过期时我们如何在不修改密码的情况下,使密码重新有效。

1案例引入

在介绍前我们先来说一个案例,某客户数据库做安全加固时,针对profile修改了部分password的安全机制。其中最重要的一点就是设置了PASSWORD_LIFE_TIME(该参数设定密码过期时间)这一个参数。而当该参数设置完后,客户又没有根据设定的安全机制实施一个良好的人工密码周期性管理策略。PASSWORD_LIFE_TIME 参数所设定的时间到期后,数据库将该用户locked,导致业务无法正常连接。从理论上来说,既然密码过期了,那么重置密码是唯一的手段,但是重置密码意味着要修改大量的中间件。这对业务逻辑不熟悉的人来说,还是存在必然的风险的。检查后发现客户并没有设置PASSWORD_REUSE_TIME(该参数设定为相同密码的重用时间),既然该参数并没有设置,那么我们可以考虑通过一个临时密码来作为中间密码,通过中间密码进一步重新设置原密码。但是这时候又一个问题出现了,客户并不知道该业务的用户密码。再次加大了解决问题的难度。下面我为大家介绍一个较为巧妙的方法来重置oracle的密码。

2概念普及

在详细说明本节内容的情况下,需要普及一些小的知识点。对于密码有效期等问题的管理上,oracle是通过profile文件来进行管理的,其中默认一个default的profile文件。在oracle 9i以及以前版本,oracle对于默认的default profile文件参数值均为UNLIMITED,在10g版本中,将FAILED_LOGIN_ATTEMPTS的值默认设置为10次,也就是说在连续10次输入错误密码后,oracle将锁定该用户,直到用户被解锁为止。从11g开始,oracle对密码文件的管理策略增加了很多,很多之前被设置了UNLIMITED的参数,在11g中都定义了相应的值,虽然这一新特性增加了oracle密码的安全机制,但是也从一定程度上对我们管理产生了影响。首先我们来说明一下oracle的profile 中关于密码这一部分的内容。(该默认的profile取自oracle11g环境)

wpsE665.tmp

详细解释一下以上参数值:

PASSWORD_LIFE_TIME 180--口令的生命周期,超过这段时间口令可能会自动过期,是否过期要看是否设定了PASSWORD_GRACE_TIME

PASSWORD_GRACE_TIME 7--接着PASSWORD_LIFE_TIME特性,如果PASSWORD_LIFE_TIME的期限已到,那么PASSWORD_GRACE_TIME 的设置是对口令生命周期的一个grace(宽限或者延续),口令到期之后,继续可以使用的天数,在这段时间内如果我们登录系统,会有提示,提示系统在几天内过期。

PASSWORD_REUSE_TIME UNLIMITED --这个特性限制口令在多少天内不能重复使用,默认值为UNLIMITED

PASSWORD_REUSE_MAX UNLIMITED--这个特性是针对PASSWORD_REUSE_TIME的,说明要想在PASSWORD_REUSE_TIME这个参数指定的时间内重复使用当前口令,那么至少需要修改过口令的次数(修改过的口令当然肯定需要和当前口令不同,因为毕竟还有PASSWORD_REUSE_TIME 特性的限制)。

FAILED_LOGIN_ATTEMPTS 10--这个比较好理解,不知道口令的话尝试登录的次数,达到这个次数之后账户被自动锁定。

PASSWORD_LOCK_TIME 1 --接着FAILED_LOGIN_ATTEMPTS参数,口令被自动锁定的时间,达到这个时间之后,下次登录时系统自动解除对这个账户的锁定。

以上即为oracle对于profile中密码管理的一些参数解释。

接下来我们来说明一下oracle中关于用户锁定的状态

wpsE676.tmp

ORACLE数据库用户有多种状态,可查看视图USER_ASTATUS_MAP。

wpsE677.tmp

可以看到oracle一共提供了9种状态,而九种状态可分为两类:1.基本状态。2.组合状态。

前五种是基本状态:0 OPEN、1 EXPIRED、2 EXPIRED(GRACE)、4 LOCKED(TIMED)、8 LOCKED。

后四种是基本状态:5 EXPIRED & LOCKED(TIMED)、6 EXPIRED(GRACE) & LOCKED(TIMED)、9 EXPIRED & LOCKED、10 EXPIRED(GRACE) & LOCKED。

后四种的组合状态可通过状态号STATUS#获得其状态的两个组合,对于我们常态管理来说我们只需要掌握前面5种即可,以上客户所发生的问题就是由于对于profile的设置导致的密码失效的问题。

3巧解密码过期问题

在上述的客户案例中,安全加固措施固然是好的,但是没有客观考虑到后期密码维护的问题,而在oracle11G中PASSWORD_LIFE_TIME参数一定程度上也会造成上述客户的问题,DBA如果不清楚这一特性很容易造成密码锁定,这样一来很难解决。

在10g或者11g环境中,如果profiles的密码参数被设置后,会导致密码在规定的时间内过期,锁定等。此时如果我们继续去连接,状态变成EXPIRED或者EXPIRED(GRACE),那么当我们连接后,会提示需要重新设定新的密码,并且该会话无法连入数据库,此时如果我们知道该用户的密码,那么DBA只需要手工干预一下,重新设定该密码即可。

在10G环境中,我们仔细查看dba_users这张视图,对应的PASSWORD这个字段,其实该字段即为我们设置的密码的HASH值,当我们的密码过期或者用户被锁定后,可以通过该字段来巧妙的规避一下该特性。

查看用户信息(10G版本)

wpsE678.tmp

我们可以看到,以上的密码经过加密处理后显示为一串无序的HASH值。而在11G开始,oracle为了凸显密码安全性,将dba_users中的password这一列不再做显示。

查看用户信息(11G版本)

wpsE688.tmp

可以看到,从11G开始,oracle将password这一列给隐藏了。

注:Oracle11g在用户安全性方面的加强,不仅仅是密码的隐藏,还包括:

wpsE689.tmp

当我们的用户密码过期并且被锁定后,再次登录将会产生报错-用户被锁定。

如下图:

wpsE68A.tmp

注意LOCKED和EXPIRED & LOCKED是两个不同的概念。LOCKED状态是由于连续的输错密码达到FAILED_LOGIN_ATTEMPTS指定的次数造成的。对于该种故障,我们只需要简单的给用户解锁即可,如下:

wpsE69B.tmp

但是EXPIRED & LOCKED是由于PASSWORD_LIFE_TIME参数导致用户密码过期而造成的锁定,单一的解锁命令无法解决该问题。此处还涉及到PASSWORD_LIFE_TIME参数造成的密码修改问题。如下:

wpsE69C.tmp

wpsE6AC.tmp

我们从上面的实验过程看到,虽然我们将用户解锁,但是用户的状态仅仅从EXPIRED & LOCKED转为EXPIRED,并没有正常的OPEN,重新连接用户提示输入新密码。

此处就产生一个问题,可以想象一下,当提示我们输入新密码时,我们势必需要输入生产用户的原密码,否则将造成业务中间件的密码与修改的密码不一致的情况。如果此时我们不知道原密码,势必会造成一定的麻烦。此时我们就需要dba_users视图中的password字段。Password字段虽然已经经过oracle的hash运算并加密(oracle密码采用用户名+密码的组合进行HASH加密),但是我们并不是需要知道该密码是什么,只是需要利用该字段HASH值来成功的解锁用户。

对于一个用户赋新的密码,相信大家都很了解:

alter user username identified by password

那么我们就可以利用password的hash值进行巧妙的解锁,如下:

wpsE6AD.tmp

可以看到,虽然我们不知道该用户的密码,但是我们可以通过password的HASH值来重置该密码。而在11G中,oracle为了提高安全性能,将DBA_USERS.password中的值不做显示,默认为空。如下:

wpsE6AE.tmp

在11G环境中,我们可以通过USER$基表中查询得到该值,如下:

wpsE6BF.tmp

运用同样的命令和方法,我们就可以解决由于密码过期而导致的用户锁定问题。

4技术结论

通过以上的方法,我们可以在不知晓用户名密码的情况下,比较巧妙的解决由于密码过期而导致的用户锁定的情况。虽然我们在上述方法中通过HASH值解锁了用户,但是无论从安全方面还是是从数据库的持续稳定运行方面考虑,我们都建议用户采用安全合理的密码管理机制,从源头上杜绝可能的隐患。

About Me

....................................................................................................................................................

本文来自于微信公众号转载文章,若有侵权,请联系小麦苗及时删除

ITPUB BLOG:http://blog.itpub.net/26736162

QQ:642808185 若加QQ请注明您所正在读的文章标题

【版权所有,文章允许转载,但须以链接方式注明源地址,否则追究法律责任】

....................................................................................................................................................

posted @ 2016-04-13 19:04  DB宝  阅读(6793)  评论(0编辑  收藏  举报