Date: Thu, 27 May 1999 00:24:26 -0700
From: Lucky Green <shamrock@NETCOM.COM>
To: BUGTRAQ@netspace.org
Subject: ICSA certifies weak crypto as secure

I am becoming concerned about the apparent lack of professional competence
within even well-known segments of the security community. I hope the
incident I discovered is an isolated one, but even a single such incident is
disquieting.

There is a site that offers credit reports to consumers called
ConsumerInfo.com. https://www.consumerinfo.com

The site owner seems to have tried to do everything right. They joined
TrustE. They had their site certified by ICSA. They clearly have given
security a serious thought. But the company and all its customers were
severely let down by ICSA, since the highly confidential information
submitted by the user to the site is insufficiently "secured" by 40bit TLS.
And it is not as if using 128 bit would have been a challenge. The site uses
IIS and is located in the US. (Not that deploying 40 bit crypto would be
acceptable even outside the US).

I find it frightening to think that somebody calling themselves a security
professional might even consider certifying a site using 40bit SSL to
protect crucial customer information. Especially a site in the financial
sector. Certifying obfuscation as security is an unacceptable level of
performance by any computer security professional.

I would like to be able to blame simple ignorance of crypto for this deed,
which alone would be bad enough coming from a security "professional", but I
am afraid that's not possible since it is inconceivable that the certifying
ICSA member was unaware that 128 bit TLS/SSL is industry standard. Instead,
we must assume that for reasons unknown, but ultimately irrelevant, a
certification was issued for technology the issuer knew to not afford the
customer security or simply didn't bother to check the crypto strength.
Either way this condemns ICSA (a member of the Gartner Group), and reflects
very badly on our industry as a whole.

--Lucky Green <shamrock@netcom.com>
  PGP 5.x  encrypted email preferred

----------------------------------------------------------------------------

From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA certifies weak crypto as secure

"Lucky Green" <shamrock@netcom.com> writes:

>I am becoming concerned about the apparent lack of professional competence
>within even well-known segments of the security community. I hope the
>incident I discovered is an isolated one, but even a single such incident is
>disquieting.

[...]

>I find it frightening to think that somebody calling themselves a security
>professional might even consider certifying a site using 40bit SSL to
>protect crucial customer information. Especially a site in the financial
>sector. Certifying obfuscation as security is an unacceptable level of
>performance by any computer security professional.

I think it's pretty common, in 1997 I heard of Ernst and Young in NZ certifying
40-bit SSL as being secure for banking use.  I mentioned this in a posting to
sci.crypt titled "Crypto for beancounters" and got several responses from
people saying they'd had similar experiences (not necessarily with E&Y, but
with Big 6 firms who did security audits).  The summary of the responses was:

-- Snip --

[...]

- Getting a security system accepted is more likely if it's been reviewed by
  the company auditors, even if the people involved don't have much experience
  with the technology.

- Even if the auditors don't have much crypto experience, they're generally
  very good at finding things like procedural flaws.  Most real systems fail
  because they're not used properly, not because of technical attacks.
  Accountants/auditing firms are very good at finding problems like this.

- Some firms may have experience in auditing crypto, but more importantly they
  should be able to call in outside experts to check the crypto.  Requiring
  that the audit report include details of how the crypto was evaluated and (if
  external experts were used) by who would be a good idea.

In summary use the auditing firm to cover security procedures, but (unless they
have expertise in the area) leave assessment of the crypto software to known
experts in the field and/or insist in seeing details of how the crypto was
assessed.

-- Snip --

It's really just an issue of being able to prove due diligence - all you need
is the right people to check the "Uses encryption" box and you're OK.  Whether
the encryption is any good or not is largely irrelevant, at least for the
purposes of the exercise, which is to pass the audit.

Peter.

----------------------------------------------------------------------------

Date: Thu, 27 May 1999 16:14:17 -0400
From: Jon McCown <jmccown@ICSA.NET>
To: BUGTRAQ@netspace.org
Subject: ICSA - Certified Sites and Criteria Issues

