> > They should absolutely *not* be stored as plain (clear?) text.
>Sorry, but that *is* a knee-jerk reaction.
The text you left out explained my reaction in terms of publicly accessible
Internet sites. I did also say that it would be advisible to allow any kind of
authentication mechanism whether it stores passwords as plain text or
uses "Tony's secret code wheel" from the back of a Kellogg's Frosties packet.
>There are tradeoffs both ways, and it should be the app developer's/local
Absolutely, but I think that for pre-packaged solutions for the
novice/inexperienced developer (or even the experienced developer who isn't an
expert on security tradeoffs) certain things should either be highlighted as
dangerous, or not used as the default in the solution proposed. Even if it's to
avoid repeated frequently asked question sessions, the "batteries included"
packages should attempt to define best practice, or best practice given a set
of well-publicised compromises.
>If passwords are hashed, it's impossible have an "I forgot my password;
>mail it to me" screen, because the program cannot unhash the password.
>You can say, "Oooh, that's unacceptable," but it all depends on what the
>password grants access to. If it's to my bank account, it better be hasned
>and behind 128-bit https: . But if it's just to post to a forum or edit
>an online profile/resume, maybe it doesn't matter that much and it's
>more important to provide convenience instead. Because forcing ppl to
>change passwords to something they didn't choose runs another risk:
>that they'll forget the password again.
Indeed, and it is up to the user to determine whether or not their password
should be re-used across different services and whether they can trust a
service enough to give them a certain password. However, such judgements can
really only be taken if one knows that a service is going to store a password
securely or not and whether the employees or providers of a service are
scrupulous, but "gut feeling" probably suffices. Naive users, however, probably
don't have the experience to decide upon these things with a high degree of
On the subject of online banking services, both of the ones I use have machine
generated access codes and passwords, and rely on scratch lists in addition. I
suppose banks don't want users to choose passwords which they may also have
issued to "Insecure and Dubious Chatrooms" which store their passwords as clear
text (and mail them out to their friends on a weekly basis).
>mod_auth_mysql has a particularly robust design. You can configure
>whether passwords are added in plaintext, DES, or MySQL PASSWORD()
>format. Then when checking passwords, you can configure several
>encryption schemes, so that it will try each scheme in order until
>one succeeds or they all fail.
My suggestion was that we leave all of these mechanisms open to configuration,
just like PAM supposedly does for UNIX authentication. What I really wanted to
emphasise was that one shouldn't spend too much time thinking about how to do
certain concrete things; it's best to follow Tavis's suggestion and start with
the absolute basics, which in my mind is the issue of defining identity in
terms of sessions and users and providing an API for managing this. Whether
someone then wants to authenticate using passwords, and whether they want to
permit reserve questions when/if users forget passwords, is really up to a
module which someone could write for this purpose. But I think it's too early
to wonder too much about how that module might work in detail, although we
could try and define an API, I suppose.
Get your firstname@... email for FREE at http://Nameplanet.com/?su