PostgreSQL Password Cracker

Devrim GUNDUZ <devrim@tr.net> writes:

Some guys from Turkey claim that they have a code to crack PostgreSQL
passwords, defined in pg_hba.conf .

http://www.core.gen.tr/pgcrack/

This is not a cracker, this is just a brute-force "try all possible
passwords" search program (and a pretty simplistic one at that).
I'd say all this proves is the importance of choosing a good password.
Using only lowercase letters is a *bad* idea, especially if you're only
going to use five of 'em...

regards, tom lane

Tom Lane wrote:

Devrim GUNDUZ <devrim@tr.net> writes:

Some guys from Turkey claim that they have a code to crack PostgreSQL
passwords, defined in pg_hba.conf .

http://www.core.gen.tr/pgcrack/

This is not a cracker, this is just a brute-force "try all possible
passwords" search program (and a pretty simplistic one at that).
I'd say all this proves is the importance of choosing a good password.
Using only lowercase letters is a *bad* idea, especially if you're only
going to use five of 'em...

Yea, that was my reaction too. Hard to see how we can guard against
this.

If they had used 8 lowercase characters, it would have been 36 days, if
8 upper and lower case, it would be 494 days, 8 upper/lowercase with
numbers, 38284 days.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Hi,

On Sal, 2002-12-31 at 19:38, Tom Lane wrote:

This is not a cracker, this is just a brute-force "try all possible
passwords" search program (and a pretty simplistic one at that).

Ah, you're right.

I'd say all this proves is the importance of choosing a good password.
Using only lowercase letters is a *bad* idea, especially if you're only
going to use five of 'em...

I had no time to search throug the code; but as far as I understood, it
*attacks* the database servers with TCP/IP on, right?

Best regards,
--
Devrim GUNDUZ
www.gunduz.org
devrim@tr.net

Devrim GUNDUZ wrote:

Hi,

On Sal, 2002-12-31 at 19:38, Tom Lane wrote:

This is not a cracker, this is just a brute-force "try all possible
passwords" search program (and a pretty simplistic one at that).

Ah, you're right.

I'd say all this proves is the importance of choosing a good password.
Using only lowercase letters is a *bad* idea, especially if you're only
going to use five of 'em...

I had no time to search throug the code; but as far as I understood, it
*attacks* the database servers with TCP/IP on, right?

It sniffs the packets going over the wire, so it can only be internet
sockets, not unix domain sockets (both use tcp/ip).

They basically sniff the text we send, and try passwords until the
result matches the successful reply the client sent.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Devrim GUNDUZ <devrim@tr.net> writes:

I had no time to search throug the code; but as far as I understood, it
*attacks* the database servers with TCP/IP on, right?

No, the program itself simply takes an MD5 hash value and does a
brute-force search for a password that generates that MD5 string.

The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)

This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.

regards, tom lane

On Tue, 2002-12-31 at 17:49, Bruce Momjian wrote:

Tom Lane wrote:

Devrim GUNDUZ <devrim@tr.net> writes:

Some guys from Turkey claim that they have a code to crack PostgreSQL
passwords, defined in pg_hba.conf .

http://www.core.gen.tr/pgcrack/

This is not a cracker, this is just a brute-force "try all possible
passwords" search program (and a pretty simplistic one at that).
I'd say all this proves is the importance of choosing a good password.
Using only lowercase letters is a *bad* idea, especially if you're only
going to use five of 'em...

Yea, that was my reaction too. Hard to see how we can guard against
this.

Keep a table of usernames used in connection attempts that failed
because of a bad password. After 2 such failures, add 1 second sleep
for each successive failure before responding to the next attempt for
the same username. Max it at say 60 seconds. That should make brute
force cracking unfeasible unless someone gets very lucky or the password
is particularly weak.

Zero the entry for a username as soon as there is a good connection.

Is it worth doing?

--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Ye have heard that it hath been said, Thou shalt love
thy neighbour, and hate thine enemy. But I say unto
you, Love your enemies, bless them that curse you, do
good to them that hate you, and pray for them which
despitefully use you, and persecute you;"
Matthew 5:43,44

Oliver Elphick wrote:

On Tue, 2002-12-31 at 17:49, Bruce Momjian wrote:

Tom Lane wrote:

Devrim GUNDUZ <devrim@tr.net> writes:

Some guys from Turkey claim that they have a code to crack PostgreSQL
passwords, defined in pg_hba.conf .

http://www.core.gen.tr/pgcrack/

