I think you mis-understood the question posed by klode ... he
indicated that he had no idea to implement, and was simply asking *IF*
something would work. As indicated by his post, he acknowledged that
it would probably break design goals.
Yes, it is important to understand the inherent risks to providing a
false sense of security. Manuel has stated time and again that he
would *NOT* apply any form of encryption to the passwords that would
ultimately be transmitted in the clear. It is crucial to know the
risks associated with the config.xml so as to better understand why it
needs to be protected.
There is an argument to be had for klode's idea. If the passwords were
encrypted and decrypted in memory as necessary, then it would be a bit
safer from the perspective of a compromise. At least this way, if
someone were to get a copy of the config.xml, not only would they
*NOT* get the passwords, they would also *NOT* get an easily
decryptable hash either, as the password locations in the config.xml
would be empty and filled in memory at runtime ...
To answer klode's question will require someone with a greater
understanding of the inner workings of m0n0wall than me. I can not
think of any non-technical reasons that it wouldn't work, in fact I
can think of several "good" reasons to try something like this.
However, that does not mean I would endorse doing this against
Manuel's stated objections.
IF, and this is a big IF, someone wanted to experiment with this
concept, for the educational benefit that could be gained, then
potentially a "module" or "plug-in" could be fielded to those willing
to experiment with it.
As for the fact that someone with a simple sniffer could still get the
passwords, that is true already. I firmly believe that if you have
someone on your network running a sniffer, then you have bigger
problems than whether or not your broadband password is obfuscated by
Just my $0.02 on the subject.
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
> 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
> 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?
> 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
Failure is not an option ... it comes bundled with your Micro$oft solution!