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
Perry E. Metzger [EMAIL PROTECTED] writes:
Steven M. Bellovin [EMAIL PROTECTED] writes:
They're still doing the wrong thing. Unless the page was transmitted
to you securely, you have no way to trust that your username and
password are going to them and not to someone who cleverly sent you an
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
Perry: I share your feelings in this matter, great message (but I made
some comments, see below). I'll appreciate the relevant Verizon URL so
I'll add them to the Hall of Shame. Notice I already have several banks
there, including Chase (which you also mentioned), and brokers,
including
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
Few comments on what Ivars Suba wrote:
How to fight against phishing in organization enviroment?
Quite easy- put SSL termination Proxy between client browser and SSL
server:
Sure, but:
1. This doesn't have any effect on non-SSL-protected sites (e.g.
AmEx,... see `Hall of Shame`). And of course
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
Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
They're still doing the wrong thing. Unless the page was transmitted
to you securely, you have no way to trust that your username and
password are going to them and not to someone who cleverly sent you an
altered version of
Ivars Suba responded to me:
1. This doesn't have any effect on non-SSL-protected sites (e.g.
AmEx,... see `Hall of Shame`). And of course assumes users will notice
the use of non-SSL-site...
Vowww.. I didn't know that AmEx is not ssl protected ;))
Before user credentials are passed to
On Jun 8, 2005, at 15:19, [EMAIL PROTECTED] wrote:
I'd like to come up to speed on the state of the
art in de-identification (~=anonymization) of data
especially monitoring data (firewall/hids logs, say).
I don't know the state of the art, but I can tell you the state of the
artless. I had a
R. Hirschfeld [EMAIL PROTECTED] writes:
From: Perry E. Metzger [EMAIL PROTECTED]
Date: Wed, 08 Jun 2005 19:01:37 -0400
The other major offender are organizations (such as portions of
Verizon) that subcontract payment systems to third parties. They are
training their users to expect to be
Ben Laurie [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
They're still doing the wrong thing. Unless the page was transmitted
to you securely, you have no way to trust that your username and
password are going to them and not to someone who
Perry E. Metzger wrote:
Ben Laurie [EMAIL PROTECTED] writes:
Perry E. Metzger wrote:
Steven M. Bellovin [EMAIL PROTECTED] writes:
They're still doing the wrong thing. Unless the page was transmitted
to you securely, you have no way to trust that your username and
password are going to
- 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
Perry E. Metzger wrote:
When I go to the SSL protected page, I can look at the URL and the
lock icon in the corner before typing in my password.
Bless you for being so careful. I, instead, look at the logo of the site
and of the CA as displayed in TrustBar. This is much easier, and
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
http://www.washingtonpost.com/wp-dyn/content/article/2005/06/08/AR20050
60802335_pf.html:
You can always get a new Social Security number, but
you certainly can't get a new thumbprint..., Lee [of
EFF] said...Robinson, of BioPay, argues that a personal
check written at a grocery
On Thu, Jun 09, 2005 at 11:17:59AM -0400, Heyman, Michael wrote:
| From
| http://www.washingtonpost.com/wp-dyn/content/article/2005/06/08/AR20050
| 60802335_pf.html:
| share its biometric data with government agencies, and
| in fact, the full fingerprints are not stored in the
| system.
On Thu, Jun 09, 2005 at 12:02:20PM -0400, Adam Shostack wrote:
Has anyone ever studied the reversability of these algorithms? It
seems to me that you could make some plausible guesses and generate
fingerprints from certain representations. I don't know how likely
those guesses are to be
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
29 matches
Mail list logo
