Re: [HACKERS] PostgreSQL Password Cracker
On Thu, 2003-01-02 at 19:33, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL Password Cracker
-Original Message- From: Robert Treat [mailto:[EMAIL PROTECTED]] Sent: 03 January 2003 15:36 To: Tom Lane Cc: Bruce Momjian; Justin Clift; [EMAIL PROTECTED]; Dave Page Subject: Re: [HACKERS] PostgreSQL Password Cracker On Thu, 2003-01-02 at 19:33, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL Password Cracker
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL Password Cracker
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL Password Cracker
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: 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL Password Cracker
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL Password Cracker
Peter Eisentraut [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL Password Cracker
Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] 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?
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL Password Cracker
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?
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] PostgreSQL Password Cracker
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL Password Cracker
Devrim GUNDUZ [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL Password Cracker
Devrim GUNDUZ [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PostgreSQL Password Cracker
Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL Password Cracker
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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL Password Cracker
On Tue, 2002-12-31 at 17:49, Bruce Momjian wrote: Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] 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[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] PostgreSQL Password Cracker
Oliver Elphick wrote: On Tue, 2002-12-31 at 17:49, Bruce Momjian wrote: Tom Lane wrote: Devrim GUNDUZ [EMAIL PROTECTED] 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 [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