-----BEGIN PGP SIGNED MESSAGE-----

While I am constrained by NDAs from discussing the specific issues of
any particular ICSA customer's security issues or policy, I will
respond "in general" to Lucky Green's posting regarding the use of
40-bit cryptography as part of an ICSA certified configuration.

Participants in our site certification program (TruSecure) are
required to meet in excess 200 criteria elements; covering such issues
as physical security, business continuity, personnel management,
network architecture, patches and updates, privacy, and sensitive
information handling.    Nearly all of the criteria elements are
driven by the customer's security and operational policy-- which is
derived from their business objectives and risk management approach.

The 'specific' criteria elements which govern the use of cryptography
in the context of the customer site are (verbatim):

HUF0007:    The handling procedures, security measures, and
classifications for sensitive information are documented in a
Sensitive Data Policy.   The procedures identified in the policy are
in place.
HUF0014:    The site's Internet Security Policy, as documented on form
TS012.01 - Security Posture and Policy, has been implemented
HUF0027:    If client data is gathered by the target, then the site
must publish online its site visitor privacy, and user data security
policies.
SVC0034:    Sensitive Information, as identified in HUF0007 is
encrypted and uses protocols which are acceptable to both the host and
user.
[in this context the "host" is the site operator and the "user" is
their client base]

In this context  _is_ possible for a customer to mandate (via their
own policy) use of whatever levels of cryptography they view as being
appropriate to their business model and customer requirements.   For
example, if a customer policy specifies 128-bit TLS,
client-certificates, and token-based auth--  they will be validated at
that level.   And if validating the server's identity to the end-user,
or no-hassle compatibility with zillions of consumers' bargain-club-PC
40-bit browsers is a goal-- a different policy might well result.

Yes, we (ICSA Labs) do agree that 40-bit/8-second, and even 56-bit
encryption have become low-hanging-fruit on the confidentiality tree.
 The Gilmore/EFF demonstrations and recent IETF SAG discussions have
put that writing on the wall.   Do we need to add an "appropriate
crypto strength" element to the TruSecure criteria?  Yes I guess we
do.

- - Jon McCown, ICSA Labs



-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5

iQCVAwUBN02nmaN04bWY62GPAQEwwgP/aJLdrxCNRkRJAtp9mdbVb2+tZttwiLbI
77gbVtbyrFG29iqp/qs0zIz4+ZS73+8fGqisaWgFyRiaM1FJhLXyjQbRVrUkAqJq
F/5cTmuTF9DOwsada+l8iq9ZO+VNk2AAo/TJnqaW3Y0/cNn2+XmA3edSgAEydO5D
Ox4VuVRLLCo=
=Mkwn
-----END PGP SIGNATURE-----

----------------------------------------------------------------------------

Date: Thu, 27 May 1999 16:06:17 -0700
From: Lucky Green <shamrock@NETCOM.COM>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

> From: Jon McCown [mailto:jmccown@icsa.net]
> In this context  _is_ possible for a customer to mandate (via their
> own policy) use of whatever levels of cryptography they view as being
> appropriate to their business model and customer requirements.   For
> example, if a customer policy specifies 128-bit TLS,
> client-certificates, and token-based auth--  they will be validated at
> that level.   And if validating the server's identity to the end-user,
> or no-hassle compatibility with zillions of consumers' bargain-club-PC
> 40-bit browsers is a goal-- a different policy might well result.

Now I am really getting worried. From your post it is clear that you, a
representative of ICSA, are unaware that by enabling 128 bit TLS/SSL on a
server you by no means prevent users limited to 40 bit crypto from accessing
it.

Sure, a server can be specifically configured to not allow access by 40 bit
browsers, but the overwhelming majority of 128 bit capable websites support
both 128 and 40 bit crypto and will automatically use the highest strength
supported by the browser. No incompatibility issues are introduced by
enabling full-strength crypto.

The site certified by ICSA did not support 128 bit crypto even to browsers
that support it. Which is, IMHO, unacceptable for a site that had their
security checked by an audit.

