OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Jeff Williams _at_ Aspect (_at_)
Date: Tue Aug 27 2002 - 12:46:18 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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?

    --Jeff

    Jeff Williams
    Aspect Security, Inc.
    Securing the Last Mile of the Internet
    www.aspectsecurity.com

    ----- Original Message -----
    From: "Kris Kirby" <kriscatonic.net>
    To: "Jeff Williams" <jeff.williamsaspectsecurity.com>
    Cc: <secprogsecurityfocus.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
    > attack.
    >
    > --
    > 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
    >