From: | Mark Mielke <mark(at)mark(dot)mielke(dot)cc> |
---|---|
To: | Albe Laurenz <laurenz(dot)albe(at)wien(dot)gv(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>, Marko Kreen <markokr(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, mlortiz <mlortiz(at)uci(dot)cu>, Magnus Hagander <magnus(at)hagander(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Rejecting weak passwords |
Date: | 2009-10-15 16:38:14 |
Message-ID: | 4AD74FF6.4010005@mark.mielke.cc |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)mielke(dot)cc>
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2009-10-15 16:41:34 | Re: Rejecting weak passwords |
Previous Message | Mark Mielke | 2009-10-15 16:28:45 | Re: Rejecting weak passwords |