Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

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

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

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 m

Re: encrypted tapes

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 ke

Re: encrypted tapes

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 g

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

[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

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

[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. --

Re: AmEx unprotected login site

"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

Re: AmEx unprotected login site (was encrypted tapes, was Re: Papersabout"Algorithm hiding" ?)

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 cluele

Re: AmEx [add: and other] unprotected login site

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 CitiGro

Re: encrypted tapes

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 "

Re: AmEx unprotected login site

> 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 directed to a site they don't > rec

Re: AmEx unprotected login site

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

Re: encrypted tapes

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

Re: AmEx unprotected login site

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 o

Re: AmEx unprotected login site

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 si

Re: de-identification

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

Re: AmEx unprotected login site

"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

Re: AmEx unprotected login site

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 n

Re: AmEx unprotected login site

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 t

Re: encrypted tapes

>- 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

Re: encrypted tapes

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 s

Re: AmEx unprotected login site

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 protect

Re: encrypted tapes

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

"Retailers Experiment With Biometric Payment" article

From : "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

Re: "Retailers Experiment With Biometric Payment" article

On Thu, Jun 09, 2005 at 11:17:59AM -0400, Heyman, Michael wrote: | From | : | share its biometric data with government agencies, and | in fact, the full fingerprints are not stored in the | system.

Re: "Retailers Experiment With Biometric Payment" article

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

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

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 a

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

On Thursday 09 June 2005 16:41, you wrote: > 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. Wit

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

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

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

> 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 database

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

> [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

Re: encrypted tapes (was Re: Papers about "Algorithm hiding" ?)

> [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