--Lucky

----------------------------------------------------------------------------

Date: Thu, 27 May 1999 19:23:19 -0400
From: Russ <Russ.Cooper@RC.ON.CA>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

If ICSA is

"constrained by NDAs from discussing the specific issues of any
particular ICSA customer's security issues or policy"

and

"Nearly all of the criteria elements are driven by the customer's
security and operational policy-- which is derived from their business
objectives and risk management approach."

and you say

"Do we need to add an "appropriate crypto strength" element to the
TruSecure criteria?  Yes I guess we do."

then what, pray tell, should a consumer visiting

https://www.consumerinfo.com/n/security.htm?htm+l

glean from the fact that the page linked on their site from your ICSA
icon contains the following;

"ConsumerInfo.Com employs sophisticated encryption"

and further states;

"In addition to employing these high-security measures, ConsumerInfo.Com
has undergone the rigorous certification process for the International
Computer Security Association's (ICSA) Web Certification program. This
process examined every aspect of our security precautions, encompassing
an on-site inspection of our facility for physical security and policy
plus a remote assessment of our potential vulnerabilities to web-based
attacks. In addition, the ICSA's certification is a continuous process,
repeated several times during the year and renewed annually, so you know
ConsumerInfo.Com's security measures are state-of-the-art."

However, the bottom line is that;

- They are *NOT* employing "sophisticated encryption", they're employing
the least sophisticated deployable.

- They also say ICSA "examined every aspect of our security
precautions", but in fact, you only examined those aspects defined in
their policies.

- They also claim that because of your certification, their customers
"know ConsumerInfo.Com's security measures are state-of-the-art" when in
fact their *NOT*.

I will not, at this time, question the integrity of ICSA. Nor will I
suggest that ConsumerInfo.Com is out and out lying.

I will, however, suggest that ICSA is tacitly allowing ConsumerInfo.Com
to mislead their customers via the ICSA Web Certification approval. By
ICSA not being permitted, by NDA, to discuss certification they have
performed, it renders, IMNSHO, the certification itself *worthless*. It
would appear that ConsumerInfo.Com has been allowed to say anything they
want about their work with ICSA and, by NDA, ICSA cannot rebuke it.

ICSA Web Certification reports should be public, or, not trusted.

Cheers,
Russ - NTBugtraq Editor

----------------------------------------------------------------------------

Date: Thu, 27 May 1999 18:46:47 -0400
From: Adam Shostack <adam@HOMEPORT.ORG>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

You can ISO9001 certify the process of shooting yourself in the foot,
so long as the process is documented and reliably produces the proper
result.

Do you require certified sites post their security policy?  If not,
how do I know that the policy doesn't explicitly accept the presense
of phf in /cgi-bin?  Would it be possible to have that in my policy
and still get certified, if I have good business reasons for putting
it in place?

This flap may be a result of certifying compliance to policy, but the
relying parties on your mark should not be expected to be able to read
and understand those policies; they should be able to rely on your
mark to say that the policies make sense.  Incidentally, do you
require sites to post these policies to which you certify compliance?

I think that the high level message here (and from the
TRUSTe/Microsoft crap) is that what organizations like ICSA and Truste
are certifying is not what people who may be expected to rely on those
marks expect is being certified.

Adam



