Tell me more ×
IT Security Stack Exchange is a question and answer site for IT security professionals. It's 100% free, no registration required.
up vote -1 down vote favorite

I have a client and a server. The client makes a request containing userId, cardId, position (on the card)

A hacker could just do the same http request with the next position. So I think about creating a hash for the data. Using plain MD5 won't be enough.

Would it be secure enough to have some salt added? Like md5(userId + cardId + position + "a very long random string")?

share|improve this question
It all depends. Exactly what attacks are you trying to prevent, and how do you discern a "real" user with non-malicious intent from a "hacker" (who could very well be a real user) with malicious intent? – Matt Ball Aug 18 '12 at 17:10
I think you might want to ask this on crypto.stackexchange.com Also, you should consider the fact that md5 is vulnerable to collision attacks, so it won't matter if you salt it or not, an attacker could efficiently brute-force it. I guess SHA512 is a better alternative. – Mihai Todor Aug 18 '12 at 17:11
1  
@D-32, your previous comment is wrong, and does not take into account the possibility of malicious users, aka "hackers". In order to find a proper security solution, you must take into account the full risk profile - e.g. it is possible for an attacker to fake messages to the server, or intercept valid messages from the app. I suggest you move this question (ask a moderator) to IT Security - I think you'd get a better picture there! – AviD♦ Aug 18 '12 at 19:39
1  
@D-32 But what would happen if someone increments the position? And why does the client needs to remember this position and why doesn’t the server do it? – Gumbo Aug 18 '12 at 19:49
1  
@D-32 But why does the client need to provide this position parameter anyways? And what happens when he is able to provide another valid position value? – Gumbo Aug 18 '12 at 20:01
show 4 more comments

migrated from stackoverflow.com Aug 19 '12 at 19:17

2 Answers

up vote 1 down vote

If you generate the random string on the client then you cannot compute the same hash. If you do it on the server then you have to send it ti the client. So this scheme won't work by itself.

If you distribute the salt (more or less a symmetric key) with the application then you can easily retrieve it from the client code. You are better off to send an RSA public key with your application and encrypt the password with it. However you might as well create an SSL session from the client and be much more sure you are safe.

It's more something for crypto, but you are better off using a scheme that includes SSL as performing any scheme without at least server authentication and key agreement/secure messaging will likely fail...

share|improve this answer
The problem is the server needs the same random string, otherwise it can't check that the message + hash has been generated by the client-application. I just thought I could hardcode that String into both applications? – D-32 Aug 18 '12 at 18:26
Ammended answer. The string would be easily retrievable by anyone using the application. – owlstead Aug 18 '12 at 19:26
May I ask how that would be possible? – D-32 Aug 18 '12 at 19:53
Which part? The SSL part or using a public key? – owlstead Aug 18 '12 at 19:55
How would it be posible for to retrieve the string? – D-32 Aug 18 '12 at 20:20
show 2 more comments
up vote 0 down vote

No. Salt is not an authenticator. Salt is not a secure way to authenticate requests from the client.

A more complete answer is: You should back up, and do a requirements analysis and a risk analysis. Figure out what your security goals are, and what the threat model is. What resources are you protecting? What kinds of attacks might someone have an incentive to mount? Once you've been able to think that through, then you can start thinking about a particular mechanism.

At present, you do not seem to be able to give a clear description of what you are trying to accomplish. Therefore, the question is ill-posed and you are not likely to receive a good answer.

With such sparse information, the best advice I can give you is: use SSL (https). While I cannot be sure, due to the sparsity of the information give -- it sounds like you are probably reinventing the wheel, and probably poorly. Also, I recommend that you store state information on the server side, rather than storing it on the client and trusting the client to be honest about reporting the current state (after all, a malicious client can always lie -- a md5 hash does not prevent that).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.