[Parti-discuss] [PATCH] secure password support
njs at pobox.com
Thu Jun 18 01:51:14 PDT 2009
On Mon, Jun 15, 2009 at 12:02 AM, Antoine Martin<antoine at nagafix.co.uk> wrote:
> Nathaniel Smith wrote:
>> On Sun, Jun 14, 2009 at 8:42 AM, Antoine Martin<antoine at nagafix.co.uk> wrote:
>>> This patch implements secure passwords authentication (I believe - can
>>> someone please check!)
>> Well, that's the problem with hand-rolled crypto -- it's mostly
>> impossible to check...
> Hard but not impossible!
Well, I meant what I said :-). I actually have a fair amount of crypto
expertise. The sad thing about crypto expertise is that you learn a
whole bunch of cool things, and then you can't actually do anything
with it, because the more you study the more you realize that the
*only* way to write working crypto designs is to (1) be one of the
best people in the world at this stuff, AND (2) convince all the other
best people in the world to spend a few years analyzing your design.
They're still finding design flaws in *ssh*, for crissakes.
So maybe this design is fine, but the problem isn't just making
something that works, it's being confident that we can stand by it and
support it. I don't see any problems in your analysis, but that
doesn't convince me that there aren't any. I need a really good reason
to take that risk. (Plus, how do I know that the next person won't
want even more assurances, like encryption or MITM protection or
whatever? That will *definitely* spiral out of our ability to get
right. And that also means that whatever reason is given needs to
explain why we need a simple ad-hoc password scheme AND NO MORE.)
>> Technically, the patch looks reasonable enough, and things like the
>> short write issue are fixable.
> I'm curious, can you suggest how?
> Without adding a whole lot of code that is... I was trying to keep it small.
It's just a little loop like
written = 0
while written < len(data):
select.select(, [sock], )
written += sock.write(data[written:])
(though of course it's better to wrap this in a utility function)
>> I'm *really* nervous, though, about getting into the secure connection
>> business. That's an impossibly difficult problem, and it's one that's
>> already solved -- just use ssh. So I'm reluctant to accept any patches
>> along these lines without, at the least, specific use cases and clear
>> argumentation for why this approach is the most appropriate way to
>> handle those use cases. Can you provide such?
> I think I can. I've got Windows boxes on the LAN, these will not have
> openssh or plink installed.
plink is trivial to install (literally: "click 'Save link as...',
done"). Hardly noticeable compared to installing the rest of xpra
(which is much less trivial).
> Another use case would be anonymous sessions (ie: locked down guest)
> where you want to allow access from remote hosts without giving them
> full ssh access. (it may also be do-able by setting their login shell to
> an xpra wrapper, but that's just too limited and nasty)
This seems like a very specific and somewhat odd use case -- is this
actually something you are planning to do for real?
(Note also that it's trivial to configure ssh so that when a certain
key is used it will automatically spawn some particular program rather
than give general shell access -- google "ssh restrict commands" or
> BTW, I'm even trying to build the xpra server for win32 now, any ideas
> where I could find one that builds/works??
> (and the machines that will run it will definitely not be running
> openssh server but will still require authentication of some sort)
Cygwin comes with an openssh service. You may well want to run xpra
under cygwin anyway (that'd be the simplest way to get the named pipe
support that xpra assumes!), so installing cygwin may not be an extra
burden at all. And if you must start running a new network-accessible
service on this machine, you should trust openssh a heck of a lot more
than any code that we throw together ourselves.
More information about the Parti-discuss