locked
Protect Your Bing Maps API Key RRS feed

  • General discussion

  • I posted a new article on my site.  This article touches on one of the ways you can protect you Bing Maps Key.  With v7 of the AJAX control requiring the use of an API key, you will want to make sure that your key is protected and not placed into your client side code in clear text.

    This article touches on one of the ways you can accomplish this.

    http://www.garzilla.net/vemaps/Protecting-Your-Map-Key.aspx

    I look forward to feedback and comments.

    Thanks,

    Mike Garza
    http://www.garzilla.net/vemaps

     

    • Moved by Ricky_Brundritt Friday, March 9, 2012 3:30 PM (From:Bing Maps: Map Control and Web services Development)
    Sunday, November 21, 2010 3:24 AM

All replies

  • Hi Mike

    As ever another great in-depth article, I just wonder though is this actually a problem? Has anyone confirmed with the Bing Team if someone else actually can use your bing key? As they are tied to URLs surely even a commercial key is not a problem because if someone hosts a map, using your key, but on another website the bing team will know its not you?

    there is certainly some grey areas here about what would happen but I cant see how its not already handled because as you point out with some work people can still get the key?

    Brian @ Earthware - UK interactive mapping web developers http://www.earthware.co.uk/blog | http://www.twitter.com/earthware | Windows Live Developer MVP
    Sunday, November 21, 2010 12:13 PM
  • Good question(s).  I dont know that the keys are tied to URLs.  I only have one key currently and seem to be able to use it from any URL.  I use it on my main site, some test servers as well as my local machine.  I thought I had read somewhere that this URL restriction will be enforced as future functionality, but I am not sure.  I know that google maps does enforce the URL that is used when generating their keys.

    That said, until the Bing Team does enforce the URL restrictions, I wanted to have a way to "hide" my key from plain site "just in case".  Once that restriction is in place, then hiding it may not be necessary, but until then it couldn't hurt. 

    As a side note, I think that the concept of controlling access to your web services has other uses and this model may better apply. I know that I have some services that I have been reluctant to deploy until I had an approach that I could control who/how they are accessed.

    Thanks for the feedback!

    Mike
    http://www.garzilla.net/vemaps

     

    Sunday, November 21, 2010 4:07 PM
  • I'm not sure whether any checks on the supplied keys are currently enforced, let alone the URL on which they reside.

    The following seems to work for me, both on localhost and a hosted domain:

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html>
      <head>
       <title></title>
       <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
       <script type="text/javascript" src="http://ecn.dev.virtualearth.net/mapcontrol/mapcontrol.ashx?v=7.0"></script>
       <script type="text/javascript">
        function GetMap() {
    
         var map = new Microsoft.Maps.Map(document.getElementById("mapDiv"),
                  { credentials: "Anything you want here...",
                   center: new Microsoft.Maps.Location(54.5, -2),
                   mapTypeId: Microsoft.Maps.MapTypeId.road,
                   zoom: 6
                  });
        }
       </script>
      </head>
      <body onload="GetMap();">
       <div id='mapDiv' style="position:relative; width:600px; height:800px;"></div>    
      </body>
    </html>
    

     


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Sunday, November 21, 2010 5:36 PM
  • Looking at the example above (using a made-up key) in closer detail, I can see that the background of the map div should display a message stating: "Invalid Credentials. Sign up for a developer account at: http://www.microsoft.com/maps/developers".

    However, since this message is placed at z-index:0, and all the map tiles are loaded at z-index:1, the message appears underneath and is completely obscured by the map! The map itself seems to continue to function exactly as expected, so I don't think I would ever have noticed this without the aid of Firebug...


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Sunday, November 21, 2010 5:52 PM
  • The other thing to note is that the key that is used for the AJAX control is also the key for the REST API.  In making calls to the REST API, how will Bing validate the URL?  In some cases the REST API may be called from the UI, but in other cases it might be called from server side code, where detecing the URL may not be possible.

    That being the case, it seems like you would want to protect your key as much as possible.

    Regards,

    Mike
    http://www.garzilla.net/vemaps

     

    Sunday, November 21, 2010 9:21 PM
  • I hate to say it but someone got a hold of one of my development Bing Maps Keys from one of my sample apps I forgot to remove it from. It looks like the app is in production as they incurred over 300,000 transactions in 2.5 months. I tried tracing it but only managed to find that whom ever is using it is has a Silverlight app that is in a project called http://localhost/FlyTC.Web/ClientBin/FlyTC.xap based on an IP address look up. 
    Windows Live Developer MVP - http://rbrundritt.spaces.live.com | http://inknowledge.co.uk
    Sunday, November 21, 2010 11:32 PM
  • Gutted, Ricky - I expect we've all accidentally posted code samples and then realised we've included our credentials in them and had to go back to rapidly edit them... (I know I have!). So, other than messing up your usage reports, have you suffered any other negative effects as a result? Have you considered cancelling that key and requesting a new one?

    It seems that Mike might be correct in promoting the security of our application keys, although I don't know if his solution would have helped in your particular case  - if you accidentally packaged up the whole sample app then presumeably you'd include the ClientService.asmx file that includes your key in plain code, just as if your key had been embedded in your HTML file...

    I don't know what implication this has for the many people that already do publish their Bing Maps key in plain view. In a few seconds, I've just been able to retrieve pages of results of publicly visible keys, and anyone else can easily do the same. While I've always been careful to protect my development key registered to localhost, I've never really thought too much about production keys, since I assumed the "tying to a URL" feature would have offered enough protection (and, that's the method that all the MS examples use)

    <thinks he might need to go back through his old code and check its security...>


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Monday, November 22, 2010 8:35 AM
  • I reported the issue to mpnet@microsoft.com. I was unable to delete this key as there currently not an option for this. I've stopped using that account all together for now. I made sure the right people are aware of this issue. Hopefully it is resolved in the near future.
    Windows Live Developer MVP - http://rbrundritt.spaces.live.com | http://inknowledge.co.uk
    Monday, November 22, 2010 2:17 PM
  • Well, sure the key is no longuer in the source code of the page itself, however it takes only 10 seconds to find out the key using "[Edited ] > Response" :/
    • Edited by wildpeaks Tuesday, November 23, 2010 2:24 PM
    Tuesday, November 23, 2010 8:20 AM
  • @wildpeaks - From Mike's page: "This example is intended to show how you can begin to protect this information or more specifically, hide this information so that end users cannot easily obtain that data." (emphasis added)

    This method is clearly not 100% secure, but it adds a basic layer of obfuscation against casual snoopers. The limited amount of protection offered by Mike's method has clearly now been reduced further by you publicly explaining how to get round it...   :/

    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Tuesday, November 23, 2010 8:39 AM
  • What I meant is that people who might be interested in finding out the key most likely already use that debug tool or similar ones for developing with Bing Maps already, so even casual snoopers would easily enough be able to retrieve it.

    But in any case, I'll edit the other post in order to restore your peace of mind :)
    Tuesday, November 23, 2010 2:23 PM
  • It's ok - I don't want you to edit your post! (sarcasm never comes across over the internet very well, does it?)

    You're absolutely right to point out the weaknesses in Mike's solution - I (and I'm sure he) wouldn't want people using it thinking that they were absolutely protected, so pointing out flaws is a way of making systems safer. I just wanted to give him credit for obscuring the key from some more "casual" hackers...


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Tuesday, November 23, 2010 3:00 PM
  • wildpeaks - Yes, you are right all I have done is provide a way to not have to put your map key in the client side source code.  As tanoshimi pointed out, I never claimed for it to be 100% secure, only that it would hide the key from easily being discovered.

    Since it was edited, I dont know what method you posed to view the key.  I did add some new logic (not reflected in the article), that only allows specific domains to call the web service.  In taking that approach, I can only think of one way to view the key information, which of course, I am not going to post here.

    The end result is any one who is tech savy, can find a way to read the key information.  That is always going to be the risk in implementing client side code.  That said, there are plenty of users, belive it or not, that dont know how to accomplish something like that.

    I am still looking into way to improve the concept to try and add as much protection as possible, but again, since you are working on the client side there is only so much that can be done. Even though the key information can be discovered, I still think that there is some merit in implementing a solution like this.

    If you have any suggestions on how to improve this concept, I would love to hear them.  I'm sure there is an approach that I am not thinking of.

    Thanks for the feedback,

    Mike
    http://www.garzilla.net/vemaps

     

    Tuesday, November 23, 2010 8:26 PM
  • This is the case when you are displaying map only,but  if you try to search something in your map (basically by rest api now), you won't get any result if the key is wrong. It gives 'invalid credentials' in the response.
    Wednesday, November 24, 2010 10:31 AM
  • Actually I wonder: what are the credentials used for in 7.0 ?
    In 6.3, it seemed logical because it had functions to call the REST apis, but this is gone in 7, yet credentials are no longuer optional.


    The solution I would see is using temporary tokens (instead of the permanent credentials) generated on the server-side using the credentials.
    That way:

    • it passes the new requirement that a key should be provided for using the Ajax control
    • the credentials are safely out of sight, on the server: they are never sent to the client one way or another
    • Bing knows which credentials generated the token, so it can associate any tracking or logging transparently
    • if someone steals the token, it's only valid for a a few hours, so it limits the damage he can do
    • if someone steals the token, they can only use it with the Ajax control, they would not be able to do REST requests, so that also limits the motivation of people to steal it
    • Bing could restrict the usage of the token to specific urls (which would be a setting defined at bingmapsportal), which would be okay because REST calls would continue to use credentials, so REST would be unaffected by the restriction
    • it's okay to use something temporary because most users don't stay 8 hours in a row on the same page (and even if they do, then javascript could retrieve a new token before that deadline)


    Imho that would be a good starting point to improve security, but it requires Bing to add a webservice method to generate tokens and modify the ajax control to use tokens instead of credentials.

    What do you guys think ?
    Thursday, November 25, 2010 10:52 AM
  • This article and its method of obscuring the Bing Maps Key is really a "moo point" until Microsoft provides better authentication for tracking our API usage. Instead of "View Source" all you need to do is run Fiddler, hit the site and you instantly know the key.

    I'm sure the Bing Maps team knows to look at what website is actually hosting the application and not just what Live ID registered the Key before they go and try charging someone for racking up a huge usage cost.

    It really would be nice if there were a more secure way to track API usage, especially when someone could just start using your apps key and have their usage show up in your usage reports.


    Microsoft MVP - Windows Live Platform
    Blog: http://pietschsoft.com  | Web.Maps.VE - ASP.NET AJAX Bing Maps Server Control
    Wednesday, December 1, 2010 3:53 AM
  • I presume you ment "moot point"? :-)  Again, as I pointed out this is just a way of obscuring your key from casual broswers. It's NOT secure. 

    Mike
    http://www.garzilla.net/vemaps

     

    Wednesday, December 1, 2010 3:40 PM
  • Just an update on the situation I had. Apparently MPNet can delete keys for you. So if you suspect someone has stolen your key send an email to mpnet@microsoft.com
    Windows Live Developer MVP - http://rbrundritt.spaces.live.com | http://inknowledge.co.uk
    Wednesday, December 8, 2010 11:07 AM
  • any developer worth a grain of salt would be able to easily find out an api key that is use on the client, the illusion of security is worse than none at all.
    Monday, December 20, 2010 11:55 PM
  • I was looking at "Developing with the 7.0 Map Control" (http://msdn.microsoft.com/en-us/library/gg427606.aspx). As much as I understand the idea is to use REST Services when Location Search is needed, and then it's still not clear how is that possible to obscure the credentials.
    Tuesday, December 21, 2010 9:00 AM
  • Utlimately you can't.  The mail problem is that we need to work with client side technologies (JavaScript).  Because the Bing Maps Services are invoked from the client, you need to persist (in some capacity) your credentials on or through the client.

    Because of this you can never completely obscure your API key.  The best you can do is not put it in you code as plain text, but that still does not prevent it from being discovered.  Until that time that the API keys are tied to a domain or URL, there is always going to be risk that some one can use your key.

    Thoughts?  Anyone?

    Mike Garza
    http://www.garzilla.net/vemaps

     

    Tuesday, December 21, 2010 1:54 PM
  • Any thought I had on that are in the november post where basically the best security/changes required ratio would imho be temporary tokens, but that it would require changes on Bing's side for starters, so it's unlikely to happen.


    The solution I would see is using temporary tokens (instead of the permanent credentials) generated on the server-side using the credentials.
    That way:
        * it passes the new requirement that a key should be provided for using the Ajax control
        * the credentials are safely out of sight, on the server: they are never sent to the client one way or another
        * Bing knows which credentials generated the token, so it can associate any tracking or logging transparently
        * if someone steals the token, it's only valid for a a few hours, so it limits the damage he can do
        * if someone steals the token, they can only use it with the Ajax control, they would not be able to do REST requests, so that also limits the motivation of people to steal it
        * Bing could restrict the usage of the token to specific urls (which would be a setting defined at bingmapsportal), which would be okay because REST calls would continue to use credentials, so REST would be unaffected by the restriction
        * it's okay to use something temporary because most users don't stay 8 hours in a row on the same page (and even if they do, then javascript could retrieve a new token before that deadline)
    Imho that would be a good starting point to improve security, but it requires Bing to add a webservice method to generate tokens and modify the ajax control to use tokens instead of credentials.



    However I may add that after checking the control, the credentials are used for only two things:

        * the Logging service: this is expected

        * the Elevation service: I personally never used it before (and doesn't seem documented either, perhaps it's a new REST service ?) so I'm not sure what this is for even if I have a few theories, but given the proper modifications, it could also be made to work with temporary token if Bing wants to.

    For info, its syntax is:
    http://dev.virtualearth.net/REST/v1/Elevation/BoundingRect/{south},{west},{north},{east}/{rows}/{cols}?key={credentials}

    Active Bing Maps programming community at StackOverflow:

    http://stackoverflow.com/questions/tagged/bing-maps

    Tuesday, December 21, 2010 2:13 PM
  • I think it's unlikely that MS will switch back to a temporary token system, considering they've only just moved from a token system to the current key system!

    Many developers felt that the old token authentication system was cumbersome, and since it required server-side code to generate the token before sending to client-side, it imposed restrictions of the technology stack that could be used to develop Bing Maps solutions. (Requesting the password-protected WSDL token service from PHP is a pain, for example).

    The new "key-only" mechanism is certainly more streamlined - all we're not sure about is whether it even matters whether someone obtains your key or not....


    Beginning Spatial with SQL Server http://www.apress.com/book/view/1430218290
    Tuesday, December 21, 2010 3:27 PM
  • If they were to setup a token generation service, I would think they would provide a REST version like they did for the old SOAP/WSDL counterparts.

    As for being cucumbersome to have an extra step, even if I share the feeling, you might change your mind when a script kiddie steals the key and you receive the bill :/


    Only locking credentials per url would be more hassle than it solves on the other hand: it could still be tricked, plus you'd have to take in account the server-side scripts that also use the same credentials for REST.

    Active Bing Maps programming community at StackOverflow:

    http://stackoverflow.com/questions/tagged/bing-maps

    Tuesday, December 21, 2010 3:42 PM
  • Hi,

    API key tied to domain or URL will not work either. Many sites have several different domains or URL's pointing to it. How would you solve that with unique kyes per domain/URL?

     

    //Thomas

    Saturday, February 26, 2011 4:27 PM