On Thu, May 27, 1999 at 04:14:17PM -0400, Jon McCown wrote:
| -----BEGIN PGP SIGNED MESSAGE-----
|
| While I am constrained by NDAs from discussing the specific issues of
| any particular ICSA customer's security issues or policy, I will
| respond "in general" to Lucky Green's posting regarding the use of
| 40-bit cryptography as part of an ICSA certified configuration.
|
| Participants in our site certification program (TruSecure) are
| required to meet in excess 200 criteria elements; covering such issues
| as physical security, business continuity, personnel management,
| network architecture, patches and updates, privacy, and sensitive
| information handling.    Nearly all of the criteria elements are
| driven by the customer's security and operational policy-- which is
| derived from their business objectives and risk management approach.
|
| The 'specific' criteria elements which govern the use of cryptography
| in the context of the customer site are (verbatim):
|
| HUF0007:    The handling procedures, security measures, and
| classifications for sensitive information are documented in a
| Sensitive Data Policy.   The procedures identified in the policy are
| in place.
| HUF0014:    The site's Internet Security Policy, as documented on form
| TS012.01 - Security Posture and Policy, has been implemented
| HUF0027:    If client data is gathered by the target, then the site
| must publish online its site visitor privacy, and user data security
| policies.
| SVC0034:    Sensitive Information, as identified in HUF0007 is
| encrypted and uses protocols which are acceptable to both the host and
| user.
| [in this context the "host" is the site operator and the "user" is
| their client base]
|
| In this context  _is_ possible for a customer to mandate (via their
| own policy) use of whatever levels of cryptography they view as being
| appropriate to their business model and customer requirements.   For
| example, if a customer policy specifies 128-bit TLS,
| client-certificates, and token-based auth--  they will be validated at
| that level.   And if validating the server's identity to the end-user,
| or no-hassle compatibility with zillions of consumers' bargain-club-PC
| 40-bit browsers is a goal-- a different policy might well result.
|
| Yes, we (ICSA Labs) do agree that 40-bit/8-second, and even 56-bit
| encryption have become low-hanging-fruit on the confidentiality tree.
|  The Gilmore/EFF demonstrations and recent IETF SAG discussions have
| put that writing on the wall.   Do we need to add an "appropriate
| crypto strength" element to the TruSecure criteria?  Yes I guess we
| do.
|
| - - Jon McCown, ICSA Labs
|
|
|
| -----BEGIN PGP SIGNATURE-----
| Version: PGP 5.5.5
|
| iQCVAwUBN02nmaN04bWY62GPAQEwwgP/aJLdrxCNRkRJAtp9mdbVb2+tZttwiLbI
| 77gbVtbyrFG29iqp/qs0zIz4+ZS73+8fGqisaWgFyRiaM1FJhLXyjQbRVrUkAqJq
| F/5cTmuTF9DOwsada+l8iq9ZO+VNk2AAo/TJnqaW3Y0/cNn2+XmA3edSgAEydO5D
| Ox4VuVRLLCo=
| =Mkwn
| -----END PGP SIGNATURE-----

--
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume

----------------------------------------------------------------------------

Date: Thu, 27 May 1999 15:44:47 -0700
From: David Schwartz <davids@WEBMASTER.COM>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

        So does ICSA certification mean simply that a company has met its own
requirements? (As opposed to some set of objectively validated or
ICSA-imposed requirements?)

        DS

> Participants in our site certification program (TruSecure) are
> required to meet in excess 200 criteria elements; covering such issues
> as physical security, business continuity, personnel management,
> network architecture, patches and updates, privacy, and sensitive
> information handling.    Nearly all of the criteria elements are
> driven by the customer's security and operational policy-- which is
> derived from their business objectives and risk management approach.
[snip]
> In this context  _is_ possible for a customer to mandate (via their
> own policy) use of whatever levels of cryptography they view as being
> appropriate to their business model and customer requirements.   For
> example, if a customer policy specifies 128-bit TLS,
> client-certificates, and token-based auth--  they will be validated at
> that level.   And if validating the server's identity to the end-user,
> or no-hassle compatibility with zillions of consumers' bargain-club-PC
> 40-bit browsers is a goal-- a different policy might well result.
[snip]

----------------------------------------------------------------------------

Date: Fri, 28 May 1999 11:09:08 +0100
From: Simon Liddington <sjl96v@ECS.SOTON.AC.UK>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

Lucky Green <shamrock@NETCOM.COM> writes:

> Sure, a server can be specifically configured to not allow access by 40 bit
> browsers, but the overwhelming majority of 128 bit capable websites support
> both 128 and 40 bit crypto and will automatically use the highest strength
> supported by the browser. No incompatibility issues are introduced by
> enabling full-strength crypto.

In my experience with Netscape and apache-SSL the lowest strength
cipher (apart from no cipher at all) is used. Unless you disable the
weaker ciphers in Netscape, netscape tries them first and will connect
if the server allows them.

Of course this doesn't invalidate your statement that there is no
problem with enabling full-strength crypto, but it does mean there is
also little to gain by doing so.

Simon

--
-----------------------------------------------------------------------
| Simon Liddington                 |                                  |
| E-Mail : sjl96v@ecs.soton.ac.uk  |  Tel (work) : +44 (0)1703 592422 |
-----------------------------------------------------------------------

----------------------------------------------------------------------------

Date: Fri, 28 May 1999 13:48:30 -0500
From: Jeremey Barrett <jeremey@TERISA.COM>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

On Fri, May 28, 1999 at 11:09:08AM +0100, Simon Liddington wrote:
> Lucky Green <shamrock@NETCOM.COM> writes:
>
> > Sure, a server can be specifically configured to not allow access by 40 bit
> > browsers, but the overwhelming majority of 128 bit capable websites support
> > both 128 and 40 bit crypto and will automatically use the highest strength
> > supported by the browser. No incompatibility issues are introduced by
> > enabling full-strength crypto.
>
> In my experience with Netscape and apache-SSL the lowest strength
> cipher (apart from no cipher at all) is used. Unless you disable the
> weaker ciphers in Netscape, netscape tries them first and will connect
> if the server allows them.

A client in SSL sends all its supported ciphers at once, it doesn't "try"
some, then "try" others. The server chooses which cipher to use from amongst
those the client supports. If you have 128-bit capable Netscape, and 128-bit
capable Apache SSL, or a Netscape server, or Stronghold, or whatever, you get
full strength crypto, unless there's a bug in the server.

Obviously if one or the other doesn't support it, you don't.

Regards,
Jeremey.
--
Jeremey Barrett <jeremey@terisa.com>
GPG fingerprint = 7BB2 E1F1 5559 3718 CE25 565A 8455 D60B 8FE8 B38F

----------------------------------------------------------------------------

Date: Fri, 28 May 1999 16:39:03 -0400
From: David Kennedy CISSP <dmkennedy@COMPUSERVE.COM>
To: BUGTRAQ@netspace.org
Subject: Re: ICSA - Certified Sites and Criteria Issues

-----BEGIN PGP SIGNED MESSAGE-----

        I'm taking it upon myself to respond for Jon who's busy trying to
have a life outside the office.  As he did, I'm going to try to steer
clear of a specific discussion of any of our customers.
        We thank the open review process of the total crypto community for
bringing this to our attention.   We will include this discussion in
our ongoing process to maintain the TruSecure criteria.
        I'd like to restate what I feel is the most pertinent criterion that
bears on this issue:  the criterion requires encryption and protocols
acceptable to both the host and the client.  As a practical matter,
for web activity this is either 40-bit SSL or 128-bit SSL.  The
TruSecure customers have the flexibility to choose, and their
customers, in turn, decide if this is "acceptable."
        Clearly, most of the readers of these lists regard 128-bit SSL as the
minimum they would find acceptable.  However I think those same
readers would acknowledge that the majority of users on the Internet
worldwide today are using a 40-bit version of the popular browsers.  A
business has every right to decide if 40-bit SSL is the level of
security they feel is appropriate for the information they are
processing.
        A TruSecure customer may make a business decision that 40-bit SSL is
"acceptable" for the communication of data from their hosts to their
clients.  Once this decision is made, they may configure their systems
for 40-bit only.
        It should be clear from Jon's previous message that, in the abstract,
128-bit SSL is preferable to 40-bit SSL.  However, 40-bit SSL for all
it's faults, protects data in transit from the client to the host from
all but a targeted attack by an experienced, well-resourced adversary.
 40-bit SSL provides superior security than the majority of meatspace
exchanges of sensitive information.

