2

so let's say I had a basic socket, doesn't give you any information about the user other than the IP address, what would be my options If I wanted to authenticate a user in the most optimal way possible (as in performant),

I thought of having a small key that I hash the packet with, which could be de-hashed quite fast (I think) - but I don't know how I could securely send that initial key. (Although maybe with a secondary SSL server, which I will have for HTTPS requests)

Edit: More Info, the user authenticates with the HTTPS server first, so a key can indeed be shared securely (with SSL) between the client and the server

Thoughts?

Whiteclaws
  • 333
  • 1
  • 3
  • 6
  • 1
    Problem with this is "dehashing" is not a thing. A hash function is a one-way function which is not trivially reversed. – multithr3at3d Jun 04 '17 at 01:25
  • My bad, thinking about it, I meant deencrypting – Whiteclaws Jun 04 '17 at 02:55
  • I would suggest that if your project isn't just a toy project for your own enjoyment or learning experience, you stop trying to design your own authentication protocol until you have more experience, and let someone who knows this stuff do it for you. From your use of "dehashing" and "deencrypting", I conclude that you don't have much experience with secure protocols, and if you design your own now, you'll probably make stupid mistakes that will render your authentication protocol insecure at best, and useless at worst. – Out of Band Jun 04 '17 at 08:27
  • @Pascal I actually always followed the mantra to "Never do encryption by myself", but if you never do something by yourself, you never learn too, but It is a pet project of mine so it's fine, I'll just accept an answer for now, thanks for sharing the info – Whiteclaws Jun 04 '17 at 17:48

2 Answers2

2

  1. Provide the clients a random key (long-lived, or temporary) in the https sessions. Include the user id in the datagrams (if you don't have it yet). Sign the datagrams with a HMAC algorithm, verify the datagrams HMAC on the server.

  2. Use DTLS.

Miklos Niedermayer
  • 36
  • 1
0

If you already have a shared secret agreed then its not too much of a stretch to use it for encryption rather than signing and get the added benefit of confidentiality. A caveat of using UDP is that, in the absence of reliable delivery you can't use CBC or CFB across datagrams (you can use a per datagram perturbation of a staic initialization vector to avoid the overhead of send a new IV for each datagram).

A small key is one which is easily reversed.

There is an rfc covering ssl over udp (not looked at it in detail, I suspect you'd need to be careful with the throttle rate). A common approach to deal with transmission loss over udp is to use error correction across multiple packets like RAID does with disks.

Using a ssl over tcp channel as a control mechanism seems a sensible approach (but bi-directional comms are not a good fit for http).

The most important question is whether you really need to use udp.

symcbean
  • 18,278
  • 39
  • 73
  • Actually, there are two servers, one http webserver behind a caddy proxy, and my udp server, the server only sends very small packets for realtime games, so the information contained in it doesn't really need to be encrypted or protected, I just need to make sure that it comes from where it says it comes, so that not anybody can come and steal the identity of a connected user, SSL would be overkill for something like this I think, and my application only cares about the latest packets – Whiteclaws Jun 03 '17 at 20:18