I like your security suggestions - I have had similar thoughts myself often. I am pretty sure we could not force this on everyone (or anyone for that matter...). This could be implemented at the RSP level, and be a distinctive selling point. We could also implement an optional opt-in "challenge" system, which is a decent idea. Would people pay extra for it? (not that we would *have* to charge for it).
The little I know about security: - no system is perfect - higher security generally means lower usability - you want to generally engineer your systems one or two iterations ahead of "easily" exploitable, generally trying to require more value of effort to "steal" than the value of any asset - there are external factors, like how easily exploitable other similar targets are - one of the best metrics for any system is the amount of abuse it attracts, currently we are well within what I consider an "acceptable" level, certainly we need to make sure we stay there and continue to evolve our security options Thanks for your feedback though - great stuff! Regards, sA At 03:23 PM 1/22/02 -0600, POWERHOUSE wrote: >Hello everyone, >Pop3 Email passwords are crackable, If a cracker is able to crack a pop3 >email password, all that one has to so >is setup the profile in Outlook Express, to download all the email, and >leave it on the server too. That is a more >"detectable" way of doing it, but if all they wanted where to set up that >email, Then have the password sent to them, >check the email, then hijack the domain, then delete the profile from >outlook express, They could even delete that email >from the server by checking the box in Outlook Express to delete the >messages off the server when deleting from the computer. >If they only deleted that ONE email, it would then delete it from existence >on the server, then they could delete the profile from >Outlook Express, and the domain owner would never know it, until their >domain was not working. They would not receive their >password, so they would not even be suspicious, and if it was the same >domain name, that their email is coming from, they will >know it when they no longer get their email, and just get a error message. > >I recommend this instead. I would start with ALL NEW customers, and have >them fill out a 3 part question during >registration. First question, should be a Question and Answer. Stating to >them, that it should be a question they will >NEVER forget, like maybe their first animal as a child, if they remember it >now, they probably will later too. >The second question should be what their D.O.B. is in MM/DD/YYYY format. >And finally the third question should be their city of birth, in all >lowercase, in case they can't remember how they typed >it in when they need their password. > >Now, in the database where the password is stored for the domain management, >if they forget it, they should NOT get it >in the mail, instead, they should have to answer all 3 of those questions, >and then it reset it for them. Now if a cracker >was to compromise the domain owners computer, its highly UNLIKELY that he >will find ALL 3 ANSWERS on the >domain owners computer, and not likely that he'll find them sniffing emails, >or downloading emails. > >That being for all new registrations. For current customers, they should get >prompted to answer those questions the first >time they login to manage their domain, HOPEFULLY, it won't be a cracker who >compromised the account, and is signing >in, and then ends up filling in the information. Of course if that happens, >the cracker is going to hijack the domain ANYWAYS, >so they can all be fixed at the same time. > >All that you'd have to do for NEW registrations is add those hidden fields >to the Database, then add it to the required information >to register the domain name. That would NOT be hard at all. The hardest part >would be if they need their password, and you have >to make the interface ask them all 3 questions, THEN, if they area all right >prompt them for a new password, and change it at that point. >Then send an update to ALL RSP's telling them their is new REQUIRED >information for security to new registrations. FORCE all of them >abide by the new security measures by adding the extra few lines of code >into the setup profile template, and into the reg_system.cgi or >equivalent file, that would support this issue. > >I'm sure that 90% of all clients would appreciate this security, the other >10% would probably be those who don't worry about security, >and are in to big of a hurry to fill out the information. > >That is how my company would do it. Security is always a number 1 priority, >and should be, I know a few crackers, and they are very >malicious. They love breaking into things, they get a high off of it. > >Richard Jones >[EMAIL PROTECTED] >http://register.firstratehosting.com/cgi-bin/reg_system.cgi > > >----- Original Message ----- >From: "Paul Chvostek" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Tuesday, January 22, 2002 9:53 AM >Subject: Re: Some improvements we would like feedback on.... > > > > > > On Tue, Jan 22, 2002 at 08:22:46AM -0500, Scott Allan wrote: > > > > > > > >Although I realize there are issues here, it would be nicer to allow me >to > > > >query for a users password using the (secure) RWI and then I can > > > >communicate that password to my customer securely (notably with a PGP > > > >encrypted message). > > > > > > I guess my response would be that should someone's email account become > > > compromised (or data sniffed), the ability to do all sorts of damage has > > > always been there. I am not sure how to design against this - allowing > > > registrants to have their U:P combo sent to them is a really useful > > > feature, and is pretty standard. I can't think of a way that improves > > > security without seriously compromising usability... PGP is nowhere near > > > widely enough deployed - I guess we could let resellers globally disable > > > this for their names, but that would likely not be an option that many > > > would choose, therefore not greatly improving security (it would of >course > > > allow those who desire greater security to have it). > > > > I would be heartily interested in using a system which allowed the > > password to be collected via the API for secure dissemination to the > > customer by the RSP. We already give customers the option of receiving > > their invoices via email that is PGP signed, encoded or both. It has > > been a silent beef of mine for some time that the only way to get a > > customer his domain management password is in cleartext email. > > > > > My understanding (perhaps wrong) is that plain text data (password) > > > sniffing exploits are pretty rare - anyone violently disagree? It has > > > always struck me as something that it is possible, but not generally >worth > > > it. In this case, not only would you have to be able to guarantee you >could > > > get all the mail sniffed, but also be familiar with the OSRS manage >system. > > > > It really depends on the particular RSP. We had an incident just a few > > weeks ago in which a unix server close to a router at our upstream was > > compromised, and the leftover logs that were discovered indicated that > > cleartext POP3 logins to my co-lo customers had been properly sniffed. > > It's unknown how long the cracker was sniffing, and/or if he managed to > > grab FTP, IMAP, HTTP and telnet passwords that simply didn't have > > leftover logs on the box. In November, a customer's Cobalt on my > > network was compromised, and the cracker may have managed to snarf a > > few days worth of POP3 logins from my customer's dialup pool. > > > > These things *do* happen, in some places more frequently than in others. > > If the development tools to protect myself from them were available, I > > would certainly use them. Does OpenSRS feel there's a liability issue > > in providing cleartext passwords to RSPs? > > > > -- > > Paul Chvostek <[EMAIL PROTECTED]> > > Operations / Development / Abuse / Whatever vox: +1 416 598-0000 > > it.canada http://www.it.ca/ > > > > > > Scott Allan Director OpenSRS [EMAIL PROTECTED]
