It has been established that the password feature only works for names you sponsor.
sA Scott Allan Director, OpenSRS [EMAIL PROTECTED] On Wed, 23 Jan 2002, POWERHOUSE wrote: > I agree, however, if we were to implement that at the RSP level, wouldn't > they be able to go to another RSP, > and ask for the password, and get it? I have a password utility that will > send the password to my customers, but > It won't work for one that is not under my RSP username. I don't know if the > utility that you use, is the same, since > I have not yet tried it, so I can't really comment on that at the RSP level > until I'm informed how it works in the manage.cgi > to send it, or until I finish integrating it into our system. > > Thanks > Richard. > http://register.firstratehosting.com/cgi-bin/reg_system.cgi > > > ----- Original Message ----- > From: "Scott Allan" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, January 23, 2002 4:00 PM > Subject: Re: Some improvements we would like feedback on.... > > > > 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] > > > > > > >
