[CUWiN-Dev] Proposed Nodeconfig Change

[Matthew Isaacs]

On Wed, 2007-08-01 at 00:25 -0500, David Young wrote:
> On Tue, Jun 19, 2007 at 05:00:16PM -0500, Matthew Isaacs wrote:
> > On Tue, 2007-06-19 at 17:35 -0400, Paul A. Kennedy wrote:
> > > On Jun 19, 2007, at 5:13 PM, Joshua King wrote:
> > > 
> > > > I think that this would be a good idea. There is nothing keeping us  
> > > > from
> > > > having the configuration on the testbed builds be different than  
> > > > the one
> > > > on the public sourceforge builds. As Matt said, those builds are
> > > > necessarily insecure, and the most important thing is to make them  
> > > > easy
> > > > to use so people can fiddle with them more easily. Plus, it would get
> > > > more much-needed usability testing for nodeconfig.
> > > 
> > > Exactly who are we targeting here?
> > > 
> > > Do we want people who don't know the basics of using ssh to be  
> > > responsible for making network security decisions?  Wouldn't we  
> > > prefer them to read the man page for ssh rather than consider network  
> > > topology and security?
> > > 
> > > I think not knowing how to use ssh is a fine barrier to entry.
> > > 
> > > Paul
> > > 
> > > --
> > > Paul A. Kennedy
> > > pakenned at pobox.com
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > CU-Wireless-Dev mailing list
> > > CU-Wireless-Dev at lists.cuwireless.net
> > > http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev
> > 
> > We're talking folks who simply download the public flash images or
> > ISO's, and boot them up, and don't bother doing their own build.
> > Without doing their own build, all the system passwords are the defaults
> > specified in the documentation.  As such, the system is insecure, and
> > someone wishing to wreak havoc with/on such a node would only need to
> > ssh using the default root password.  This presents a much more
> > interesting security hole for a potential hacker than a web gui that
> > only allows someone to configure a predetermined set of options.
> > 
> > I agree that this solution is not suitable in a production environment,
> > however one would hope that no one is using the public images in such a
> > manner, due to the password and other security issues.
> 
> Sorry I am so late to respond.
> 
> I think that we need to move away from distributing software with
> passwords set to well-known defaults.  For many demo purposes, nobody
> needs to know any password at all.  For users who do want to admin their
> own node, but who do not want to build their own image, we need a secure
> web site that they can visit to get their own SSH/web admin password.
> CUWiN will assign some random password or, if they don't trust us, let
> them provide their encrypted password.  When the web site has their
> encrypted password, it will provide them a unique URL where they can
> download the image they desire for a limited time.
> 

I've been working on something similar to this.  My point was that
without such a mechanism, why bother securing the web interface on an
image where every other password is freely available?


> The web interface on nodes really needs some authentication and privacy.
> We can put the same certificate on each node in a network, and then we
> can give that certificate to every admin for that network, but if any
> node is ever compromised, then we cannot trust the certificate any more.

> These days there are cheap ICs that contain some "write-only" memory for
> a secret and an engine for producing SHA-1 message digests.  After you've
> programmed the secret, you can write a bit string to the IC and it will
> "mix" the string with the secret, compute the SHA-1 hash of the mixture,
> and write it back to you.  Maxim/Dallas makes a few such ICs---for
> example, the DS2704.  If somebody gets hold of a node containing one
> of these, they can produce hashes using that particular physical IC,
> but it will be tremendously difficult for them to replicate the IC or
> its secret for reuse, quite unlike a certificate.  I'd like to explore
> the use of these ICs for authentication of nodes to nodes and nodes to
> admins at CUWiN.
> 

An interesting idea.  Wouldn't it be possible to wire one of these in on
the GPIO lines on nodes that have those available?  Especially since
this particular chip sports the Dallas 1-wire interface?

> Dave
>