>Ok, got your point on encryption algorithms.  Public encryptions scare me,
>as at least they offer hints on to how they're done, making TRUE hackers
one
>step closer to knowing where to look to find the key, or what the basis of
>the algorithm is.

Wrong.

You can think about what makes a good encryption scheme as:

Give everybody the plans to your encryption method.
Give everybody the means to use your encryption method.

If they can't break your encryption even if they know all this, then you've
come up with a (somewhat) secure scheme.


>However, before getting overly complicated, you could at least do some
level
>of your own encryption without a lot of research that would prevent the
lazy
>hacker from just ripping off your credit card numbers.  Splitting them in
>two tables is not all that difficult to figure out.

NEVER EVER make your own ecryption scheme.  How is a half-assed encryption
scheme better than no encryption at all (and trust me, NO ONE on this list
could even make a half-assed encryption scheme, let alone something that was
solid)?  And are you hoping that only "lazy" hackers attack your system?

>If someone wants them
>bad enough, they're still going to get them... Having access to your
>database is one thing, getting access to your encryption code, even if it
is
>very basic is at least one larger step towards deterrence.

If you encryption is "basic" then a hacker won't need your encryption code.
Brute-force attack will decrypt it in a manner of seconds.

You're missing the point of encryption.  Yes, all encryption schemes are
breakable.  It's how long it takes to decrypt it before the encrypted
information becomes useless.  If it takes a hacker 100 years to decrypt your
CC numbers, you're doing fine, because all the users of those credit cards
will be dead and hence those CC numbers will be invalid.

>As far as CFENCRYPT, I meant public in the fact that you can use CFDECRYPT
>to decrypt the values.

All good encryption schemes have their method of decryption as public.  All
bad encryption schemes have their method of decryption as private.

-Bill
brainbox

----- Original Message -----
From: "Dave Watts" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Sunday, January 27, 2002 1:18 PM
Subject: RE: Best way to store credit cards in database?


> > Roll your own encryption. I remember awhile back some
> > posted their algorithm for encryption in CF, and it
> > seemed pretty solid. If you use your own encryption
> > scheme, it would be a lot harder for a hacker to decrypt
> > the CC number.
>
> Yikes! I'd strongly recommend against writing your own encryption
> algorithms, unless you're Bruce Schneier or the like. A good,
> publicly-examined algorithm is your best bet. There's a reason why the
> government takes so long to approve an encryption algorithm - public
> examination by experts is the best way to find flaws within the algorithm.
>
> Here's a good quote on the subject:
> http://www.counterpane.com/crypto-gram-9810.html#cipherdesign
>
> > Using a public standard (like cfencrypt) is not a
> > very good solution.
>
> The problem with CFENCRYPT isn't that it's a public standard, but rather
> that it uses a relatively weak encryption strength (that, along with the
> fact that the key is probably stored somewhere within the application code
> or environment).
>
> Dave Watts, CTO, Fig Leaf Software
> http://www.figleaf.com/
> voice: (202) 797-5496
> fax: (202) 797-5444
>


______________________________________________________________________
Get Your Own Dedicated Windows 2000 Server
  PIII 800 / 256 MB RAM / 40 GB HD / 20 GB MO/XFER
  Instant Activation � $99/Month � Free Setup
  http://www.pennyhost.com/redirect.cfm?adcode=coldfusionb
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to