On 6/22/05, bruce <bedouglas@xxxxxxxxxxxxx> wrote: > sure it can rory... > > i can give you a file... i create a hash of the file... if i have a process > within the file that i give you that allows the file to more or less create > the hash of itself, and if i can query/access the file to get the > information, then i can more or less determine if the file has been > changed.. Let me get this straight: - You give me a file containing a process, which you keep a hash of. [ I assume by 'process' you mean code to create a process. ] - Process creates hash of itself. [ which should be the same as the one created by you ] - You then access the file [ I assume you mean the hash, generated on the client ] - and determine if the file has been changed. [ by, I'm assuming, comparing the hashes. ] Assuming I understand your suggestion, you're simply checking to see if the file has been changed. How exactly does this detect hacked browsers? If the code to do the hashing is in the file you give me, then the browser used is irrelevent. The hash will be the same. If the code to do the hashing is in the browser, then anyone who hacks the browser, generally wouldn't modify the hashing code. You could conceveably hash the browsers binary, but there nothing to stop the hacked browser from simply storing and returning when requested checksum. Even if the hacked browser did execute the file correctly, it could simply replace the file access routines, with ones redirecting the file to a legitimate binary. > > would this approach require additional functionality.. sure but it might > also require no more than a plugin... the issue is that there are multiple > ways of tryng to determine if you have a legitimate file/app... 'trying' being the operative word. > > i hope you don't have this narrow focus with any of your customers, or in > your daily job.. or you might simply need to recognize that there's a lot > more that you don't know, than you do... ahh to be young! I think that applies to everyone, and is particularly irrelevent to this discussion. The fact that there are things I don't know doesn't take away from the stuff that I do, and one thing I do know is that your current suggestions are completely impractical. > > do some research, check some of the literature.. > > -bruce > > > -----Original Message----- > From: Rory Browne [mailto:rory.browne@xxxxxxxxx] > Sent: Wednesday, June 22, 2005 6:58 AM > To: bedouglas@xxxxxxxxxxxxx > Cc: Rene Brehmer; php-general@xxxxxxxxxxxxx > Subject: Re: Re: security question...?? > > > Okay Bruce: > There's one very major problem with your suggestion - IT CAN NOT BE DONE. > > YOU CAN NOT TEST A REMOTE PIECE OF SOFTWARE TO MAKE SURE THAT THERE > HAVE BEEN NO CHANGES TO IT. > > There are ways of checking what type of valid browser, or what type of > valid Operating System, your using, but "invalid" or "illegitimate", > would return the same test results as "valid" or "legitimate", since > anybody hacking them would hack them to return the "valid/legitimate" > results to such tests. > > Just incase you didn't understand me earlier - YOU CAN NOT RELIABLY > TEST REMOTE SOFTWARE TO MAKE SURE THAT IT HAS NOT BEEN HACKED AND/OR > CRACKED > > On 6/22/05, bruce <bedouglas@xxxxxxxxxxxxx> wrote: > > rene... > > > > the scenario that i'm envisioning could very well cause people to get > > ticked. but i also can easily see financial institutions starting to tell > > their customers, that unless your system is of a certain level, or running > a > > certain kind of browser, that you'll get charged more to do business with > > them... > > > > security is an issue, and it's going to get larger. and that will require > > thinking about the user/client's setup.. > > > > if i as a bank, refuse to allow you to signin to my server, because i > detect > > that your client is not valid/legitimate, meaning i think it's been > hacked, > > how have i trampled the rights of anyone. i haven't. will some customers > > run, sure.. perhaps.. will i potentially feel better. yeah. will i > > potentially have something that i can promote as an extra level of > security > > that others don't have, maybe.. > > > > let people continue to read/hear about massive losses of data and see what > > happens... > > > > rene, you also have to understand, i'm not trying to determine if the > user's > > entire system is 'clean/valid'. i'd settle for a way of knowing that the > > browser/client that i'm talking to is legitimate!! > > > > -bruce > > > > > > > > -----Original Message----- > > From: Rene Brehmer [mailto:plasticbunny@xxxxxxxxxxxxxx] > > Sent: Tuesday, June 21, 2005 3:18 PM > > To: php-general@xxxxxxxxxxxxx > > Subject: Re: Re: security question...?? > > > > > > Documented research indicate that on Tue, 21 Jun 2005 13:37:50 -0700, > > "bruce" wrote: > > > > > chris... > > > > > > what you state is true at the extreme... but in the case of an client > app, > > i > > > could already extract information about the various apps that make up > the > > > client.. ie if, as in the case of IE, I was able to get information from > > the > > > IE browser about various dlls that make up the browser. if these pieces > of > > > information correclt match what msoft would state should be there, then > i > > > could assume that the app was/is legitimate. > > > > BUT: That would mean that you can't take into account any plugins or > > extensions the user might install. And the security leak you're afraid of > > might not even be IN the browser program used. It might as well be a > packet > > sniffer on the outside of the user's firewall ... > > > > > and here's why. while you may not give a damm, there will be a growing > > > chorus of people who'll want to know that the developers/sites are doing > > > everything they can to ensure the safety of the entire transaction. in > > fact, > > > i'm willing to bet that somehting like what i've been discussing will be > > > delivered, and promoted as a security/selling point... > > > > I think it's more a matter of education and morale than anything else. You > > can't take responsibility for all clients not screwing up their own > system. > > You just have to hope and trust, that when you tell your users to use this > > and that browser, and take this and that precaution, that they actually do > > it, and not install a whole bunch of crap that creates a security problem. > > > > What you're asking for is basically a way to control what users do on > their > > own computers, and refuse them if you don't like what they've done. It's > > not very short of invasion of privacy. Electronic Arts already do that > with > > their games (spy on your computer without your permission, and the refuse > > you to play the game you legally paid for, because you have other legally > > paid programs that they don't approve of). > > > > What you can do however, is to develop an app that can run a security test > > locally on the user's computer, and have that app sign off on the user > > being safe enough for you to want to deal with him. And then force them to > > regularly have to do that again. But I'm telling you, the more troublesome > > you make it for your users to use your stuff, the more users you'll loose, > > and fast. Mostly thanks to MS and Apple, computer users today know very > > little about their computers, or how they work, or how they protect > > themselves, and we teach them that they should all and anything that comes > > their way. So it's continuingly limited what you can actually ask a > > computer user to put up with, they'll just go somewhere else that's less > > hazzlesome (that's the whole reason the majority use IE: It's there, it's > > easy to use, it gets the job done, and it doesn't complain a whole lot). > > The majority of end-users don't care, or know, or understand, simple > > security precautions when it comes to network traffic. > > > > Education and discipline is, in the end, the only means to achieve what > you > > want. > > > > /rambling off > > -- > > Rene Brehmer > > aka Metalbunny > > > > We have nothing to fear from free speech and free information on the > > Internet, but pop-up advertising! > > > > http://metalbunny.net/ > > My little mess of things... > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > -- > > PHP General Mailing List (http://www.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
