1

I'm wondering if I have a web service like this:

Login(username, password)

or a page like 

login.aspx?u=username&p=pass

If they were called from a desktop app, which would be more secure. From what i've read a sniffer can read the request and figure out the url. I AM hashing the passwords before putting them in the request, but if someone sees the request url with the params/query string then they can make the request with the same values!?

How easy/hard is it for a sniffer to figure out the hashed password? Should I encrypt the password and username before putting it into the url and web service? Any other options I have?

I'm asking because the data is NOT all that sensitive but basic security should exist at a minimal performance cost

NOTE: SSL is NOT an option

gideon
  • 19,329
  • 11
  • 72
  • 113

3 Answers3

1

Just use HTTPS to encrypt the channel. That way you don't have to worry about sniffers.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • Sorry I didn't mention this earlier My clients(a bank) have decided specifically NOT to use SSL because: 1.Data is NOT all that sensitive 2.App is hosted on LAN (access to LAN is secured itself) 3.Users are bank staff. – gideon Aug 29 '10 at 22:08
1

Use SSL to create a unique session token via a login service. Use that session token over standard HTTP for the rest.

Your login session will need to take the username/password as a POST otherwise the values will be visible in the URL request to the server and possible snooping on the network.

Paul Alexander
  • 31,970
  • 14
  • 96
  • 151
  • Hi Paul, Could you please elaborate a little bit more on how I would create a unique session token? Thanks – gideon Jan 11 '11 at 03:55
  • Remember, my client doesn't care all too much for the security if their data, so *they* won't buy any SSL or install it on their machines. Could I use some kinda of encryption, I'd like to keep it simple since the data it not all that important. – gideon Jan 11 '11 at 04:02
  • If your client doesn't care about the security of their data - then you need to convince them how wrong they are and to purchase a SSL certificate. If they won't pony up for that, then there's no reason to do any security at all. – Paul Alexander Jan 11 '11 at 16:39
  • The unique session token works just like your normal authentication solutions. You have a log in service that expects a username and password. If the credentials match, you generate a random token and pass that pack to the client. That token is good for a given amount of time - perhaps a sliding window of activity. On subsequent requests, you pass just the token. At the server you validate that the token is valid (ie matches some security hash or exists in the Session). – Paul Alexander Jan 11 '11 at 16:41
  • Security token is part of the hash algorithm. That should add an extra layer of security - but still needs to be implemented well. – nick Jan 16 '11 at 15:42
0

If you're working with a bank, you may be obliged to use SSL. Check your local legislation - I think this will also determine what is sensitive data.

nick
  • 1,477
  • 2
  • 20
  • 29