William Leader wrote
> 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.
Hey Will, Chris here;
The issue with this would be replay attacks, where an attacker is
able to recreate the environment in which a encrypted message is
created. The issue with this is that an attacker would know roughly
what time the packet was created. Because K2W is open source the
random generator algorithm is known. Recreating the packet would be
trivial using a range of seeds (time) from when the communication
was intercepted. Your random number generator seed, even if you use
SSL, should be based on the entropy of the machine and not based on
time.
I'd suggest something like this:
seed = CPU usage + num_seconds_from_bootup + memory_usage_in_bytes
+ mouse_velocity
or maybe just ask the user to slam on their keyboard with their
elbows
Funny story along this line... A real security guru teacher I had
taught a Secure Communications class in my college. I was in his
class. Our assignment was to write a Public/Private key system then
decrypt a message he signed using his public key. As a joke he bet
us $1 USD that no one could find out his Private key. Well, one
student actually did! What happened was the teachers signed message
had a timestamp on it. The student used a replay attack using the
Java randomizer and a range of times close to the timestamp as the
seed. The student found out that the java randomizer was seeded at
exactly 36 seconds before the message was created. The dollar bet
was paid.
Chris