Re: Pete Finnigan's Oracle database password checker
Date: Sat, 11 Oct 2008 16:42:33 +0200
Hi Yong Huang,
I didn't say that to blame Pete's code. Not at all. I think it is marvellous that he translated the oracle password hashing algorithm into plsql. Because that brings so much flexibility in how you run the code, or schedule it as database background job.
But it makes sense to limit the BF part if you want to have results quickly. If you do that then you could run it even as a database function with relatively good performance, eg something like SELECT USERNAME,CRACKER20(USERNAME,PASSWORD) FROM DBA_USERS and get the usernames and their clear text passwords back quickly. If too complex then the function should simply return NULL.
I found out that even by using dictionary and pw=un checks you can retrieve lots of passwords. The reason is because those users/dba's/application code creating database accounts either are not enforced to use complex passwords (verify_function) or don't see the danger of making it too easy for malicious users to use their db accounts. Almost all database vulnerabilities start with having a login into the database.
This cracker basically is a plee to use and enforce complex oracle database passwords. And if password verification function cannot be used for some (political) reason then DBA's now have the tool to check for password strength .
2008/10/11 Yong Huang <yong321_at_yahoo.com>
> > the slow part of the plsql code is the Brute Force attack. That can
> > compete with real password crackers written in C(++). You can reduce the
> > pain of doing a brute force attack by changing the line with
> > *passlen:=4*; -- need to restrict to 4 so that it takes around 35 secs
> > into
> > *passlen:=2*; -- need to restrict to 2 so that it takes around 1 sec
> > you can extend the dictionary list with your own words as pointed out by
> > others.
> In the real world, users' passwords rarely are <=4 chars long. And even
> with crackers written in C or C++, brute force check takes more than a few
> weeks on a typical PC nowadays, if the password is longer than 8 characters.
> The problem with all password crackers out there is that none accept
> user-defined regular expressions as patterns of possible passwords (most
> allow you to specify a predefined set of chars, letters only, letters and
> digits, etc). For instance, I know my users will only start a password with
> a letter, not digit or non-alphanumeric char, and the only non-alphanumeric
> chars are such and such (no `, ~, ^, etc.). I can't do that. If I could, the
> runtime of the brute force password check would be much shorter.
> It's not hard to implement this logic in the program. Pete and a few others
> are aware of this shortcoming.
> Yong Huang