At 10:00 PM 1/22/02 -0800, Gregory Neil Shapiro wrote: >sallan> I guess my response would be that should someone's email account >sallan> become compromised (or data sniffed), the ability to do all sorts >sallan> of damage has always been there. > >Yes, the problem existed before your post but that doesn't mean it >shouldn't be fixed. :)
I am pretty sure it will never be *fixed* (completely). We can (and will) address it further. >sallan> I am not sure how to design against this - allowing registrants to >sallan> have their U:P combo sent to them is a really useful feature, and >sallan> is pretty standard. > >A couple of ideas have come up on the mailing list. My favorite two are: > >1. Give the information to the reseller via the secure RWI connection so > the resellers can generate a secure message to the user using > alternative methods (PGP, phone call, fax, hand delivery, etc.). >2. Provide an API call so the reseller can automate the process (customer > requests the password via web form on reseller's server, reseller > application uses secure API connection to get password and PGP encrypts > or sends it to fax modem). This would eliminate the human time spent in > #1. These are both decent suggestions. Supporting PGP would require some overhead that we might want to charge for. >sallan> My understanding (perhaps wrong) is that plain text data (password) >sallan> sniffing exploits are pretty rare - anyone violently disagree? > >Yes. :) > >Keep in mind that the attack can come from someone on your LAN -- >especially in a university environment (or a shared LAN segment between a >neighborhood on a cable modem). I routinely see postings outside the >terminal room at IETF meetings and USENIX conferences of passwords >collected by sniffing the wireless network. > >sallan> It has always struck me as something that it is possible, but not >sallan> generally worth it. > >These days, it's so easy though -- just install dsniff and you are done. >It even gives nice reports. Fair. Probably nicer reports than we do. :) Scott Allan Director OpenSRS [EMAIL PROTECTED]
