Next message: Igor Brezac: "Re: on a similar note: enabling CRAM-MD5 auth for postfix+cyrus-imap+auxprop+mysql w/ encrypted passwords?"
On Thu, 11 Nov 2004, OpenMacNews wrote:
> if the goal is to migrate to _this_ proposed system, then eventually
> there's an administrative task to be undertaken. either:
[...]
> (b) the existing encrypted PWD db's beed to migrated to (i) unencrypted
> stores, or to (ii) a translated system where "something_in-the_middle"
This is the only way you can do that right now (if you're going to use
anything SASL based, that is). Of course it is a pain, since you either
have to reset everyone's password to something and send it to them using a
not-too-insecure secondary channel... or you have to tell everyone to change
their password in X weeks (and store the new password in plaintext
somewhere, to feed to SASL in the new system).
What I would do here would be something like this:
1. set aside at least two months for the password changeover
2. tell all users that we will be doing a major upgrade in the near
future, and that we are taking advantage of the opportunity to
(don't know the exact word in english) "review all subscription
information" to weed-out outdated and bad account information.
I will call this "procedure A". Warn the users that they must
go to page <url>/visit building bar and deliver form foobar signed
by their boss/whatever redtape you want, and enter/update their
new information, or their accounts will be locked in <password
changeover deadline>.
3. make sure that "procedure A" tells the user to update their
passwords, and store it in plaintext somewhere.
In a corporate environment, I *would* make the best out of "procedure A",
and root out people with weird account information, or unauthorized
access... and force everyone to sign a form accepting the terms-of-usage
for the email system while at it :-)
> (c) a system needs to be migrated TO that does not require such
> reconfiguration -- i.e., one that DOES support secret-based auth over
Not doable in practice. For *some* auth types, it could be done, but it
would require extensive changes to a lot of stuff. But there are auth types
for which this is just impossible I think.
In the end, you gain nothing security-wise if you store data like above (the
encripted/hashed data is a plaintext equivalent and can be used to
impersonate the user as is), so it doesn't make sense to have SASL act that
way. It would help migrations, true, but it would leave a half-broken SASL
behind...
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
