[MUD-Dev] TECH: Securing Symetric Encryption.

[William Leader]

Crowder, Brian wrote:

> Storing keys on the client in general is a bad idea as you will
> inevitably be disassembled and hacked.  Once your keys are known,
> man-in-the-middle attacks are trivially easy.

> A better suggestion for passwords etc. is to use a one-way hash.
> You can look at how the linux passwd code works for an example of
> that.

> If you need things that the client can send and only the server
> can recieve, PKI should be adequate, and all you should need in
> terms of "key management" is to build the server's public-key into
> the client.  This prevents man-in-the-middle attacks, but doesn't
> really stop people from emulating your client protocol.

> If you need more than this, it gets a lot more interesting.  :)

Thanks Brian,

Since my project is an open source effort it does change the rules a
little over a commercial product. I for one would be thrilled if
someone wrote an alternative client for the system. (I'm actually
going through the effort to document the protocol as it evolves on
the project website, but that is besides the point.)

One of the things I was thinking since writing that email, was that
the server never sends the password to the client, and passwords is
the only thing I am securing. So I did consider that the client
would send a login packet to the server using the service public
key, the trouble is that the encrypted packet would be the same
every time, so an attacker wouldn't even need to decrypt the packet,
they could just send the captured data as is. What is needed is
something to make the login packet different every time. This is why
I wanted to come up with a way to send a client a random key each
session.

A second method I considered was adding expiration data to the login
packet, that would change depending on when it was sent. This would
mean that if an attacker captured a login packet, it would only be
suitable for use for a very short time before it changed again. Of
course the attacker would know this, and could grab it, and
instantly send a change password packet. (but that wouldn't work
because a change password packet would be encrypted too.) So This
does limit the damage to that a fast moving attacker could steal the
login packet, send it instantly and log on as the victim. That could
be enough to rob the victim. The other problem is that this only
works if the client and server can agree on what time it is, so
there will be login problems with users who can't figure out how to
set a clock. (or I will have to instruct the server to tell the
client what time it is.)  But even still they are vulnerable for a
short period of time after sending.

This is why I keep going back to the Symmetric system I outlined
originally, because if it is stolen, it can't be used without
cracking it. Or at least that is what I was trying to confirm.

-William Leader
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev