Rejecting weak passwords
in [PgSql]
|
From: "Albe Laurenz" on 15 Oct 2009 10:38 Mark Mielke wrote: > Does Oracle really do password checks on the base SQL commands used to > change an Oracle password? That sounds silly. In Oracle you can write a stored procedure to check passwords; it is invoked whenever a user is created or altered. No matter how you change the password, Oracle can always recover the plaintext and feed it to the password checking function. So, unless you use the "Advanced Security" option (extra $$) that enables you to encrypt network connections, any eavesdropper with knowledge of Oracle's (secret) encryption algorithms can get your new password when you change it. And the DBA can get your password with ease. Yours, Laurenz Albe -- 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: Mark Mielke on 15 Oct 2009 12:23 On 10/15/2009 03:54 AM, Dave Page wrote: > On Wed, Oct 14, 2009 at 11:21 PM, Mark Mielke<mark(a)mark.mielke.cc> wrote: > >> On 10/14/2009 05:33 PM, Dave Page 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. >>> >>> >> Why care? >> > Because many large (and small for that matter) organisations also have > security policies which mandate the enforcement of specific password > policies. Just because you think it's worthless to try to prevent > someone reusing a password, or using 'password' doesn't mean that > everyone else does. Some organisations will use such a feature in a > box-ticking exercise when evaluating, and others may actually decide > to use the feature, and expect it to work effectively. > > Beside, we are not in the habit of putting half-arsed features in > PostgreSQL. If we do something, we do it properly. > You miss my point (and conveniently cut it out). For users who accidentally break policy vs users who purposefully circumvent policy - the approaches must be different, and the risk management decision may be different. It's a lot easier to circumvent policy than most people (management specifically) realize. If your attempt it to absolutely prevent a determined competent individual from circumventing your policy - you need to do a LOT MORE than what you are suggesting. If you just want to prevent accidents - having the client software do the checks is fine. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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: Mark Mielke on 15 Oct 2009 12:28 On 10/15/2009 10:08 AM, Dave Page wrote: > It's certainly true that there are other ways for users to compromise > their passwords if they want. The fact remains though, that most other > DBMSs (and all major operating systems I can think of) offer password > policy features as non-client checks which are difficult, if not > impossible for the user to bypass. Clearly other people think it's > important to do this, and we are compared against their products on a > daily basis, so if we want to compete with them on a level playing > field we need at least a comparable feature set. > Not so clear to me. If they're doing strong checks, this means they're sending passwords in the clear or only barely encoded, or using some OTHER method than 'alter role ... password ...' to change the password. Point being - if you think this is absolutely important to do - don't go +5% of the way - go 100% of the way. Then again, I'm not so concerned about what arbitrary criteria some person defines as "what makes a good database system". I'm more concerned with what makes the system better for *me*. I don't see how this entire thread helps *me* in any way - and I do understand the need for strong passwords - and my company *does* have policies that require strong passwords. Even if the plugin is provided - I'm not going to activate it. I already have a policy for setting strong passwords that I already follow. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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: Mark Mielke on 15 Oct 2009 12:38 On 10/15/2009 10:38 AM, Albe Laurenz wrote: > Mark Mielke wrote: > >> Does Oracle really do password checks on the base SQL commands used to >> change an Oracle password? That sounds silly. >> > In Oracle you can write a stored procedure to check passwords; > it is invoked whenever a user is created or altered. > > No matter how you change the password, Oracle can always recover > the plaintext and feed it to the password checking function. > > So, unless you use the "Advanced Security" option (extra $$) that > enables you to encrypt network connections, any eavesdropper > with knowledge of Oracle's (secret) encryption algorithms can get > your new password when you change it. > > And the DBA can get your password with ease. Now I remember. Our "secure password server" used as single-sign on for most applications in the company, which normally avoids any applications ever having to see or authenticate the login, needs to send the passwords in plain or encoded form (not one-way encrypted) to a few "broken" systems, which include systems designed around Oracle user management, to allow people to login to these applications using their corporate wide password. I remember thinking one word when I learned this... "awesome" (sarcastic tone playing in head). Where is the check box that says "prevents password recovery"? For Dave Page: Understand that in a large company, as you are discussing, with policies that require strong passwords, the usual reason for requiring strong passwords is due to concerns over privilege escalation. Access to one system gives you access to others. In the case of single sign-on, which is a requirement for any business with dozens or more applications, where it is unreasonable for each employee to actually memorize dozens of distinct "strong" passwords, access to one system gives you access to all systems. Therefore, "trust the DBA" makes no sense. If the DBA can see my password, then they can login to my employee records and check out what my salary or contact information is, or they can login to one of the secure portals and authorize purchases as me. A *good* system, is not trusted with the password. This is why I say you are focusing on making PostgreSQL what you think is a tiny bit better, but the gain is minor or artificial. If PostgreSQL starts requiring strong passwords - the world is not necessarily a better place in any mind except the person doing the ignorant checkbox evaluation who believes advertising on face value. If you need security - you should know enough to know you need something better than per-application password strength checkers. Cheers, mark -- Mark Mielke<mark(a)mielke.cc> -- 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 15 Oct 2009 12:41
On Thu, Oct 15, 2009 at 5:28 PM, Mark Mielke <mark(a)mark.mielke.cc> wrote: > > Not so clear to me. If they're doing strong checks, this means they're > sending passwords in the clear or only barely encoded, or using some OTHER > method than 'alter role ... password ...' to change the password. Some are sending them in the clear (though often over SSL connections). > Point being - if you think this is absolutely important to do - don't go +5% > of the way - go 100% of the way. Exactly - that's why I want to see a check in the server, not the client which should get to 95%. I also happen to agree with Magnus that the only really secure way to do this on outside of SQL, but I can't see us dropping ALTER USER ... WITH PASSWORD in a hurry. > Then again, I'm not so concerned about what arbitrary criteria some person > defines as "what makes a good database system". I'm more concerned with what > makes the system better for *me*. I don't see how this entire thread helps > *me* in any way - and I do understand the need for strong passwords - and my > company *does* have policies that require strong passwords. Even if the > plugin is provided - I'm not going to activate it. I already have a policy > for setting strong passwords that I already follow. That's an excellent point. It probably doesn't make any difference to you or many of the other people on this list who are concerned with running their own systems and may already use other techniques, such as LDAP, SSPI etc. A not-insignificant percentage of the people here are not concerned with running their own systems though. They are working to help new users adopt PostgreSQL, and make a living selling services or support to those users. Sometimes that can be for huge projects, where it is necessary to justify every difference in check-box items against other products to get past the early eval stages. Like it or not, that is a fact, and this hampers our adoption. -- 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 |