At 10:28 AM -0700 9/27/00, [EMAIL PROTECTED] wrote:
>>Personally, I'd rather require that $CUSTOMER call Tucows/etc., and
>>provide proof of identity, the whole nine yards in the case of a
>>forgotten password, than for someone to be able to sniff the
>>password at some stage of e-mail and get it handed to them.
>
>This is how you personally feel.
>
>What do your customers want?
I am my own best customer, but I can probably speak for them (all
four of them) that they'd feel the same way.
>Many of our customers are too busy with their brick-and-mortar
>businesses to worry about doing the full 9 yards to prove their
>identity as you mentioned.
Then let them have the option of not protecting it. Just the same as
I request the option of protecting it.
I'm certainly not of a mind to make peoples' lives unnecessarily
difficult, but I am averse to having security sink to the
lowest-common-denominator. Just because "your" customer wants ease of
use and easy access, don't tell me that my password has to be
retrievable in the clear. ["Your" and "my" are used generically
here, not you in particular].
>It would seem appropriate that the RSP could obtain the password,
>call the customer directly, and give them the password when
>requested.
>Instead of using e-mail for this procedure, we could use the
>telephone number. This way we'd only have to worry about wire-taps.
Indeed, that's one extra level of security I wouldn't mind. Although,
the RSP should be incapable of getting access to the password because
(in reality) the password shouldn't be STORED in cleartext (which it
obviously currently is). It should be stored as the result of some
trapdoor encoding routine (MD5, crypt(), etc.).
D