At 07:53 PM 5/27/99 -0400, David Schwartz wrote:
>
>       So does ICSA certification mean simply that a company has met its own
>requirements? (As opposed to some set of objectively validated or
>ICSA-imposed requirements?)

        Certification requires compliance with our criteria.  The best web
page we have describing this is: http://www.trusecure.net/process.html
 If you want the nitty gritty details, browse to
http://www.trusecure.net/
and either go to the library or click the "contact us" link.
        ICSA helps customers address risks across multiple categories
(physical, hacking, malicious code, spoofing, eavesdropping, lack of
knowledge/awareness, lack of trust, DoS, privacy-user by site & data
subject, lack of interoperability).  We developed a methodology to
focus on high risk/cost categories and follow this methodology with
our customers.  When addressing the issue of privacy, ICSA approaches
the matter by addressing the risk of capturing customer information
across the wire and as it resides on the customers server.  We do
require the use of encryption but choose to let the customer to decide
the level based on the assets they are protecting, the impact to their
business, and the fact that the real concern is the data residing on
the server un-encrypted.  ICSA therefore works with our customers to
set up multiple layers of synergistic controls that not only address
the use of encryption but also those mentioned above.
        We rely on addressing our customers' issues not only from a
technology perspective, but from a business level one as well.  When
deploying security, ICSA will always address how technology impacts
our customers operations and costs.

At 07:31 PM 5/27/99 -0400, Adam Shostack wrote:
>Do you require certified sites post their security policy?  If not,
>how do I know that the policy doesn't explicitly accept the presense
>of phf in /cgi-bin?  Would it be possible to have that in my policy
>and still get certified, if I have good business reasons for putting
>it in place?
>

        For the purposes of site certification we would not certify a site
with phf in the cgi-bin directory.  Our criteria do restrict this.
However, we have customers who have purchased TruSecure but have "good
business reasons" for ignoring or violating one or more of our
criteria.  ICSA has a process to review these occurrences and have
withheld certification from some of these customers.  Indeed, we have
customers who are quite satisfied with their TruSecure purchase
without achieving certification.  Without turning into a
sales/marketing droid, we try to emphasize TruSecure as a process to
provide acceptable security to the customer; many customers are
satisfied without completing certification and know this before their
purchase.

>This flap may be a result of certifying compliance to policy, but the
>relying parties on your mark should not be expected to be able to read
>and understand those policies; they should be able to rely on your
>mark to say that the policies make sense.  Incidentally, do you
>require sites to post these policies to which you certify compliance?
>

        Certified sites must post a privacy and user data security policy as
part of our criteria.  We do not require the site to post their
security policy.  Most enterprises would be reluctant to post an
un-santitized version of their security policies which opens the
question of how much sanitization is necessary or desirable.  I don't
believe it would be wise to require they post the nitty gritty details
of their policies.  One would not want details such as these widely
known:

        Inbound telnet is blocked except from IP xxx.xxx.xxx.xxx to
yyy.yyy.yyy.yyy which is permitted so Y Inc can review progress
reports on Project Z.
        Employees assigned to our office in Sri Lanka will use PPTP to host
at zzz.zzz.zzz.zzz to access the company intranet.

At 07:36 PM 5/27/99 -0400, Russ wrote:
>However, the bottom line is that;
>
>- They are *NOT* employing "sophisticated encryption", they're employing
>the least sophisticated deployable.
>

        I can't respond to this directly.

>- They also say ICSA "examined every aspect of our security
>precautions", but in fact, you only examined those aspects defined in
>their policies.

        For any customer, we examine every aspect defined by *our* criteria,
which includes examining their security policies and implementations,
but these two aspects are but a handful of the 200+ criteria we
include in TruSecure.

>
>- They also claim that because of your certification, their customers
>"know ConsumerInfo.Com's security measures are state-of-the-art" when in
>fact their *NOT*.

This issue is with the semantics on a page not maintained by ICSA.

