I support Derek's emphasis on security.
swerve
> From: "Derek J. Balling" <[EMAIL PROTECTED]>
> Date: Wed, 27 Sep 2000 13:32:07 -0700
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: Wish List Additions
>
> 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
>
>
