Date: Thu, 27 May 1999 00:24:26 -0700 From: Lucky Green 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 PGP 5.x encrypted email preferred ---------------------------------------------------------------------------- From: Peter Gutmann To: BUGTRAQ@netspace.org Subject: Re: ICSA certifies weak crypto as secure "Lucky Green" 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 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 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 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 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 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 To: BUGTRAQ@netspace.org Subject: Re: ICSA - Certified Sites and Criteria Issues Lucky Green 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 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 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 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 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 To: InfoSec News Subject: Re: [ISN] ICSA certifies weak crypto as secure Reply From: edison 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]