[ previous ] [ next ] [ threads ]
 
 From:  "John ." <jvoigt at gmail dot com>
 To:  Claude Morin <klodefactor at gmail dot com>
 Cc:  Paul Rae <PRae at aminocom dot com>, m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] feature request (hidden and encrypted passwords/pre-sharde keys)
 Date:  Sat, 7 May 2005 23:04:19 -0400
I'm sure that if you're that worried about security that you already
have PGP or some other package that can encrypt your backup copies of
config.xml.  Also, there is other info in there besides passwords that
you would want kept secure.

Anyway, I'd bet that most people haven't even taken a backup of their
config.  They just type it in again if they manage to lose it.

On 5/7/05, Claude Morin <klodefactor at gmail dot com> wrote:
> Sorry if this sounds a bit argumentative, but it's a bit late so I'm in a
> hurry. This is just for the sake of discussion...
> 
> I can think of three places that DynDNS, PPP, etc. passwords need to be
> protected: on the m0n0wall, in backup copies of config.xml, and when they're
> used by the relevant protocol.
> 
> I'll assume the m0n0wall gets it right :-), and the protocols can look out
> for themselves. That leaves only backup copies of config.xml, and a local,
> secret password could protect those passwords.
> 
> I agree that security through obscurity doesn't provide any real security at
> all. There are two things I don't understand so far in this discussion:
> 
>    - why opening another line of attack (via cleartext passwords in file
>    backups of the configuration) is a good way to avoid giving people a false
>    sense of security.
>    - why people shouldn't take responsibility for understanding how
>    protocols work.
> 
> -klode
> 
> On 5/7/05, Paul Rae <PRae at aminocom dot com> wrote:
> >
> > No all it would do is give a false sense of security. No matter how you
> > encrypt / obfuscate it on the box, it needs to be sent clear when its used.
> >
> > All it would take is a simple sniffer and you would get it.
> >
> > Its wrong to give people a false sense of security.
> >
> > -----Original Message-----
> > From: Claude Morin [mailto:klodefactor at gmail dot com]
> > Sent: Thu 05/05/2005 23:48
> > To:
> > Cc: m0n0wall at lists dot m0n0 dot ch
> > Subject: Re: [m0n0wall] feature request (hidden and encrypted
> > passwords/pre-sharde keys)
> >
> > [Sorry to resurrect this, but I have a kooky idea. I have no illusions
> > about
> > implementing it, it's more intended to nail down my understanding of this
> > issue.]
> >
> > Is it possible that the problem with this discussion is that everyone
> > assumes some sort of fixed obfuscation algorithm in the m0n0wall sources?
> > Instead, couldn't an installed m0n0wall store a secret key that is
> > notincluded in the
> > config.xml file? The secret would be set from the physical console menu,
> > and
> > stored elsewhere in the installed m0n0wall image.
> >
> > Whenever DynDNS or PPP or anything else needs a password, the local secret
> > key would be used to decrypt (in memory only) the appropriate
> > config.xmlentry.
> >
> > As I said, it's a kooky idea and probably breaks a bunch of design goals,
> > but would it work?
> >
> > -klode
> >
> > On 4/21/05, Chris Buechler <cbuechler at gmail dot com> wrote:
> > >
> > > On 4/21/05, Christoph hanle <christoph dot hanle at leinpfad dot de> wrote:
> > > > Neil A. Hillard schrieb:
> > > > >>i think it is no good solution, that in the webgui and the
> > config.xml
> > > > >>the passwords for ppoe etc. and the pre-shared-key are always in
> > > > >>cleartype visible; the admin password is hidden or encrypted
> > > > >>respectively. Imho is this a big problem with the security.
> > > > > Try:
> > > > >
> > > > > http://www.m0n0.ch/wall/docbook/faq-plaintextpass.html
> > > > >
> > > >
> > > > Thx, i have overlooked this part, but i think it might be possible to
> > > > encrypt/decrypt these passwords for example against the
> > admin-password.
> > > > And in the web-gui you can use the "hidden" tag.
> > > > but i still think, this is a big security hole, that should be fixed.
> > >
> > > It can't be fixed. Any "fix" would be nothing more than obfuscation.
> > > Creating a false sense of security is worse than making it clear there
> > > should be *no* sense of security.
> > >
> > > That FAQ explains why very well.
> > >
> > > -Chris
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > >
> >
> >
> 
>