Re: Pete Finnigan's Oracle database password checker

  • From: "Andre van Winssen" <dreveewee@xxxxxxxxx>
  • To: yong321@xxxxxxxxx
  • 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 .

Regards,
Andre

2008/10/11 Yong Huang <yong321@xxxxxxxxx>

> > the slow part of the plsql code is the Brute Force attack. That can
> hardly
> > 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
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>

Other related posts: