[Parti-discuss] [PATCH] secure password support

[Antoine Martin]

Hi Nathaniel,

Here is an updated password patch.
This should alleviate your fears on what you called "hand-rolled
crypto", as it uses plain HMAC (which also makes the code smaller).

Changes:
* uses HMAC rather than MD5 directly
* deals with short writes to the socket
* stores the password in a text file so that it cannot be snooped from
the process list.

This has the added benefit of allowing us to do things like running xpra
 using the same password file for authentication with Xvnc:
xpra --xvfb-bin="Xvnc -PasswordFile=/path/passwordfile"
--password-file=/path/passwordfile start :10

This obviously requires my previous patch to be merged (the trivial one
allowing "--xvfb-bin" option on the command line).

Cheers
Antoine




Nathaniel Smith wrote:
> 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!
> [...analysis snipped...]
> 
> 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
> somesuch.)
> 
>> 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.
> 
> Cheers,
> -- Nathaniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: password-file.patch
Type: text/x-patch
Size: 7158 bytes
Desc: not available
URL: <http://lists.partiwm.org/pipermail/parti-discuss/attachments/20090728/90c19208/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: <http://lists.partiwm.org/pipermail/parti-discuss/attachments/20090728/90c19208/attachment.pgp>