On Wed, Aug 13, 2008 at 09:58:50AM -0400, Paul Clements wrote:
Wouter Verhelst wrote:
What we came up with is this:
- Server sends a random number as a way to challenge the client for a
password
- Client constructs something based on the IP address, password, and the
random number the server sent, pumps it through a secure hash
algorithm, and sends that back.
- Server constructs the same thing and pumps it through the same
algorithm. If the output matches, we're authenticated; if it doesn't
match, we're not.
Thoughts, anyone?
But why build that into nbd? You can stunnel the nbd connection, and it
takes care of authentication and encryption. And no messy code added to
nbd.
That's a bit of a hack, isn't it? It'd blow up the requirements on the
client side too, which I'm not very fond of (requires libssl and
libwrap, and seems to want some perl stuff, which I don't think can be
done from an initrd). Also, is it possible to run stunnel on the server
side in such a way that it'll accept different authentication for
different ports? After all, nbd-server can serve multiple connections
from the same server process now.
OTOH, I don't think the code for a secure hash function is very hard or
convoluted. I'd obviously ask someone to audit it once I've written it,
just to make sure I've made no errors, but it seems like something that
can be done in less than 100 LOC to me. The current nbd-client is only
358 LOC.