[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real
problem
| is the key handling (how to make sure the DBA can't get the key,
cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax or the like to see if the
[EMAIL PROTECTED] wrote:
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax
On Fri, Jun 10, 2005 at 01:11:45PM -0400, [EMAIL PROTECTED] wrote:
| Ben Laurie wrote
| Sure, but Equifax should.
|
| No, they shouldn't! If you think they should, you are missinformed. At
| least in Canada, the Privacy Act protects the SIN, Equifax cannot demand
| it.
| See for example
|
[EMAIL PROTECTED] wrote:
Ben Laurie wrote
[EMAIL PROTECTED] wrote:
Example:
Cash_Ur_check is in the business of cashing checks. To cash a
check,
they ask you for sensitive information like SIN, bank account number,
drivers licence number, etc. They use the information to query
Equifax
Jerrold Leichter [EMAIL PROTECTED] writes:
They also sold a full solution for encrypted Ethernet - KDC, encrypting
Ethernet adapters, associated software. None of this stuff went anywhere.
People just weren't interested.
That wasn't quite the case for the Ethernet encryption. What happened
On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote:
Yes, encrypting indexed columns for example is a problem. But if you
limit yourself to encrypting sensitive information (I'm talking about
stuff like SIN, bank account numbers, data that serves as an index to
external databases and are
On Wed, 8 Jun 2005, David Wagner wrote:
[...]
That said, I don't see how adding an extra login page to click on helps.
If the front page is unencrypted, then a spoofed version of that page
can send you to the wrong place. Sure, if users were to check SSL
certificates extremely carefully, they
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real problem
| is the key handling (how to make sure the DBA can't get the key, cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the key
From: Charles M. Hannum [EMAIL PROTECTED]
I can name at least one obvious case where sensitive data -- namely credit
card numbers -- is in fact something you want to search on: credit card
billing companies like CCbill and iBill. Without the ability to search by
CC#, customers are pretty
On Thursday 09 June 2005 17:37, Charles M. Hannum wrote:
If we assume that the last 4 digits have been exposed somewhere -- and they
usually are -- then this gives you at most 38 bits -- i.e. 2^38 hashes to
test -- to search (even a couple less if you know a priori which *brand* of
card it
On Wednesday 08 June 2005 21:20, [EMAIL PROTECTED] wrote:
Yes, encrypting indexed columns for example is a problem. But if you
limit yourself to encrypting sensitive information (I'm talking about
stuff like SIN, bank account numbers, data that serves as an index to
external databases and
[EMAIL PROTECTED] wrote:
| Oracle, for example, provides encryption functions, but the real
problem
| is the key handling (how to make sure the DBA can't get the key,
cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the
[EMAIL PROTECTED] writes:
I saw allot of requirements by security auditors that looked pretty
silly.
Must use 128-bit RSA encryption has to be the all-time favourite.
One I saw recently was a requirement for using X9.17 key management... in
SSL.
Peter.
One of my favourites was that PINs
Perry E. Metzger wrote:
Have a look, for example, at
http://www.americanexpress.com/
which encourages users to type in their credentials, in the clear,
into a form that came from lord knows where and sends the information
lord knows where. Spoof the site, and who would notice?
Every company
Steven M. Bellovin wrote:
The bigger issue, though, is more subtle: keeping track of the keys
is non-trivial. These need to be backed up, too, and kept separate
from (but synchronized with) the tapes. Worse yet, they need to be
kept secure. That may mean storing the keys with a different
Perry wrote:
In case you think the answer is regulation, by the way, let me note
that most of the regulatory pressure I've seen on security policy
results in people finding extremely well documented ways to do exactly
what the regulators ask, to no actual effect. This is generally
because the
On Wed, Jun 08, 2005 at 01:33:45PM -0400, [EMAIL PROTECTED] wrote:
|
| Ken Buchanan wrote:
| There are a number of small companies making products that can encrypt
| data in a storage infrastructure, including tape backups (full disclosure:
| I work for one of those companies). The solutions
2) The cost in question is so small as to be unmeasurable.
Yes, because key management is easy or free.
Also, reliability of encrypted backups is problematic: CBC modes render
a single fault destructive to the entire dataset. Counter mode is
sufficiently new that it's not supported by
| Oracle, for example, provides encryption functions, but the real problem
| is the key handling (how to make sure the DBA can't get the key, cannot
| call functions that decrypt the data, key not copied with the backup,
| etc.).
| There are several solutions for the key management, but the
Ben Laurie writes:
Why is it bad for the page to be downloaded clear? What matters is the
destination is encrypted, surely?
Because the page you downloaded in the clear contains the https: URL
in the post method. How do you know that this is the right URL? If
you got the page in the clear, you
In message [EMAIL PROTECTED], Perry E. Metzger writes:
The truth is, the likely reason no one encrypted the data on the tapes
in transit was because no one thought to do it, or they were too lazy
to bother to make even the simplest effort, or both.
I don't completely agree. While I suspect
On Tue, Jun 07, 2005 at 07:48:22PM -0400, Perry E. Metzger wrote:
It happens because some idiot web designer thought it was a nice
look, and their security people are too ignorant or too powerless to
stop it, that's why.
It has nothing to do with cost. The largest non-bank card issuer in
Steven M. Bellovin wrote:
The bigger issue, though, is more subtle: keeping track of the keys is
non-trivial. These need to be backed up, too, and kept separate from
(but synchronized with) the tapes. Worse yet, they need to be kept
secure. That may mean storing the keys with a different
24 matches
Mail list logo