icsa.certified.weak.crypto.txt

`Date: Thu, 27 May 1999 00:24:26 -0700  
From: Lucky Green <[email protected]>  
To: [email protected]  
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 <[email protected]>  
PGP 5.x encrypted email preferred  
  
----------------------------------------------------------------------------  
  
From: Peter Gutmann <[email protected]>  
To: [email protected]  
Subject: Re: ICSA certifies weak crypto as secure  
  
"Lucky Green" <[email protected]> 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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
Subject: Re: ICSA - Certified Sites and Criteria Issues  
  
> From: Jon McCown [mailto:[email protected]]  
> 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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
Subject: Re: ICSA - Certified Sites and Criteria Issues  
  
Lucky Green <[email protected]> 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 : [email protected] | Tel (work) : +44 (0)1703 592422 |  
-----------------------------------------------------------------------  
  
----------------------------------------------------------------------------  
  
Date: Fri, 28 May 1999 13:48:30 -0500  
From: Jeremey Barrett <[email protected]>  
To: [email protected]  
Subject: Re: ICSA - Certified Sites and Criteria Issues  
  
On Fri, May 28, 1999 at 11:09:08AM +0100, Simon Liddington wrote:  
> Lucky Green <[email protected]> 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 <[email protected]>  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: InfoSec News <[email protected]>  
Subject: Re: [ISN] ICSA certifies weak crypto as secure   
  
  
Reply From: edison <[email protected]>  
  
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 [email protected] with "subscribe isn".  
Today's ISN Sponsor: OSAll [www.aviary-mag.com]  
  
`