0

I have a program that opens a web browser control and just displays a web page from our server. They can't navigate around or anything.

The users are not allowed to know the credentials required to login, so after some googling on how to log into a server I found this:

http://user_name:password@URL

This is 'hard coded' into the web browsers code. -It works fine.

HOWEVER: Some smart ass managed to grab the credentials by using WireShark which tracks all the packets sent from your machine.

Is there a way I can encrypt this so the users cannot find out?

I've tried other things like using POST but with the way the page was setup, it was proving extremely difficult to get working. -(Its an SSRS Report Manager webpage)

I forgot to include a link to this question: How to encrypt/decrypt the url in C#

^I cannot use this answer as I myself am not allowed to change any of the server setup!

Sorry if this is an awful question, I've tried searching around for the past few days but can't find anything that works.

Community
  • 1
  • 1
  • 1
    You should look into some sort of Token based authentication. Basically the place that calls the url would create a token and then the end point would pick up the token from the url cross reference with some sort of Database/Service and then complete the login. The token should be destroyed after use and a unique one should be created for each request. – Tony Jun 12 '14 at 14:28
  • 1
    Sweet jesus, what an awful idea. Don't blame the guy that discovered the flaw, if anything he did you a favour. – DGibbs Jun 12 '14 at 14:28
  • I know he did me a favour, thats why I'm trying to fix it? –  Jun 12 '14 at 14:32
  • 1
    [SSL](http://en.wikipedia.org/wiki/Secure_Sockets_Layer) is the only way data on the wire can be encrypted. Wireshark is listening at a transport (the **t** in TCP/IP) level so you'd need to encrypt all of this level, which only SSL can do. This will need to be configured on the server though. – Liam Jun 12 '14 at 14:51
  • However you authenticate (e.g. doing what you are currently doing or using a cookie or using a token in HTTP headers and so on) you'll want to use SSL (ahem TLS) as @Liam suggests. Not using TLS leaves you wide open to tools like wire shark and any kind of man-in-the-middle attack (MTM), regardless of how you authenticate. – Jeremy Cook Jun 12 '14 at 16:06

1 Answers1

1

Perhaps you could work around your issue with a layer of indirection - for example, you could create a simple MVC website that doesn't require any authentication (or indeed, requires some authentication that you fully control) and it is this site that actually makes the request to the SSRS page.

  • That way you can have full control over how you send authentication, and you need never worry about someone ever getting access to the actual SSRS system. Now if your solution requires the webpage to be interactive then I'm not sure this will work for you, but if it's just a static report, it might be the way to go.

i.e. your flow from the app would be

  • User logs into your app (or use Windows credentials, etc)

  • User clicks to request the SSRS page

  • Your app makes an HTTP request to your MVC application

  • Your MVC application makes the "real" HTTP request to SSRS (eg via HttpClient, etc) and dumps the result back to the caller (for example,it could write the SSRS response via @HTML.Raw in an MVC View) The credentials for SSRS will therefore never be sent by your app, so you don't need to worry about that problem any more...

Just a thought.

Incidentally, you could take a look here for the various options that SSRS allows for authentication; you may find some method that suits (for e.g Custom authentication) - I know you mentioned you can't change anything on the server so I'm just including it for posterity.

Stephen Byrne
  • 7,400
  • 1
  • 31
  • 51