On Mon, 8 Sep 2003, Dave Warren wrote: > If your mail server supports SSL, then the password will > be sent encrypted. If not, then it sends plain text since > that is all your mail server is able to handle.
Badly programmed application resulting in a unencrypted version of the passwords is huge bug no matter whether receiving party supports encryption or not. The application would have to simply refuse to connect to a party which is not verified and authenticated to be the reseller. And last time I checked SMTP doesn't provide for any such authentication. SSL could support this, but *ONLY* with a (pre-specified) certificate, and it doesn't look like OpenSRS is storing a certificate. *And* it is not a secure systems design to rely on MX records to deliver something sensitive. Since domain registration and handling is *above* MX resolution in the food chain, maning that domain registration and handling *controls* what an MX record will resolve to, and therefore must not be controlled by what an MX record will resolve to. And OpenSRS has allowed an MX record to determine how a domain registration and handling will happen(*1) - this is wrong and upside down ! (*1) I.e. if anyone manages to steer the traffic that depends on MX records to themselves, !they gain control over whole existence of *all* reseller's customers' domains! The *ONLY* automated, secure solution is to use data-level encryption, not transport-level encryption (unless OpenSRS holds a pre-stored certificate *required* for a connection to be established). Such wide-spread data-level secure solution exists, and is called PGP. Each customer should have the option to supply the public PGP key to use for sensitive (if not for all) email communication with OpenSRS. > Personally, I don't think the password itself should be > sent out, but rather a token which can be used to change > the password, but that's just me. I can't believe that OpenSRS actually stores the password in a form that can be changed back to plaintext. That should be barred by law (isn't it?). Hash is sufficient ! They have no business knowing what our password is. Their business is to know whether supplied password matches the one that was previously set up. (This is what hashes are for.) And, even better, only the password hash would be transmitted (would be calculated by JavaScript on JavaScript-enabled clients. But this is not necessary. I have enough trust in OpenSRS that if they don't store their customers' plaintext passwords, they won't go to the lengths to leak it to anybody with a network monitoring tool). Mark.
