Is this a good security strategy?_问答_开发者_运维开发者技术经验分享

I'm trying to make a web service secure.

It's not for a bank or anything of that sort, but the organization using it may lose some money if the service will be used by someone not authorized (it's hard to tell exactly how much..).

The purpose is not to allow unauthorized applications to use any method (other than "GetChallenge". for users authentication there is a different mechanism which checks for username and password. I actually combined the two, but they serve different purposes):

So here's what I do:

I send a (ASP.NET) session key (for everyone to read. ASP.NET's session Is 15 randomly generated bytes, it lives for 20 minutes unless prolonged, and ASP.NET will not receive any request without it).

In my SignIn method, apart from username and password (which anyone can acquire, since it's a part of a public site), I receive a third parameter - the session key hashed by md5 algorithm with 6 bytes as salt.

And only if the hash i开发者_JS百科s correct (I'm hashing and comparing it on the server side) - I let the users sign in.

From then on in every method, I check if the user is signed in.

Added: The username and password are sent as clear text, and that's not a problem (not the one I'm addressing at least). The problem is for someone (other than the company we're working with) writing an application which uses my web service. The web service should only be used by an authorized application.

Also, the session id is sent back and forth with every request and response (as a part of ASP.NET session mechanism. That's how ASP.NET knows to "track" a session specific for a user). Sorry for not clarifying that from the first place.

(irrationally thought it was obvious).

How strong and effective is that security strategy?

Thanks.

Updated based on your edit and comment

It's pretty secure and is very similar to the approach used by Google, Facebook and others for their API keys. Except...

Session ID plain text potential issue

I would recommend against using Session ID as part of a security mechanism.

The one issue is with passing the session key in plain text across the network. There is potential that this could open up some Session hijack and other attacks.

From the Microsoft Docs:

The SessionID is sent between the server and the browser in clear text, either in a cookie or in the URL. As a result, an unwanted source could gain access to the session of another user by obtaining the SessionID value and including it in requests to the server. If you are storing private or sensitive information in session state, it is recommended that you use SSL to encrypt any communication between the browser and server that includes the SessionID.

As you are using the Session ID as part of your security mechanism I would say that is sensitive data.

One way to ensure someone doesn't get hold of your session key is to run your service on HTTPS. Personally I would avoid using the Session ID in this way and generating a non-related value instead.

Recommended change

Follow more closely the model used by Google and the like. Generate a new GUID for each application, store the GUID in a database on the server, pass the GUID in each request to your server from the client.

Benfits:

Identifies the client application uniquely, allowing you to track and manage usage per client nicely
Easily disable any client by removing the GUID from your data store
No sensitive data on the wire

I would still run the service on HTTPS as it's easy to setup and gives the added benefit of protecting any other data you send to your service.

The purpose of encryption is not to allow unauthorized applications to use any method

Wrong. The purpose of encryption it to prevent the understanding of data whilst either in transit or stored. It prevents data being 'useable' by those that do not have the means to decrypt.

What you are describing is something similar to a public/private key system. You're making your session key available to everyone. Then only after they've md5 with the correct salt (as per your server side comparison) you're then trusting that source.

You've got NO authentication here except for username and password. Also your data isn't encrypted during transit. I fail to see how this is at all secure.

I think you're best bet is to use an SSL certificate (so your web service is running over HTTPS) along with the username and password. If you want to be doubly secure you might want to go down the route of checking source IP ranges and login locations as an additional check. Perhaps a forced password change interval will help in the case that consumers are passing credentials to a third party + audit how the web service is actually being used.

As a side note if you want to hash something don't use MD5, its broken.

From a web services perspective the ideal way to use authentication or provide security to your service is something like this: Web Service Authentication (Token and MD5 Hashing to encrypt password).

The way you describe it, it does not seem secure at all.

What is the point of letting the SignIn method accept a hashed session key, if the session key is public ("for everyone to read")?

Plus: "in every method, I check if the user is signed in. " How do you check that?

A common (and reasonably secure) strategy would be to generate a (unique, sufficiently long and random) session ID server-side, and send it to the client after it has authenticated. Then check every client request and only accept it if it contains the session ID. To do this, either embed the ID into all links on every page, or set it as a cookie, depending on what's easier for you. On logout, just delete the session ID on the server.

That way, no one can invoke any method without a valid session.