[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
On 6/8/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote:
-+--
| If you have no other choice, pick keys for the next five years,
| changing every six months, print them on a piece of paper, and put it
| in several safe deposit boxes. Hardcode
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
On Wed, 8 Jun 2005, Perry E. Metzger wrote:
Dan Kaminsky [EMAIL PROTECTED] writes:
2) The cost in question is so small as to be unmeasurable.
Yes, because key management is easy or free.
In this case it is. As I've said, even having all your tapes for six
months at a time use the same key
On 6/8/05, [EMAIL PROTECTED] (Perry E. Metzger) wrote:
If you have no other choice, pick keys for the next five years,
changing every six months, print them on a piece of paper, and put it
in several safe deposit boxes. Hardcode the keys in the backup
scripts. When your building burns to the
[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
Ken, you are correct (see below). And in fact, if the page came from the
right source (as validated by SSL and a secure browser extension such as
TrustBar), I don't think there is any need to validate the source (which
is impractical even for the geekest geek). After all, if a site is so
From: Perry E. Metzger [EMAIL PROTECTED]
It is worse than that. At least one large accounting company sends new
recruits to a boot camp where they learn how to conduct security
audits by rote. They then send these brand new 23 year old security
auditors out to conduct security audits, with
On Wed, 8 Jun 2005, Perry E. Metzger wrote:
Dan Kaminsky [EMAIL PROTECTED] writes:
Yes, because key management is easy or free.
Eh - my experience is that that is where 99% of the cost is - in the whole
human procedures and vetting around it. The paper work, the auditing,
dealing with
- you must prove it before you can report it
I don't think this is a good policy in general. Often, it's more
cost-effective to fix a potential vulnerability than to investigate it
in detail, construct a proof that it's real, and fix it. This is
especially true in environments where changes
On Thu, Jun 09, 2005 at 08:57:51AM +0100, [EMAIL PROTECTED] wrote:
|
| From: Perry E. Metzger [EMAIL PROTECTED]
|
| It is worse than that. At least one large accounting company sends new
| recruits to a boot camp where they learn how to conduct security
| audits by rote. They then send these
I spent several years as such a security auditor for PwC. While yes, they
do hire a bunch of kids out of MBA school they also have extremely
experienced senior managers supervising them.We always delved into
business processes as well as using off the shelf tools. Invariably I
would find
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
Ben Laurie [EMAIL PROTECTED] writes:
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,
james hughes [EMAIL PROTECTED] writes:
There are large institution with 1000s of tape drives and 1,000,000
or more cartridges. Even simple solutions are huge to implement. This
is a non-trivial matter. The technical solutions are possible, there
are vendors out there that are already doing
Amir Herzberg wrote:
3. They did not actually spell out the problem in using SSL in the
homepage (like eTrade, for instance). But I think I know the reason
(they didn't confirm or deny). I think the reason is that they host
their site; in particlar, when I tried accessing it via https, I got
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
[EMAIL PROTECTED] writes:
One thing that irritates me is that most security audits (that verify
compliance with regulations) are done by accountants. No disrespect for
accountants here, they are smart people, but most of them lack the
security knowledge needed to really help with the
| Perry makes a lot of good points, but then gives a wrong example re Amex site
| (see below). Amex is indeed one of the unprotected login sites (see my `I-NFL
| Hall of Shame`, http://AmirHerzberg.com/shame.html). However, Amex is one of
| the few companies that actually responded seriously to my
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
Dan Kaminsky [EMAIL PROTECTED] writes:
2) The cost in question is so small as to be unmeasurable.
Yes, because key management is easy or free.
In this case it is. As I've said, even having all your tapes for six
months at a time use the same key is better than putting the tapes in
the clear.
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
39 matches
Mail list logo
