Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

migrated from Aug 19 '12 at 19:17

This question came from our site for professional and enthusiast programmers.

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 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
@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 Information Security - I think you'd get a better picture there! – AviD Aug 18 '12 at 19:39
@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
@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

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. – Maarten Bodewes 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? – Maarten Bodewes Aug 18 '12 at 19:55
How would it be posible for to retrieve the string? – D-32 Aug 18 '12 at 20:20

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


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