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
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
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
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
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
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
[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
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
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.
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
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
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
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?
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
14 matches
Mail list logo
