Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Jeff Williams _at_ Aspect (_at_)
Date: Tue Aug 27 2002 - 12:46:18 CDT
Interesting. Two responses to my idea (user inputs "secret" into web
application when it starts). One suggested that having someone enter a
password is too restrictive, because it would require someone to enter the
password after every reboot. The other implies that it is not secure
enough, because the password could get swapped out to disk.
Let's assume for a moment that we want to store some encrypted content that
only the web application can read. There are certainly many reasons someone
might want this -- not the least of which is storing passwords (Please note
that you can't hash them if you have to answer people's 'forgot my password'
requests). Anyway, we have to put the key (or password to unlock the key)
somewhere. So how do we protect the secret?
1) If we hardcode the secret, we're asking for trouble since the code might
get disclosed somehow. The risk here is much greater if the code is
embedded in HTML and interpreted (a la JSP, ASP) as the code is more likely
to be disclosed through some web server hole (e.g. .htr+). But it is
certainly easy enough to find a secret in compiled code as well, assuming
you could get a hold of the executable.
2) We could store the secret in a file on the server somewhere, but web
server misconfigurations and web application holes might make it
discoverable. I don't think any amount of encrypting with other keys or
other shell games make any difference here.
3) We could store the secret on another server somewhere, but ultimately
that boils down to another shell game. Anywhere we put it that is accessible
to the web application is accessible to an attacker. If we protect the other
server with passwords or encryption, then that's the secret you have to
store somewhere on your server.
I think the security benefit of not having the secret stored anywhere but in
memory is significant (despite the possibility of being swapped out). The
alternatives seem pretty dangerous to me. Does the benefit outweigh the
burden of having an administrator initialize the web application by typing
in a password each time the web app is started? (Note that this could be
done remotely via an authenticated webpage over SSL). Are there other
options here I'm missing?
Aspect Security, Inc.
Securing the Last Mile of the Internet
----- Original Message -----
From: "Kris Kirby" <kriscatonic.net>
To: "Jeff Williams" <jeff.williamsaspectsecurity.com>
Sent: Tuesday, August 27, 2002 9:19 AM
Subject: Re: Encryption approach to secure web applications
> On Fri, 23 Aug 2002, Jeff Williams wrote:
> > I've been thinking about a scheme where an administrator has to enter a
> > password for a master key when the web server starts up. That key would
> > only reside in memory and would be difficult for an attacker to get to.
> > Then you've got a secret that can be used to encrypt and decrypt other
> > keys and passwords as necessary. Thoughts?
> Unless you can come up with a fail-safe way of making certain that there
> is *no* *possible* *way* that the page of memory holding said keys/secrets
> can be swapped to disk in the event of heavy activity or a bombarding
> Kris Kirby, KE4AHR <krisnospam.catonic.net> TGIFreeBSD IM: 'KrisBSD'
> "BIG BROTHER IS WATCHING YOU!"
> This message brought to you by the US Department of Homeland Security