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