This is not a cracker, this is just a brute-force "try all possible
passwords" search program (and a pretty simplistic one at that).
I'd say all this proves is the importance of choosing a good password.
Using only lowercase letters is a *bad* idea, especially if you're only
going to use five of 'em...

Yea, that was my reaction too. Hard to see how we can guard against
this.

Keep a table of usernames used in connection attempts that failed
because of a bad password. After 2 such failures, add 1 second sleep
for each successive failure before responding to the next attempt for
the same username. Max it at say 60 seconds. That should make brute
force cracking unfeasible unless someone gets very lucky or the password
is particularly weak.

The problem is that our MD5 algorithm is open source, so they are doing
the checks in C looking for a match, not by sending the string to the
server.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

Devrim GUNDUZ <devrim@tr.net> writes:

I had no time to search throug the code; but as far as I understood, it
*attacks* the database servers with TCP/IP on, right?

No, the program itself simply takes an MD5 hash value and does a
brute-force search for a password that generates that MD5 string.

The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)

This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.

This is absolutely correct, shouldn't this be in the FAQ?

mlw wrote:

The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)

This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.

This is absolutely correct, shouldn't this be in the FAQ?

Well, this is a pretty rare issue, so it doesn't seem like an FAQ.
People need to understand the ramifications of the various pg_hba.conf
settings, and I think our documentation does that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian wrote:

mlw wrote:

The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)

This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.

This is absolutely correct, shouldn't this be in the FAQ?

Well, this is a pretty rare issue, so it doesn't seem like an FAQ.
People need to understand the ramifications of the various pg_hba.conf
settings, and I think our documentation does that.

A good DBA will probably read the docs, a bad DBA will probably not, and
it is the bad DBA that needs to be guided the most.

Maybe not FAQ, but is the a short page of "dos and don'ts?

What do others think? I am not sure myself.

---------------------------------------------------------------------------

mlw wrote:

Bruce Momjian wrote:

mlw wrote:

