Mon Oct 10 16:46:27 CEST 2005
rbt <rbt at athop1.ath.vt.edu> writes:
> > Instead, for client #i, let that client's key be something like
> > hmac(your_big_secret, str(i)).digest()
> > and the client would send #i as part of the string.
> How is this different from sending a pre-defined string from the client
> that the server knows the md5 hash of? The clients know the string, the
> server knows the hash of that string.
I'm confused, I don't understand what that md5 whatever would do for you.
I'm assuming the server is secure and the clients are less secure.
> Also, could this not be done both ways? So that, if an attacker figures
> out the string he's supposed to send from a client to the server (which
> he could easily do). He could not easily figure out the string the
> server should send back as all he would have is the hash of that string.
I'm still confused, are you now trying to prevent the client from
accepting bogus stuff from the server? You can do that with a digital
signature and not need client-side secrets. But I still don't see
much gain from that.
> So, before the actual data is sent from the client to the server. The
> client would send it's secret string that the server would verify and
> then if that worked, the server would send its own secret string that
> the client must verify. We'd have two secret strings instead of one.
If the client is insecure, an attacker who gets control of it will get
all the secrets in it, so it doesn't matter if there's one or several.
> Nothing important. It just logs network data. It's an anti-theft program
> for laptops that phones home data like this: public and private IP(s),
Yeah, if a laptop is stolen and the thief is sophisticated enough to
go finding the authentication keys inside some binary, s/he also won't
be dumb enough to leave the program active. Those programs are just
for dumb thieves (of whom there are a lot) or their customers, who
simply plug in the laptop and start using it, without concern about
what software is on it. If they have any sense they'll do a total
But anyway, yeah, people who enroll in the system should get a
customer number. Then you can derive an auth key from the customer
number as described earlier.
More information about the Python-list