Re: [HACKERS] Re: Encrypting pg_shadow passwords
On Tue, Jul 10, 2001 at 11:32:00PM -0400, Bruce Momjian wrote: On Tue, Jun 26, 2001 at 11:02:15AM -0400, Bruce Momjian wrote: This is the first time I am hearing people are more concerned about pg_shadow security than the wire security. I can see cases where people are on secure networks or are using only local users where having pg_shadow encrypted is more important than crypt authentication. Fortunately the new system will solve both problems. The crypt authentication currently used offers _no_ security. If I can sniff on the wire, I can hijack the tcp stream, and trick the client into doing password authentication. It is my understanding that sniffing is much easier than hijacking. If hijacking is a concern, you have to use SSL. That is not true. The internet happily allows for active attacks. In fact, active attacks are easier on the internet than passive ones. My concern is, that by having something that we proclaim to be secure, we need for it to really be secure. An HMAC would be a better alternative to the current crypt scheme, as it would provide integrity, without the overhead of having privacy. Of course, HMAC would require the postgres protocol to talk in packets, as it can't accept the data as being valid until it verifies the MAC. I'm not familiar with the protocol yet. I suggest these authentication options: * password - The current meaning of password, but with passwords hashed using md5crypt() or something. (The usual crypt unneccessarily limits passwords to 8 characters) * HMAC - Wrap all postgres data in an HMAC (I believe this requires an plaintext-like password on the server as does crypt and the double crypt scheme) * Public Key (RSA/DSA) - Use public key cryptography to negotiate a connection. (When I'm not busy, I may decide to do this myself) Also, I think we should add to the client API the ability to only accept certain authentication schemes, to avoid active attacks tricking your software from sending the HMAC password in cleartext. -- Michael Samuel [EMAIL PROTECTED] ---(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] Re: Encrypting pg_shadow passwords
Also, I think we should add to the client API the ability to only accept certain authentication schemes, to avoid active attacks tricking your software from sending the HMAC password in cleartext. This is an interesting point. We have kept 'password' authentication around for secondary password files and for very old clients, but now see that having it around can be a security problem because you can ask the client to send you cleartext passwords. Comments? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Encrypting pg_shadow passwords
That is not true. The internet happily allows for active attacks. In fact, active attacks are easier on the internet than passive ones. My concern is, that by having something that we proclaim to be secure, we need for it to really be secure. An HMAC would be a better alternative to the current crypt scheme, as it would provide integrity, without the overhead of having privacy. Of course, HMAC would require the postgres protocol to talk in packets, as it can't accept the data as being valid until it verifies the MAC. I'm not familiar with the protocol yet. I suggest these authentication options: * password - The current meaning of password, but with passwords hashed using md5crypt() or something. (The usual crypt unneccessarily limits passwords to 8 characters) Once I do crypting of pg_shadow/double-crypt for 7.2, we don't need password anymore. It is around only for very old clients and for secondary password files but wWe will not need that workaround with double-crypt. * HMAC - Wrap all postgres data in an HMAC (I believe this requires an plaintext-like password on the server as does crypt and the double crypt scheme) No, double-crypt has the passwords stored encrypted. * Public Key (RSA/DSA) - Use public key cryptography to negotiate a connection. (When I'm not busy, I may decide to do this myself) SSL? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Encrypting pg_shadow passwords
On Tue, Jun 26, 2001 at 11:02:15AM -0400, Bruce Momjian wrote: This is the first time I am hearing people are more concerned about pg_shadow security than the wire security. I can see cases where people are on secure networks or are using only local users where having pg_shadow encrypted is more important than crypt authentication. Fortunately the new system will solve both problems. The crypt authentication currently used offers _no_ security. If I can sniff on the wire, I can hijack the tcp stream, and trick the client into doing password authentication. Also, the double crypt authentication offers no advantage over the wire. You're better off just doing an md5crypt() on the server side, and just passing the password in the clear. At least you're not confusing users into thinking that they're secure. Of course, SSL *if done correctly with certificate verification* is the correct fix. If no certificate verification is done, you fall victim to a man-in-the-middle attack. -- Michael Samuel [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Encrypting pg_shadow passwords
On Tue, Jun 26, 2001 at 11:02:15AM -0400, Bruce Momjian wrote: This is the first time I am hearing people are more concerned about pg_shadow security than the wire security. I can see cases where people are on secure networks or are using only local users where having pg_shadow encrypted is more important than crypt authentication. Fortunately the new system will solve both problems. The crypt authentication currently used offers _no_ security. If I can sniff on the wire, I can hijack the tcp stream, and trick the client into doing password authentication. It is my understanding that sniffing is much easier than hijacking. If hijacking is a concern, you have to use SSL. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
AW: [HACKERS] Re: Encrypting pg_shadow passwords
On Tue, Jun 26, 2001 at 10:18:37AM -0400, Tom Lane wrote: though I would note that anyone who is able to examine the contents of pg_shadow has *already* broken into your database note: the dbadmin may not be the system administrator, but the dbadmin, by default (with plaintext) can scoop an entire list of useful passwords, since many users (like it or not) use the same/similar passwords for multiple accounts. I fully agree with this statement and think it is a valid concern. Would it help here to introduce some poor man's encryption that is reversible ? Then the admin would need to intentionally decrypt the pg_shadow entry to see that plain password, and not see it if he just accidentally select'ed * from pg_shadow. If an admin intentionally wants to crack a password he will always have means to do that (e.g. send well chosen salts). Andreas ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Encrypting pg_shadow passwords
[EMAIL PROTECTED] (Frank Ch. Eigler) writes: tgl wrote: : What this discussion seems to come down to is whether we should take a : backward step in one area of security (security against wire-sniffing) : to take a forward step in another (not storing plaintext passwords). It seems to me that the two issues are orthogonal. In the abstract yes, but not when you have a constraint that you can't change the protocol or the client-side code. Remember we are talking about a backwards-compatibility mode. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: Encrypting pg_shadow passwords
Frank Ch. Eigler [EMAIL PROTECTED] writes: Having scanned over the discussion again, my understanding is that Jim's proposed changes don't affect backwards compatibility. As long as user passwords continue to be passed in plaintext to the server, the server can store encrypted passwords in the authentication table. The 'passwd' mode wouldn't be affected, but the 'crypt' mode would be; it would become less secure than it is now, because the server would be forced to send the same salt always, and so a captured encrypted password would be just as useful as a captured plaintext one. That's the step backwards. 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] Re: Encrypting pg_shadow passwords
Frank Ch. Eigler [EMAIL PROTECTED] writes: Oh, I see finally. You already put a custom little challenge/response authentication scheme into postgresql, and want to keep that working. (May I ask when/why that went in at all? Long before any of the current generation of developers, AFAIK. Was lower-layer encryption not an option?) What lower layer? This code predates SSL by a good bit. In any case, as several people have pointed out, one may well want to guard one's password more carefully than one guards the entire session contents. Running SSL on a session that may transfer many megabytes is a lot of overhead. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Re: Encrypting pg_shadow passwords
Jim and Bruce wrote: [ a lot of stuff ] What this discussion seems to come down to is whether we should take a backward step in one area of security (security against wire-sniffing) to take a forward step in another (not storing plaintext passwords). It seems largely a matter of local conditions which hazard you consider greater (though I would note that anyone who is able to examine the contents of pg_shadow has *already* broken into your database). Anyway, I doubt anyone will convince anyone else to change sides on that point. My take on the matter is that we shouldn't invest any more effort in crypt-based solutions (here crypt means specifically crypt(3), it's not a generic term). The future is double encryption using MD5 --- or s/MD5/more-modern-hash-algorithm-of-your-choice/, the exact choice is irrelevant to my point. We ought to get off our duffs and implement that, then encourage people to migrate their clients ASAP. The crypt code will be supported for awhile longer, but strictly as a backwards-compatibility measure for old clients. There's no reason to spend any additional work on it. For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? 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] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. In the long run, though, we want to drop crypt(3) usage entirely. It's just too much of a pain in the neck to depend on the C library's crypt(), for two reasons: 1. It's not in libc on all systems, leading to constant problems when linking clients, particularly with shared libraries that have to have a dependency on another shared library because of this. (Search the archives for problems about can't find crypt. There are many such reports.) 2. crypt() isn't guaranteed compatible across platforms, meaning that your clients may be unable to log in anyway. See for example http://fts.postgresql.org/db/mw/msg.html?mid=57516 Using our own MD5 (or whatever) code will avoid these problems. 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] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. Haven't many systems (at least Linux and FreeBSD) switched from this to other algorithms as default, like MD5? (and usually found in /etc/shadow) Yes, most BSD's are MD5. I wasn't sure about Linux. Most recent (3-4 years and newer) use PAM, which can use MD5 as an underlying module. -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. Haven't many systems (at least Linux and FreeBSD) switched from this to other algorithms as default, like MD5? (and usually found in /etc/shadow) Yes, most BSD's are MD5. I wasn't sure about Linux. Most recent (3-4 years and newer) use PAM, which can use MD5 as an underlying module. But what is the default? crypt or md5? Varies. In Red Hat Linux, it's been user configurable during install for a couple of years now - it's been default to on for most of that time, AFAIR. -- Trond Eivind Glomsrød Red Hat, Inc. ---(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] Re: Encrypting pg_shadow passwords
Bruce Momjian [EMAIL PROTECTED] writes: My take on the matter is that we shouldn't invest any more effort in crypt-based solutions (here crypt means specifically crypt(3), it's not a generic term). The future is double encryption using MD5 --- or s/MD5/more-modern-hash-algorithm-of-your-choice/, the exact choice is irrelevant to my point. We ought to get off our duffs and implement that, then encourage people to migrate their clients ASAP. The crypt code will be supported for awhile longer, but strictly as a backwards-compatibility measure for old clients. There's no reason to spend any additional work on it. For the same reason I don't see any value in the idea of adding crypt-based double encryption to clients. We don't really want to support that over the long run, so why put effort into it? The only reason to add double-crypt is so we can continue to use /etc/passwd entries on systems that use crypt() in /etc/passwd. Haven't many systems (at least Linux and FreeBSD) switched from this to other algorithms as default, like MD5? (and usually found in /etc/shadow) -- Trond Eivind Glomsrød Red Hat, Inc. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
