Thread: storing passwords

storing passwords

From
Ron Peterson
Date:
I'd like to propose the unthinkable, to see what people think.

I have been considering the possibility of storing passwords in a
PostgreSQL database.  Unencrypted.

Boo Hiss.  I know, I know...

But consider.  In an environment with multiple architectures, and
multiple applications, with many users, password management is
difficult, at best.

Solutions like LDAP are a step in the right direction, but until there
is widespread support of this standard, it is only a partial
solution.  Besides which, my preferred implementation, OpenLDAP, has
yet to fully support SASL.  (LDAP => SASL yes, SASL => LDAP no).

In addition to the problem of the need to distribute authentication
credentials, there is the small matter of simply *remembering* lots of
different passwords.  We're all told: "Don't write them down, but make
them impossible to crack."  Which might be fine if there you only had
one or two passwords to remember.  But I'd hazard to guess I have some
dozens of passwords I need to know.  Some I use frequently, some not.
I try to minimize, but that's not always something I can control.

So yes, I do physically record my passwords.  Truth be told, they are
in a file on my computer, to which only I have access.  There, now you
know.  Hack me to bits.  I don't know how else to manage this problem.

So I've been thinking about doing something like the following.
Against my better judgement, which is why I'm writing this damnable
expose of my ignorance.  Disabuse me, please.  Am I completely nuts,
or could something like the following work?

In a multi-user environment, allow people to change their password via
a web form.  Via https, of course.  Store the password, *unencrypted*,
in PostgreSQL.  Run scripts to distribute updates to necessary
locations.  Maybe crypt, maybe md5, maybe sha, as required.  Via
secure channels, of course.

I cringe as I await your response...

-Ron-


RE: storing passwords

From
"Robert D. Nelson"
Date:
>Solutions like LDAP are a step in the right direction, but until there
>is widespread support of this standard, it is only a partial
>solution.  Besides which, my preferred implementation, OpenLDAP, has
>yet to fully support SASL.  (LDAP => SASL yes, SASL => LDAP no).
>
>In addition to the problem of the need to distribute authentication
>credentials, there is the small matter of simply *remembering* lots of
>different passwords.  We're all told: "Don't write them down, but make
>them impossible to crack."  Which might be fine if there you only had
>one or two passwords to remember.  But I'd hazard to guess I have some
>dozens of passwords I need to know.  Some I use frequently, some not.
>I try to minimize, but that's not always something I can control.
>
>So yes, I do physically record my passwords.  Truth be told, they are
>in a file on my computer, to which only I have access.  There, now you
>know.  Hack me to bits.  I don't know how else to manage this problem.
>
>So I've been thinking about doing something like the following.
>Against my better judgement, which is why I'm writing this damnable
>expose of my ignorance.  Disabuse me, please.  Am I completely nuts,
>or could something like the following work?
>
>In a multi-user environment, allow people to change their password via
>a web form.  Via https, of course.  Store the password, *unencrypted*,
>in PostgreSQL.  Run scripts to distribute updates to necessary
>locations.  Maybe crypt, maybe md5, maybe sha, as required.  Via
>secure channels, of course.

Ron,

Very good question. I recently came back from LISA 2000, where we had a
discussion on this very subject of multiple passwords...actually two. One
was on Windows/Unix integration, and the other was distributed forms of
maintaining passwords across multiple hosts (i.e. how to make a password
change fall out to solaris, linux, osf1, etc., all at the same time). While
it's not online yet, the class notes for Unix will be at
www.castle.org/class. In the meantime, I'll look to first find the CD that
should have some of the slides and then see if they're on there, I'll let
you know if I find them.

Two big things from the class. One, somewhere, somehow, you will have to
store the passwords in a database in a way that everything can read. If you
can store it hashed, fine, but hash differences may force you to use clear
text. Be cautious, and make sure that the database doesn't hold a lot of
other information, like the machines that person has access to.

The other big thing was making sure that when the password is changed, it's
changed. If it goes into a database and then replicates outward, chances are
the user will log out and back in again to find that it failed, and then go
to the web page and change it again. And make sure that only hosts that
person needs access to get the password, don't push it to every machine on
your network "just cause".

Other than that, look at how you can simplify passwords in the scheme of
things. For instance, one way we're looking at simplifying it at our site is
to get NDS for NT, which means people only have a novell password, not a
novell and NT password. Other products (in my case, Novell's dirXML, which
allows other data services to talk with NDS, whether they're LDAP or not)
can eliminate even more. You say LDAP's not there, it is but there's no easy
one-size-fits-all manual. Play with it. And if you figure something out, let
me know! ;)

Good luck, and I'll try and get you those slides if I can find them.


Rob Nelson
rdnelson@co.centre.pa.us