The comments at the top suggest sniffing a Postgres session startup
exchange in order to see the MD5 value that the user presents; which the
attacker would then give to this program. (Forget it if the session is
Unix-local rather than TCP, or if it's SSL-encrypted...)

This is certainly a theoretically possible attack against someone who
has no clue about security, but I don't put any stock in it as a
practical attack. For starters, if you are talking to your database
across a network that is open to hostile sniffers, you should definitely
be using SSL.

This is absolutely correct, shouldn't this be in the FAQ?

Well, this is a pretty rare issue, so it doesn't seem like an FAQ.
People need to understand the ramifications of the various pg_hba.conf
settings, and I think our documentation does that.

A good DBA will probably read the docs, a bad DBA will probably not, and
it is the bad DBA that needs to be guided the most.

Maybe not FAQ, but is the a short page of "dos and don'ts?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What do others think? I am not sure myself.

There should definitely be someplace that recommends using SSL across
insecure networks (if there's not already). But it doesn't seem to me
to qualify as a FAQ entry. Somewhere in the admin guide seems more
appropriate. Perhaps under Client Authentication?

Maybe someone could even put together enough material to create a whole
chapter on security considerations --- this is hardly the only item
worthy of mention.

regards, tom lane

Yes, I have been feeling we should do that. Justin pointed out just
yesterday that .pgpass is only mentioned in libpq documentation, and in
fact there is lots of stuff mentioned in libpq that releates to the
other interfaces, so it should be pulled out and put in one place.

Does anyone want to tackle this?

---------------------------------------------------------------------------

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

What do others think? I am not sure myself.

There should definitely be someplace that recommends using SSL across
insecure networks (if there's not already). But it doesn't seem to me
to qualify as a FAQ entry. Somewhere in the admin guide seems more
appropriate. Perhaps under Client Authentication?

Maybe someone could even put together enough material to create a whole
chapter on security considerations --- this is hardly the only item
worthy of mention.

regards, tom lane

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

I'll do that. Justin: What's the URL for the .pgpass stuff? So far I see
mention of using SSL. That's two items to cover. Anything else?

On Wed, 1 Jan 2003, Bruce Momjian wrote:

Dan Langille wrote:

I'll do that. Justin: What's the URL for the .pgpass stuff? So far I see
mention of using SSL. That's two items to cover. Anything else?

Hi Dan,

Very Cool. The URL for the .pgpass stuff is:

http://developer.postgresql.org/docs/postgres/libpq-files.html

:-)

Regards and best wishes,

Justin Clift

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

On Fri, 3 Jan 2003, Justin Clift wrote:

Very Cool. The URL for the .pgpass stuff is:

http://developer.postgresql.org/docs/postgres/libpq-files.html

There is a typo on that page. First it talkes about the file .pgpass and
then it says: "chmod 0600 .pgaccess".

I had no idea that one could store the passwords like this. This feature
is something I'm going to use from now on (now that I know about it).

--
/Dennis

Bruce Momjian writes:

Yes, I have been feeling we should do that. Justin pointed out just
yesterday that .pgpass is only mentioned in libpq documentation, and in
fact there is lots of stuff mentioned in libpq that releates to the
other interfaces, so it should be pulled out and put in one place.

It is difficult to make out which place that would be. You can duplicate
the information in every place where an interface or tool that uses libpq
is documented, but that doesn't seem to be conceptually superior.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Yes, I have been feeling we should do that. Justin pointed out just
yesterday that .pgpass is only mentioned in libpq documentation, and in
fact there is lots of stuff mentioned in libpq that releates to the
other interfaces, so it should be pulled out and put in one place.

It is difficult to make out which place that would be. You can duplicate
the information in every place where an interface or tool that uses libpq
is documented, but that doesn't seem to be conceptually superior.

Duplicating this info is clearly a losing proposition. But I think
Bruce is envisioning restructuring the documentation of libpq to
separate out the parts that are only interesting to a programmer using
libpq from the parts that are interesting to a user of a libpq-based
program (for example, all the info about environment variables, conninfo
string syntax, and .pgpass). Then the docs for interfaces and tools
could cross-reference the "externally visible behavior" section of the
libpq docs --- and this section would make sense to an end user,
without drowning him in details he doesn't care about.

regards, tom lane

Dennis Bj���rklund wrote:

On Fri, 3 Jan 2003, Justin Clift wrote:

Very Cool. The URL for the .pgpass stuff is:

http://developer.postgresql.org/docs/postgres/libpq-files.html

There is a typo on that page. First it talkes about the file .pgpass and
then it says: "chmod 0600 .pgaccess".

I had no idea that one could store the passwords like this. This feature
is something I'm going to use from now on (now that I know about it).

I looked at CVS and the fix is in CVS head, but not in 7.3.X.

I applied it only to CVS head because I wasn't sure if were were
backpatching docs into CVS. I was later told we were rebuilding 7.3.X
docs every night so we should backpatch docs.

Also, does anyone know why the development docs are 7.3.1?

http://developer.postgresql.org/docs/postgres/index.html

Seems if it is on the developers page, it should be CVS head? Wasn't
that supposed to build on demand? I don't think that is working.
Perhaps it took too much CPU.

The docs on my machine are based on CVS head and do build on demand:

http://candle.pha.pa.us/main/writings/pgsql/sgml

Both links are on the developers page.

Is someone working to get 7.3.1 announced on our main web site?

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

Bruce Momjian writes:

Yes, I have been feeling we should do that. Justin pointed out just
yesterday that .pgpass is only mentioned in libpq documentation, and in
fact there is lots of stuff mentioned in libpq that releates to the
other interfaces, so it should be pulled out and put in one place.

It is difficult to make out which place that would be. You can duplicate
the information in every place where an interface or tool that uses libpq
is documented, but that doesn't seem to be conceptually superior.

Duplicating this info is clearly a losing proposition. But I think
Bruce is envisioning restructuring the documentation of libpq to
separate out the parts that are only interesting to a programmer using
libpq from the parts that are interesting to a user of a libpq-based
program (for example, all the info about environment variables, conninfo
string syntax, and .pgpass). Then the docs for interfaces and tools
could cross-reference the "externally visible behavior" section of the
libpq docs --- and this section would make sense to an end user,
without drowning him in details he doesn't care about.

Right. I think as a minimum, we need to move the libpq environment
variables and, as Justin said, the .pgpass stuff out into its own
section, and reference that from libpq and other
interfaces/applications. We have had several reports of folks not
knowing it, and it is obvious is it because the info is inside a C
library API chapter.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Also, does anyone know why the development docs are 7.3.1?

Because it was pointed to that branch during the 7.3 beta cycle.
It needs to be repointed to CVS tip. I dunno how to do so, however.

Is someone working to get 7.3.1 announced on our main web site?

I would like to think that someone in either the -advocacy or webmaster
groups will get around to that sometime soon ;-)

regards, tom lane

On Thu, 2003-01-02 at 19:33, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Also, does anyone know why the development docs are 7.3.1?

Because it was pointed to that branch during the 7.3 beta cycle.
It needs to be repointed to CVS tip. I dunno how to do so, however.

Is someone working to get 7.3.1 announced on our main web site?

I would like to think that someone in either the -advocacy or webmaster
groups will get around to that sometime soon ;-)