>
>I will not, at this time, question the integrity of ICSA. Nor will I
>suggest that ConsumerInfo.Com is out and out lying.
>
>I will, however, suggest that ICSA is tacitly allowing ConsumerInfo.Com
>to mislead their customers via the ICSA Web Certification approval.  By
>ICSA not being permitted, by NDA, to discuss certification they have
>performed, it renders, IMNSHO, the certification itself *worthless*.  It
>would appear that ConsumerInfo.Com has been allowed to say anything they
>want about their work with ICSA and, by NDA, ICSA cannot rebuke it.
>

        The way this paragraph is constructed makes it impossible to respond
to it.  We would like to respond, and explain how certification is not
as you say, "worthless," but to do so would be to reveal confidential
information about a customer.

At 07:36 PM 5/27/99 -0400, Lucky Green wrote:
>
>Now I am really getting worried. From your post it is clear that you, a
>representative of ICSA, are unaware that by enabling 128 bit TLS/SSL on a
>server you by no means prevent users limited to 40 bit crypto from accessing
>it.
>

        Incorrect, we understand this fact.
        Again, the criteria require encryption and protocols acceptable to
both the host and the client.  Popular browsers provide the capability
for users to click on an icon and determine the encryption being used,
if any.  Undoubtedly that's how this thread started.


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.0.2

iQCVAwUBN07+V/GfiIQsciJtAQECrgQA3IsyfP6AEWV4OarIG5xs46sIWP/IdSYQ
sWvEYaENjbFdyu8tOH2hq5y1bm9/ALM8nITz94zYs/kZupJ2XZR5GYFhOpyfbG2v
4qzL1pml8Ht2aKsJ+r6Ghf9cp2qOfCejigSWcHTfRLNhgoI2u1CL6G6ua3OkDBS8
5KVOeNhwDK0=
=GqTy
-----END PGP SIGNATURE-----

Regards,
David Kennedy CISSP
Director of Research Services, ICSA Inc. http://www.icsa.net

Using encryption on the Internet is the equivalent of arranging
an armored car to deliver credit-card information from someone
living in a cardboard box to someone living on a park bench.
                      Gene Spafford

----------------------------------------------------------------------------

Date: Fri, 28 May 1999 20:08:35 -0600 (MDT)
From: cult hero <jericho@dimensional.com>
To: InfoSec News <isn@repsec.com>
Subject: Re: [ISN] ICSA certifies weak crypto as secure 


Reply From: edison <edison@dhp.com>

A few thoughts on the subject. 

First, with the frightening amount of completely unsecured consumer info
sites on (and off) the net today, I would disagree that ICSA's actions
reflect "very badly" on our industry.  Because there are much easier
targets, consumerinfo.com can be resonably certain that it won't even be
attacked for quite some time.  At least until most of the rest of the
sites are secure in the same fashion. 

Don't get me wrong, I'm not advocating 40-bit encryption as 'secure,' but
it is 'more secure' than nothing at all.  And until the ingorant IT
managers with sites on the net clue in, this kind of certification won't
_hurt_ our industry.  Please don't attack me - I'm just saying that while
we professionals might recognize weaknesses in this level of security,
those outside don't and "we" still look good to them. 

Second, if you've every been to a hacker BBS/site, you have to know that
getting into Equifax or any other reporting agency is pitifully easy.  If
you think 40-bit encryption is weak, how about a 2 character alphanumeric
"password" on accounts that can be pulled from your own credit report? 
And for that matter, there are posted algorithms to the account scheme, so
you can even generate your own. 

I will agree that there are more unsavory characters on the net than there
are people aware of CBI dialups.  But then again, 40-bit crypto is not
exactly _easy_ to crack. 

-edison

On Fri, 28 May 1999, cult hero wrote: 

> I am becoming concerned about the apparent lack of professional competence
> within even well-known segments of the security community. I hope the
> incident I discovered is an isolated one, but even a single such incident
> is disquieting.

-o-
Subscribe: mail majordomo@repsec.com with "subscribe isn".
Today's ISN Sponsor: OSAll [www.aviary-mag.com]