In comp.security.misc Pete Finnigan <pete_at_peterfinnigan.demon.co.uk> wrote:
> Hi
> have a look at DbEncrypt by Application Security Inc, in New York,
> Aaron, Eric and the guys have produced a good encryption tool that uses
> modern algorithms rather than DES and they have key hiding built in.
> have a look at their site http://www.appsecinc.com/products.
Key management is a far more importent issue the DES or not DES.
Before this discussion starts mentioning products, have a look
at the "snakeoil warnings article" periodically posted on comp.crypto
Then a lot of "products" become rather pale :-)
> HTH
> Pete Finnigan
> www.pentest-limited.com
> In article <MPG.16359497ef9d8196989688_at_west.usenetserver.com>, Gilbert
> W. Pilz Jr. <gilbert.pilz_at_e2open.com> writes
>>In article <3bcbee48$0$225$ed9e5944_at_reading.news.pipex.net>, n-
>>litchfield_at_audit-commission.gov.uk says...
>>> <pelln_at_icke-reklam.ipsec.nu.invalid> wrote in message
>>> news:9qemfv$nqf$2_at_nyheter.crt.se...
>>> > In comp.security.misc NetComrade <andreyNSPAM_at_bookexchange.net> wrote:
>>> > > We are planning to store credit card #'s in our database..
>>> >
>>> <snip>
>>> > The better method is : Don't try to obfuscate credit card info. MOVE IT
>>> > to a safe server.
>>> >
>>> > If a machine is exposed to Internet ( or other security hazards) it's
>>> > unwize to have any sensitive information on-line.
>>>
>>>
>>> This raises the question of how on earth do you conduct online commerce. Is
>>> it just impossible? If you are using an RDBMS to drive your ecommerce site
>>> then it has to have a communications channel to the internet site, though of
>>> course that channel should be secure etc. Maybe this is a FAQ on
>>> comp.security.misc but it isn't on the Oracle NG.
>>
>>The commonly accepted way of doing this is with two firewalls, a web
>>server, an application server, and a database server. The web server
>>sits in the DMZ where it is accessible to the public. Requests are
>>routed from the web server to the app server where they are carried out
>>by whatever you use to implement your business logic. Database reads and
>>writes are performed by the app server code against the database server.
>>If you think carefully about security (authenticate at the web server,
>>authorize at the app server and database server, and configure your
>>firewalls correctly (amazing how many people never do the last)) through
>>all these layers you can put up a pretty good defense.
>>
>>As for encrypting the information in the database; by all means do so.
>>Use a modern algorithm (I.e. not DES). Do not, repeat DO NOT put the
>>key/passphrase anywhere on any disk on any system. Program your app
>>server to prompt for the key on startup (don't use the command line
>>because something like of a 'ps -ef' will reveal the key). Program the
>>whole system so that, periodically during maintenance windows, you can
>>change keys and re-encrypt the entire database.
>>
>>If you do at least this much it will be enough to send the idiots away
>>in search of easier pickings. The smart and determined are another
>>matter . .
>>
>>
> --
> Pete Finnigan
> IT Security Consultant
> PenTest Limited
> Office 01565 830 990
> Fax 01565 830 889
> Mobile 07974 087 885
> pete.finnigan_at_pentest-limited.com
> www.pentest-limited.com
--
Peter Håkanson
IPSec Sverige (At the Riverside of Gothenburg, home of Volvo)
Sorry about my e-mail address, but i'm trying to keep spam out.
Remove "icke-reklam"and "invalid" and it works.
Received on Tue Oct 16 2001 - 06:23:08 CDT