I don't want to speak for anyone else, but honestly I don't think anyone
is working on it (I mean how long could it take to do it and how long
has 7.3.1 been released?). I'd be happy to do it if someone would
explain to me how to do it. I have a lot of access to a bunch of stuff
but I don't think I have access to the cvs that the main site is stored
in. Anonymous access and an email of who to send patches to would be
enough if people are worried about me trashing things :-)

Robert Treat

-----Original Message-----
From: Robert Treat [mailto:xzilla@users.sourceforge.net]
Sent: 03 January 2003 15:36
To: Tom Lane
Cc: Bruce Momjian; Justin Clift;
pgsql-hackers@postgresql.org; Dave Page
Subject: Re: [HACKERS] PostgreSQL Password Cracker

On Thu, 2003-01-02 at 19:33, Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Also, does anyone know why the development docs are 7.3.1?

Because it was pointed to that branch during the 7.3 beta cycle. It
needs to be repointed to CVS tip. I dunno how to do so, however.

Is someone working to get 7.3.1 announced on our main web site?

I would like to think that someone in either the -advocacy or
webmaster groups will get around to that sometime soon ;-)

I don't want to speak for anyone else, but honestly I don't
think anyone is working on it (I mean how long could it take
to do it and how long has 7.3.1 been released?). I'd be happy
to do it if someone would explain to me how to do it. I have
a lot of access to a bunch of stuff but I don't think I have
access to the cvs that the main site is stored in. Anonymous
access and an email of who to send patches to would be enough
if people are worried about me trashing things :-)

www.postgresql.com - with a little luck should become www.postgresql.org
rsn.

Regards, Dave.

Tom Lane writes:

separate out the parts that are only interesting to a programmer using
libpq from the parts that are interesting to a user of a libpq-based
program (for example, all the info about environment variables, conninfo
string syntax, and .pgpass).

The sections on environment variables and the .pgpass file are at the
"sect1" level, which is about as prominent as I think we can make them.
Certainly they are not a subject matter that warrants a whole chapter of
their own. What's missing are some cross-references.

--
Peter Eisentraut peter_e@gmx.net

Peter Eisentraut wrote:

Tom Lane writes:

separate out the parts that are only interesting to a programmer using
libpq from the parts that are interesting to a user of a libpq-based
program (for example, all the info about environment variables, conninfo
string syntax, and .pgpass).

The sections on environment variables and the .pgpass file are at the
"sect1" level, which is about as prominent as I think we can make them.
Certainly they are not a subject matter that warrants a whole chapter of
their own. What's missing are some cross-references.

But it is a "sect1" in libpq. It should be a "sect1" somewhere that
makes more sense.

Right now it appears here:

Table of Contents
1. libpq - C Library

1.1. Introduction
1.2. Database Connection Functions
1.3. Command Execution Functions
1.4. Asynchronous Query Processing
1.5. The Fast-Path Interface
1.6. Asynchronous Notification
1.7. Functions Associated with the COPY Command
1.8. libpq Tracing Functions
1.9. libpq Control Functions
1.10. Environment Variables

^^^^^^^^^^^^^^^^^^^^^
1.11. Files
1.12. Threading Behavior
1.13. Building Libpq Programs
1.14. Example Programs

It doesn't belong in libpq, and it doesn't belong in the Programmer's
Guide.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

But it is a "sect1" in libpq. It should be a "sect1" somewhere that
makes more sense.
...
It doesn't belong in libpq, and it doesn't belong in the Programmer's
Guide.

How could it not belong in libpq? But you are right that the
Programmer's Guide seems the wrong place for information that is
important to end-users.

Perhaps libpq needs to have a chapter in the User's Guide as well as a
chapter in the Programmer's Guide? Or maybe we could put the relevant
information into a reference page under PostgreSQL Client Applications
(titled something along the line of "common behavior of all libpq-based
client applications").

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

But it is a "sect1" in libpq. It should be a "sect1" somewhere that
makes more sense.
...
It doesn't belong in libpq, and it doesn't belong in the Programmer's
Guide.

How could it not belong in libpq? But you are right that the
Programmer's Guide seems the wrong place for information that
is important to end-users.

Some people don't even know libpq exists. If someone uses only
psql, how would they know?

Perhaps libpq needs to have a chapter in the User's Guide as
well as a chapter in the Programmer's Guide?

Or maybe we could put the relevant information into a reference
page under PostgreSQL Client Applications (titled something
along the line of "common behavior of all libpq-based client
applications").

Yep, that's what I would do.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073