Re: Secure Remote Password...

From: Guy Macon (http://www.guymacon.com)
Date: 11/22/04 

Date: Mon, 22 Nov 2004 16:42:03 +0000

jrv wrote:

>Recently I was nearly sent into cardiac arrest when I discovered
>one [non-profit organization] group had a non-secure website
>whereunder they had a database of plaintext passwords and credit
>card information from contributors.

...

>One of their "system requirements" is that on subsequent visists,
>members should not have to reenter their CC info, but the physical
>security of the server itself is only moderate (...ok, ok ... it's
>actually rather poor).

I have bad news for you. You are hosed. There is no solution.

It is a basic and unchangable fact that any cryptographic solution
fails instantly unless both parties have a secret. (having a shared
secret is the simple solution, but there are private key / public
key systems that don't require the secret to be shared).

In the system you described, the two parties are the member and the
server. If the physical security of the server is poor, then an
attacker can find out any secret that the server holds in it.
Encryption cannot protect that secret, because the encryption needs
a secret, leaving you with the same situation - a secret that the
attacker has access to.

>I thought we might be able to encrypt each credit card with a unique
>encryption key, such that each key can only be recovered for a
>particular session after the user has authenticated themself with ther
>server. (Basically, I'd like the encrypted credit card information to
>be useless to anyone who "stole" the server, without them also having
>each and every member password.)

If you encrypt the credit card number and the user password and the
attacker has the key to that encryption, you are hosed.

>Asking an authenticated user for a second password, so we can
>temporarily decrypt their CC info seems like a klunky solution, but
>with my limited computer security background, it's the only solution
>that seems plausible to me.

It doesn't solve your problem. The server has to know a secret to
decrypt, and the attacker knows that secret.

>Various web searches have led me to a hill of folks selling
>"professional security services", but most of them appear to be
>expensive, "security through obsurity" solutions, which very much
>annoys me... but perhaps that's just because I *am* uninformed on the
>topic...

Your suspicions are well-founded. There are a lot of snake oil
sellers out there. Avioding them is important, but you have to
solve your fundamental flaw of the attacker having the keys to
all of the locks before you start comparing brands of deadbolt.

>Can anyone please suggest whitepapers, RFCs, technologies, or baseline
>implementations of "SRP w/ a payload" (perhaps a 256 bit encryption
>key) that might be of use in helping me to craft a solution for these
>folks. (GNU General Public, or similar, licensing isn't a problem - in
>fact, it's preferred for anything implementation related.)

There are none. Your problem has no solution given your "system
requirements."

You also have an ethical dilema. On the one hand, you have a duty
to the organization to not reveal these problems, but on the other
hand you have a duty to the members to warn them that someone is
storing their credit card number on an insecure system - unless the
organization stops doing that.

I see two solutions to this situation:

[1] Drop the "system requirement" is that on subsequent visits,
    members should not have to reenter their CC info. Put up
    a notice saying that you are doing it to keep their personal
    information secure and few will complain.

[2] Purchase hosting somewhere that has a secure server. Note that
    you don't have to put everything on that secure server, just
    the page that deals with credit card numbers. I realize that
    you think that they cannot afford it, but your really should
    shop around - such services are amazingly cheap.

If anyone thinks that fixing this security weakness is too expensive,
ask them to consider how much it will cost them to have a major
security breach followed by a front-page article in the local
newspaper, followed by a major loss of membership, followed by
still having to pay to fix the security weakness, but having to do
it in a rush - paying rush prices - while being screamed at by the
remaining members.

If I happen to be a member, please delete me from the system. :) 

-- 
Guy Macon <http://www.guymacon.com>