0

I have a WinForms app which interfaces to a website. In the Windows App, users can log into their website account via a SOAP webservice (username/password are sent with each web service call, made over HTTPS). I've been asked to create a button which will log them into the website in their browser, so they don't have to sign in twice if they need to use both the Windows app and the website at the same time.

Is it safe to also a button in the Windows app, which gives them one-click access to the website, by encoding their username and password in the URL? When using HTTPS, I'm not sure if the URL itself is encrypted, or only the request/response traffic. Would it be better to asymmetrically encrypt the user/pass into some kind of login token? And if so, how could I stop someone else from simply using that same token?

I'm not really sure what to Google to get an answer on this one and as changing APIs is relatively difficult once it's in use, I'd rather do something sensible the first time.

NickG
  • 9,315
  • 16
  • 75
  • 115

1 Answers1

1

You could create a token and store this in your database with the username and a "use before" timeout. Then you include the the token in the url, and on the website you lookup in your database verify that the token exists and is connected to a user and is recent.

hans.arne.vartdal
  • 46
  • 6
  • 1
    What is the advantage of using a token over just using the username and password as the token, when the connection is encrypted anyway? I realise token use is quite common but I've never really understood the reasoning behind it :) – NickG May 23 '14 at 09:43
  • With a random token it would be unlikely for anyone to guess a token that could work, especially within the timeout of the token. (You should generate a new token each time). With an encrypted username+password "token" anyone that gets hold of it could use it. Using HTTPS that shouldnt happen, but with the chance of misconfiguration i would rather have a secure mechanism at the solution level. Also, ideally your system should not know the password of the user. It should be stored as a hash, and only used to verify what the user later inputs. A token give you an internal mechanism. – hans.arne.vartdal May 23 '14 at 10:22
  • The system uses hashed passwords, but sending only the hash would allow anyone access knowing only the hash, which is even less secure than requiring them to know the password. So presumably you only mean to use the hash for storage, not for any kind of authentication? – NickG May 23 '14 at 12:08
  • Correct, only for storage. I just think that passing the password around is bad practice regardless. Ideally it should only be hashed and stored when set, and then verified against later. The point would be to send something that expires, so that IF the URL is compromised somehow, it is still not valid. Either because it is too old, or more likely because you already used the token once. If you send the password in the URL, that URL could be used to login until the user changes the password. – hans.arne.vartdal May 28 '14 at 14:05
  • See this for more on how the URL could be compromised, e.g. in server logs: [link](http://stackoverflow.com/questions/2629222/are-querystring-parameters-secure-in-https-http-ssl) – hans.arne.vartdal May 28 '14 at 14:05
  • Thanks! Following your advice I have now implemented a one-time token based system, where a token (GUID) is requested though an SSL API call from the Windows app, then that is valid one-time only (for 30 seconds) and is opened in their default browser to log them in (usually within 1 second). The user doesn't even see the token in the URL as the page instantly redirects, so it works well. That's secure enough for my needs I think. :) – NickG May 28 '14 at 14:11
  • I have accepted your answer and hopefully given you your first stackoverflow points. Welcome :) – NickG May 28 '14 at 14:12
  • Thanks :-) Sounds like a secure enough solution, hope it works out for you! – hans.arne.vartdal Jun 24 '14 at 09:27