Presumably the reason you don't want to give out the Mappoint key is because they can use the key to perform requests that they can't do through your app.
How about building a webservice 'proxy' that only exposes the behaviour that the application needs, and which in turn connects to the map-point service using the key? That way the key never needs to be distributed to clients. Kirk -----Original Message----- From: Dan Souk [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 14 May 2002 4:52 a.m. To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Hide part of code from Developers Isn't the real risk in this type of setup not having your key snooped, but having the return value hijacked? However complex and clever the encryption is designed, if all it sends back is true/false, the return value is the only thing that has to be compromised. Or am I missing something? -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Peter Vertes Sent: Monday, May 13, 2002 11:40 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Hide part of code from Developers The original key doesn't get transmitted via the network nor does it get hard coded. Consider this: you have a remote machine that has a service running on it waiting for someone to connect to it with a certain string. So Joe Developer makes a call to this service from his code, from his workstation, like: bool authCheck = CheckKeyAuthenticity("strSecretKey"); Now, method CheckKeyAuthenticity() will make a connection to the remote machine and pass in the string that was given to it as a parameter (strSecretKey). The service, on the remote machine, takes this string and compares it to a string that it has (this original key can reside in a file, registry, database, etc... depending on how you trust this remote machine). Now, if the strings match the service returns true (meaning the correct key was passed in to CheckKeyAuthenticity() or false if the keys didn't match. The original key was never transmitted through the network only the result of the authenticity check. If one is worried about snooping then encrypting the key would be a wise idea before sending it off to the remote machine, but in that case the remote machine's key should be encrypted too. That way only the encrypted string can be sniffed and not the plain-text string. Still not a 100% tamper-proof solution but better then nothing. If someone wants to get that key they would have to work hard for it. -Pete -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Brad Wilson Sent: Monday, May 13, 2002 12:21 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] Hide part of code from Developers Peter Vertes wrote: > How about storing the key on a remote server ? When you need it you connect > to it get it. Or extending on this idea; you could store the key on a > remote server, when you need to authenticate you call the authentication > code on the remote server side and have it spit back a bool (true = user is > authenticated / false = user need to try again). I haven't actually > implemented this but in theory it should work. You're still in an automated case. The code that calls the server is subject to snooping, and any authentication information would be contained within the code, so the bad guy could pick out that information and call the remote service manually to discover the key. Until you put a human (who isn't the person you're trying to prevent from snooping) is put in the loop, any data is snoopable with enough effort. Brad -- Read my web log at http://www.quality.nu/dotnetguy/ You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
