0
$\begingroup$

I have clients sending data to a server. The data is not encrypted, but that's OK. I want to make sure the server only accepts data from authorized clients.

The server knows all of the clients' passwords. The clients generate a fairly random string (the first 6 characters of a UUID, gotten through the Python uuid.uuid4() function). They do md5(random_string + password), and send this and the random string along with their data. The server takes the random string, the password, and does the md5 itself to verify that the client does indeed know the password.

Is this home-made system adequate? Again, I just want clients to be verified, I'm not worried about encryption of the data.

Improve this question
$\endgroup$
4
$\begingroup$

They do md5(random_string + password), and send this and the random string along with their data.

What would happen if the attacker recorded the above data, and then sent 'md5(random_string + password)', 'random string' (both from the recorded data), and then included their preferred data. The system would check that the random string checks out, and so trust the data.

What I would recommend is something like:

HMAC( random_string, data ), data

(where data would include something that would identify the client, if necessary)

That way, the attacker can't just cut/paste the authentication information; it is a function of the data being authenticated.

BTW: there is no reason to use MD5. The weaknesses known in MD5 do not apply in your case, however that's not a good enough reason to use it; I'd suggest using SHA-256 instead (possibly truncating it if 256 bits is too long)

Improve this answer
$\endgroup$
1
$\begingroup$

One unfortunate property of your scheme, is that the server needs to know your password. That means that the sysadmin knows everyone's password, which is quite a security risk.

I think you can get better security by using a more conventional solution, like TLS and then send your username and password explicitly (but encrypted by TLS). Doing this does NOT require the server to store a list of passwords. I suspect, if you're programming in python, you can do this in a fairly small amount of code.

Improve this answer
$\endgroup$
0
$\begingroup$

You posted that you want authentication and not necessarily encryption. But consider that encryption can ALSO make for authentication. Instead of leaving your data unecrypted, consider TLS or some DH exchange that ensures that not only is your data now safe, it's verified too.

Encrypting a lot of data with PKI will be slow, use something symmetric for the data, private/public to establish that key. Probably don't use PreSharedKey in your scenario. All of these things are built into TLS fwiw.

Don't use MD5, there is just no reason for it. If you JUST need a fast hash, use SHA1/2.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Encryption is often combined with authentication but encryption by itself does not provide authentication; there are numerous Qs on this already. In particular unauthenticated DH can easily be faked. TLS actually has some unauthenticated suites but in practice they aren't used so in practice TLS is authenticated. $\endgroup$ – dave_thompson_085 Oct 27 '17 at 5:24
  • $\begingroup$ For what he's trying to do in closed point-to-point, enc could be auth. He's pretty vague on it, but I promise in ideal-world PSK any message that comes in correctly is going to be authenticated. My point was really to get him to consider encrypting because unenc data is may be unnecessary in his example. $\endgroup$ – mint branch conditioner Oct 27 '17 at 16:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.