On Tue, Aug 12, 2008 at 05:29:51PM -0300, Wouter Verhelst wrote: > On Tue, Aug 12, 2008 at 11:10:14AM -0700, qm <Brad Allen wrote: > > couldn't as easily steal or modify runnable data. To make it > > really secure, nbd-server ought to have a password settable in the > > config file that nbd-client must use, which it requires upon > > negotiation. > > I completely agree. It's been on my TODO list for a few years (with > dreams of adding Kerberos support, too), but just hasn't happened yet. > There're a few reasons for that: > - First, I want to keep nbd-client as small as possible, so that it'll > fit on embedded devices and in initrds and such; so using a (possibly > huge) library to implement password authentication is out, unless it > can optionally be disabled; this rules out things like SASL and > Kerberos if they're the only thing we're going to use. > - Second, I do /not/ want to send passwords across the wire in the clear > in any case. Doing this will only provide a false sense of security, > and I don't want to do that in any case. > - Third, so far I just haven't had the time to properly work out a > solution that satisfies both of the above constraints.
Actually, come to think about it, one advantage of being at a conference like Debconf is that you can ask people around you to help brainstorming. 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. Doing a checksum isn't usually an insanely expensive operation, and can probably be done in a reasonably small amount of code, thereby not enlarging nbd-client too much. Anyone writing this will have to learn such an algorithm first, obviously; or alternatively, if we can find a small library somewhere that will do such checksums _only_, we may consider including that as a build requirement. I'm specifically not considering openssl here, which takes about half a meg and may be too much for embedded things or initramfses on memory-constrained systems. This principle is reasonably future-proof; if the particular checksum protocol we choose ever goes the way of MD5 (which people are now able to construct a collision for in minutes on a laptop, according to wikipedia), we can replace the checksum algorithm but keep the same principle. The IP address requirement is included as a simple MITM protection. Of course this doesn't make NBD safe for eavesdroppers (no encryption, so anyone with a sniffer between client and server can map out the entire contents of the block device, given time), but at the very least it will prevent unauthenticated access. Thoughts, anyone? -- <Lo-lan-do> Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Nbd-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/nbd-general
