Rejecting weak passwords
in [PgSql]
|
From: "Kevin Grittner" on 14 Oct 2009 16:50 Dave Page <dpage(a)pgadmin.org> wrote: > I said up front this was a box-ticking exercise for these folks, Can they check the box if the provided clients include password strength checking? I'm just wondering if we're going at this the hard way, if that really is the main goal. From the point of view of usefulness, wouldn't it be OK if clients enforced the strength (or at least warned of weakness) *and* sent the md5sum? And, perhaps slightly off topic: if the login password is sent over a non-encrypted stream, md5sum or not, can't someone use it to log in if they're generating their own stream to connect? Discussions of which is the more secure way to change passwords seems a little silly if you're only worried about environments where someone can sniff any login sequence and spoof the user anyway. > (meh - who cares if we can store 2009-02-31 - it stores all the > valid dates which are the ones that matter :-p ) Oh, now that's just trolling -- you really don't want to open that can of worms again, do you? :-p -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 14 Oct 2009 17:17 "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: > And, perhaps slightly off topic: if the login password is sent over a > non-encrypted stream, md5sum or not, can't someone use it to log in if > they're generating their own stream to connect? Not if they only capture a login exchange --- the password is doubly encrypted during that. If they see the md5'd password in a CREATE USER command, then yeah, they could pass a subsequent md5 challenge, using suitably modified client software that doesn't try to re-encrypt the given password. But the main point is to hide the cleartext password, in any case. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Dave Page on 14 Oct 2009 17:33 On Wed, Oct 14, 2009 at 9:50 PM, Kevin Grittner <Kevin.Grittner(a)wicourts.gov> wrote: > Dave Page <dpage(a)pgadmin.org> wrote: > >> I said up front this was a box-ticking exercise for these folks, > > Can they check the box if the provided clients include password > strength checking? I'm just wondering if we're going at this the hard > way, if that really is the main goal. No. Any checks at the client are worthless, as they can be bypassed by 10 minutes worth of simple coding in any of a dozen or more languages. > And, perhaps slightly off topic: if the login password is sent over a > non-encrypted stream, md5sum or not, can't someone use it to log in if > they're generating their own stream to connect? Discussions of which > is the more secure way to change passwords seems a little silly if > you're only worried about environments where someone can sniff any > login sequence and spoof the user anyway. No - see Tom's reply. >> (meh - who cares if we can store 2009-02-31 - it stores all the >> valid dates which are the ones that matter :-p ) > > Oh, now that's just trolling -- you really don't want to open that can > of worms again, do you? :-p Well, after 12+ years in these parts I figure anyone should get the privilege of a small dig once in a while :-) -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 14 Oct 2009 17:45 Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner(a)wicourts.gov> writes: >> if the login password is sent over a non-encrypted stream, md5sum >> or not, can't someone use it to log in if they're generating their >> own stream to connect? > If they see the md5'd password in a CREATE USER command, then yeah So anyone in a truly security-conscious environment should only change the password through a trusted connection, whether or not it is md5'd? (Trusted here meaning that the connection has suitable encryption or it is local to the server, which is suitably secured.) > But the main point is to hide the cleartext password, in any case. Sure, sorry to drift off-topic, but the thought kept nagging at me. :-) Anyway, I think it helped crystallize something for me -- the client-side md5 mangling protects against malicious DBAs or database server admins, while the trusted connection protects against network snooping. The former is more about keeping the bad guys, who would have other ways of compromising the database, from gleaning information about your password choices that they may be able to apply to other resources. The latter protects the database itself. Did I miss any other forms of attack either addresses? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Kevin Grittner" on 14 Oct 2009 17:51
Dave Page <dpage(a)pgadmin.org> wrote: > No. Any checks at the client are worthless, as they can be bypassed > by 10 minutes worth of simple coding in any of a dozen or more > languages. Well, sure, but we're talking about a client going out of their way to wrestle the point of the gun toward their own foot, aren't we? If we're worried about the user compromising their own password, we have bigger problems, like that slip of paper in their desk drawer with the password written on it. I mean, I know some of these checklists can be pretty brain-dead (I've been on both sides of the RFP process many times), but it would seem over the top to say that client-side password strength checks aren't OK for the reason you give. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |