Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…
Net-net, just in case you've been in a coma or something: PDF format used to black out portions of the classified report on the Nicola Calipari/Giuliana Sgrena incident; Italian newspaper (Corriere Della Sera) recovered and posted the classified text by performing a "copy and paste" operation on the blacked-out sections. Story here: http://it.slashdot.org/it/05/05/01/1314216.shtml?tid=172&tid=103 COTS strikes again. The main risk is in using something you don't understand. Another risk is in having allies whose press is eager to publish information which will endanger your troops.
Time Warner Inc. data on 600,000 current and former employees stored on computer backup tapes was lost by an outside storage company. The Secret Service is now investigating. The tapes included names and Social Security information on current and former Time Warner employees, dependents, and beneficiaries, back to 1986. http://money.cnn.com/2005/05/02/news/fortune500/security_timewarner/index.htm?cnn=yes [See also http://www.nytimes.com/2005/05/03/business/media/03warner.html?th&emc=th http://finance.lycos.com/home/news/story.asp?story=48820133 In addition, the *Wall Street Journal*, 3 May 2005, noted that the tapes were lost by Iron Mountain Inc., a data-storage company based in Boston. An Iron Mountain spokeswoman said this is the fourth time this year that Iron Mountain has lost tapes during delivery to a storage facility. PGN]
An agency that warns Texans not to share personal information with strangers because of the risks of identity theft mistakenly mailed hundreds of driver's licenses to the wrong people. The Texas Department of Public Safety (DPS) blamed the mixup on a malfunctioning machine that was recently installed to sort licenses for mailing. Statewide, at least 500 to 600 people who applied for a license renewal or replacement in late March or early April instead received somebody else's card, said DPS spokesperson Tela Mange. A driver's license contains enough personal information for thieves to open up a line of credit or a bank account in that name, make long-distance phone calls or apply for a Social Security card, according to the Texas attorney general's office. Information on the license includes a full name, signature, birth date, height, eye color, address and a photograph. The driver's license number, assigned by DPS, is also used by many agencies to verify a person's identity. In the case of the mismailed licenses, no identity theft or other crime has been reported, Mange said. [Source: *Knight Ridder Tribune*, 26 Apr 2005] http://www.kansascity.com/mld/kansascity/news/nation/11497175.htm (registration required) Peter Gregory, CELLULARONE, Western Wireless Corporation Bellevue, WA 425-586-8386 CISSP, CISA, Information Security Analyst
National Public Radio's Morning Edition included a report this morning that an accused murderer using an alias had been stopped and fingerprinted three times, but IAFIS (the FBI's Integrated Automated Fingerprint Identification System) didn't match his fingerprints to those on file under his real name. After the first false positive, it added his fingerprints to the database using his alias, and subsequent matches turned up the alias rather than his real name. Based on the news report, there seems to be an assumption among the public that IAFIS is 100% accurate, with 0% false negatives (the failure this time) and 0% false positives (where someone is inaccurately accused of a crime). IMHO, this isn't a case so much of technology failure, as it is of unrealistic expectations of technology. http://www.npr.org/templates/story/story.php?storyId=4631503&sourceCode=RSS Also in the *Atlanta Journal Constitution* http://www.ajc.com/metro/content/metro/0505/04jones.html (free signup required). [He was already wanted on charges of rape, sodomy, and jumping bond, and now has been charged with three subsequent murders and suspected of another. See an article by Ellen Barry and Jenny Jarvie, *Los Angeles Times*, 5 May 2005] http://www.latimes.com/news/nationworld/nation/la-na-killer5may05,0,7657766.story?coll=la-home-nation
In RISKS-23.84, Ed Taft <email@example.com>, Principal Engineer at Adobe, and a respected Adobe spokesman on standards and security issues, expressed skepticism about the security, reliably, and user-friendliness of the RSA SecurID, the one-time password (OTP) token that E*TRADE Financial is distributing to customers to enhance the security of their online market trades, and the privacy and integrity of E*TRADE's brokerage records. Subsequently, in RISKS-23.85, Jon Lewthwaite <JLewthwaite@passgo.com>, offered the Adobe exec the vigorous if convoluted endorsement of an RSA competitor, while Kurt Raschke <firstname.lastname@example.org>, a Baltimore high school student, tech editor of the Towson High "Colophon," reacted to Mr. Taft's complaints with wry insight. "Ed raises these issues as though E*TRADE is the first company to ever implement SecurID," wrote a bemused Raschke, "but in reality they are not very grave issues, and many government labs and other organizations find SecurID to be a very good security method despite them." Mr. Raschke, a teenager who develops open-source projects on SourceForge, turns out to be a veteran sysop, quite familiar with SecurID and practical security issues. By contrast, Mr. Taft, one of the architects of Postscript and PDF, reacted to his new SecurID as if it was the first time he had encountered a blinking LCD: >I recently received "The E*TRADE Complete Security System" for controlling >access to my online E*TRADE account. It introduces two-factor >authentication to the login process, requiring both something I know (my >password) and something I have (a keyfob device). While this seems like a >very good idea on the surface, the implementation leaves something to be >desired from a usability standpoint. RSA's SecurID is a small, hand-held, personal authentication device that uses the US standard AES cipher, Current Time, and a 128-bit "shared secret" to generate, and continuously display, one-time passwords: 6-8 character "token-codes" that change every 60 seconds. E*TRADE has re-branded the RSA OTP token as its own "Digital Security ID" and is offering it without charge to its "Power" and "Priority" customers: independent market traders who make 15 trades per quarter, or have more than $50,000 at play in E-TRADE accounts. A FDIC study published in December 2004 concluded that — with 24/7 remote global access to financial networks now the norm; and "fraud through impersonation" rampant — "single-factor" password-based credentials, susceptible to capture and replay, no longer provide financial service customers with the credible security required for remote access to critical infrastructure. "Two-factor authentication," said the FDIC, "should be considered as the new security baseline for remote access to computer systems." Unlike banks, brokerages are not covered by the FDIC and "Regulation E" rules that limit consumer liability and ensure that defrauded bank customers are made whole. US brokerages usually return money that was transferred from an account due to criminal activity, but they are not obligated to do so. Losses due to online fraud are growing, but financial institutions across the board worry far more about the public reaction to the drumbeat of headlines about "identity theft" and multiple thefts of personal information data files. Perceived risk has already had a noticeable impact on public trust. Financial institutions increasingly rely on online channels for margins in their delivery of retail financial services, but Gartner reports that almost 60 percent of online consumers are "concerned" or "very concerned" about the security of financial services' web portals. Spurred by regulators, carping customers, foreign competitors, and consumer surveys, all US financial institutions are looking at two-factor authentication (2FA) — but US brokerage firms, led by E*TRADE, the first online broker, seem to be adapting to the 2FA requirement more quickly than US banks. E*TRADE Financial, with assets exceeding $17 billion, is today the 3rd largest online brokerage (by transaction volume); as well as the 3rd largest mortgage originator; and the 8th largest financial institution regulated by the US Treasury's Office of Thrift Supervision. Mr. Taft described E*TRADE's new access protocol: >The keyfob device, which carries E*TRADE and RSA logos, has a 6-digit >display that changes once per minute. In order to login, I need to present >my username and a password consisting of my regular fixed password >appended with the currently displayed 6-digit number. E*TRADE is using one of RSA's newer SecurIDs — a smaller key-shaped token, sometimes called a key ring "fob" — but the SecurIDs deployed by E*TRADE are functionally identical to those used daily by over 15 million men and women, largely enterprise corporate employees, at over 15,000 institutions. E*TRADE chose to substitute its own established password system — so customers like Mr. Taft need not memorize a new password — for the small password (aka "PIN") typically required as the second factor in SecurID 2FA installations. These passwords were previously used as E*TRADE's stand-alone authenticators, so they are surely at least marginally more secure than the 4-digit PINs traditionally used with SecurIDs by the White House staff, US Senators, and (as Mr. Raschke noted) employees in numerous government agencies, American and allied, around the globe. Mr. Taft began a querulous litany: >While this appears to have good security, some potential deficiencies come >to mind -- > >* It requires more typing than the old scheme, including an unfamiliar >sequence of characters that changes every time. I've been a consultant to RSA for nearly as long as Mr. Taft has been at Adobe, but Taft's fussy fretful complaints about "potential deficiencies" in the E*TRADE initiative bewilder me. The carefully-nuanced E*TRADE implementation is, to my mind, a case study of how to do 2FA right: application-specific, proportional, and customer-savvy — with the option of cranking up the security barrier even higher, as needed, with additional changes at the server end of the SSL link. E*TRADE launched this program in March after an extensive pilot project in which E*TRADE adapted the SecurID to their specific client requirements, and carefully explored the receptivity of E*TRADE customers to 2FA. Online investors expect their brokerage to offer security that will adapt to evolving threats, transparently where possible, overtly when necessary. They also demand immediate and relatively unobstructed access to their accounts, any time, from anywhere. And when they feel secure, they buy more financial services. Most SecurID token-holders are corporate employees required to use 2FA to safeguard corporate resources. E*TRADE knows consumers march to a different drum. E*TRADE's P&P clients are given a choice: 2FA is voluntary — and, for these select clients, the token is free. The old password system doesn't change; the OTP is simply an added service option. E*TRADE expects a high opt-in from brokerage customers who realize that it's their own assets and privacy that is at risk. Instead of an OTP token, Mr. Taft opined, E*TRADE should have provided its customers with digital certificates in USB plugs: >A better arrangement would be for the keyfob to have a USB connector that >I plug into my computer to prove that I have the keyfob. Yet, as young Mr. Raschke noted: >>Having a keyfob with a display allows the device to be used with any sort >>of computer — not every computer out there has a USB port, or one that >>is user-accessible. What if you log in using a phone or a PDA? USB authentication tokens are hot, the fastest-growing niche market in personal authentication. USB ports are multi-use connectors, and their widespread use in PC hardware has delighted PKI advocates who waited 25 years for smart-card readers on PCs. But USB is not ubiquitous. Twenty percent of the PCs sold two years ago didn't have USB ports, and the percentage rises rapidly with older PCs. Phones and PDAs, as Kurt noted, lack the port. Publicly accessible PCs — at airport kiosks, hotel business centers, Internet cafes, conference sites — often block USB ports to minimize their vulnerability to vandals and other local threats. A USB plug, for those unfamiliar with the tech, is a small injection-molded dongle, typically with a microprocessor and sufficient memory to securely store digital certificates and crypto keys. Plugged into a computer's USB port and initialized with a password, it can, like a smartcard, provide cryptographic services locally, and — in conjunction with a public-key infrastructure (PKI) — over a network: two-way authentication, encryption, digital signatures, assurances of message integrity, even "non-repudiation." Cost-effective PKI is still an institutional challenge, and consumer PKI an irksome Grail, but it's a rich technology. Against all that, the SecurID offers a stark if elegant simplicity. The OTP is available anytime, anywhere. It provides the functionality expected, and no more — an assurance difficult to obtain from a USB memory stick or a smartcard with a direct circuit connection to the CPU and the Net. Adobe's market lies largely in institutional sales, where users are disciplined to hierarchy and PCs are standardized and routinely upgraded. A financial services firm like E*TRADE serves opinionated individual investors, like Mr. Taft, who have no common computing platform — and little patience with any service provider which tries to dictate the configuration of their computers, let alone what communications device they can use, when they get down to business. (RSA, of course, invented RSA public key crypto and the PKCS protocols used to implement certificate-based PKI. So when E*TRADE chose classic SecurIDs over USB plugs, it wasn't because RSA didn't offer the USB option. RSA has sold USB tokens, smartcards, Keon PKI, and BSAFE crypto modules for a long time. RSA's newest SecurID — one of the five models it now sells -- actually features both a LCD for OTP display and a USB plug: <http://tinyurl.com/9rqoq>.) Mr. Taft had another worry about the E*TRADE setup: >* What if I need to login when I don't have the keyfob? There is a phone >number I can call to obtain temporary-access instructions, assuming that I >can convince the agent that I am the legitimate owner of the account. This >seems like a potential weak link in the scheme. Anything less than 2FA is inherently less secure, but jeeeze! — the problem of temporary credentials exists where E*TRADE still relies on static passwords, and would exist even if the brokerage had issued USB plugs. If Mr. Taft forgets his fob, he can still offer his password, which might gain him some account privileges, but not others. These are local policy issues, and E*TRADE is a financial institution which has had a lot of experience managing this particular risk. People are always the "weak link" in any security scheme. E*TRADE customers are people with power, with a choice among service providers. Like C-level executives who call their corporate help desk, privileged consumers probably expect E*TRADE to have a human over-ride for rigid technology (and granular levels of authorization at hand). Mr. Taft had one prescient concern: >* If multiple service providers adopt this scheme, I'll need a pocket full >of keyfobs. A better arrangement would be one keyfob that can hold >credentials for logging into multiple sites. In the token trade, this is called the "necklace" scenario, which for me always conjures up an image of cargo-cult Polynesian natives dancing with a string of SecurIDs around their necks. Corporate partners deal with this today with "federated identity" mechanisms: bilateral or group agreements to honor one another's authentication credentials, with the privileges of the "visitors" constrained as appropriate. (See, e.g., <http://tinyurl.com/43jfl>) In consumer financial services, however, attempts to establish a collaborative "trusted third-party" entity for federated identity management have run afoul of competitive realities. In response, two months ago, RSA announced the RSA Authentication Service, a managed service provider which later this year will offer a network of bilateral authentication services for organizations serving consumer markets. E*TRADE immediately announced that it would be the first RAS pilot site. RSA VP Chris Young — who was the head of safety and security for AOL premium services, when AOL first offered SecurIDs to its subscribers -- leads the product development team. The RSA Authentication Service (RAS) will require only that each participating institution has to trust RSA, as many already do for mission critical IT services. And the design goal for RAS is for RSA to hold almost zero information about the token-holder or his accounts. A customer of, say, "BoldBank" may have a SecurID issued by his bank. If he needs a broker, and he sees (on the E*TRADE website) that E*TRADE is willing to use the BoldBank SecurID he already carries as his E*TRADE 2nd authenticator for 2FA — he simply gives E*TRADE the serial number embossed on that SecurID and creates a password. E*TRADE then asks RAS to associate that SecurID, by serial number, with an E*TRADE-specific value — say a pseudo-random number — that will in the future be used to link authentication requests from that SecurID with a specific but unidentified E*TRADE account. RAS can now validate SecurID authentication calls from both account providers. The next time the customer signs on at the E*TRADE SSL portal, he provides his account name, password, and SecurID OTP. E*TRADE will validate the password locally. It will then link the SecurID "token-code" with the PRN identifier it gave RAS, and pass both over to RSA for a blind validation of the OTP. When E*TRADE receives the RAS's validation of the OTP, it has 2FA. The brokerage then makes the final link to the customer's account and opens that account with whatever privileges it has conferred on the customer. The account providers maintain total control over their customer account information; RAS doesn't want to know who or what is involved. Needless to say, Metcalfe's Law applies. RAS is an ambitious undertaking, perhaps comparable to the introduction of the early ATM networks, or RSA's spin-off of VeriSign ten years ago to exploit the potential of digital certs. The politics of trust, and the potential risks of "one token, many sites," will probably be the subject of RISKS commentaries at least through Mr. Raschke's college years. Expect a few from him. In his E*TRADE litany, Mr. Taft eventually stepped beyond grounded concerns. >* The scheme seems to depend on the keyfob and the server to have >synchronized clocks. What happens if the keyfob's battery dies or the >server's clock becomes misadjusted, as appears to occur with some regularity? Without sources or citations, without claiming first-hand experience himself, Mr. Taft — a gentleman of some prominence in this industry -- offers an accusation on the level of a "wife-beating" rumor. If Mr. Taft had a competitive bias in this discussion (as I do), this would rank as FUD: fear, uncertainty, and disinformation If a battery fails, as Mr. Raschke put it, "replace the token. It's as simple as that." RSA provides a full warranty on its sealed, tamper-resistant, SecurIDs. In 17 years, I can only recall a single batch of SecurIDs that had to be recalled (two years ago) because of electrical or battery problems. SecurIDs are programmed for a pre-designated product life of up to five years — three years for the E*TRADE token, I think — but the risk of a flawed SecurID battery is, historically, minuscule If and when a host server's clock becomes "misadjusted," it may (but not necessarily) require the RSA Authentication Manager to reset — but the RAM (aka ACE/Server) is itself rarely the cause of any disruption in the host. (Veteran ACE Admins on the list are invited to comment.) No hardware/software product is perfect, but the stability and reliability of the SecurID and its authentication server is such that it has — for 15 years — constantly held about a 70 percent share in a very competitive growth market for OTP tokens. After nearly two decades in the field, RSA's regular enhancements to the SecurID, and functional extensions for its authentication server, can still pull in a dozen respected ""Best New Product" and "Readers' Trust" awards. See the 04/05 prize list at: <http://tinyurl.com/8xbdg>. Mission-critical applications are necessarily held to a high standard. Does Mr. Taft really believe that RSA's SecurID could be this popular, for this long, if the employees of RSA's customers — "with some regularity" — were unable to access network resources? Does anyone believe that Microsoft would open up the Windows logon process, as it did last year — so that SecurIDs and 2FA could be used to replace Windows XP passwords — if SecurID 2FA was so undependable? A series of time-synch patents give RSA exclusive control over the mechanism that keeps the RAM server's clock "virtually" synchronized with the clock chips in each of the SecurIDs pre-registered on that server. Those patents allow for the elegant roll of 60-second OTPs on a SecurID, and that simplicity, historically, conferred on the SecurID an ease-of-use advantage over Challenge/Response tokens. Some analysts expect the half-billion dollar market for "strong authentication" tech to double over the next three years — largely because of new regulatory demands, in the US and elsewhere — but the 2KA market is also increasingly splintered among software and hardware options. OTP tokens; smartcards; USB plugs; GSM SIMs; biometric sensors; and flash drives are all in the hardware mix. Time-synch was the foundation of RSA's market dominance in OTPs, but it confers no particular advantage over C/R when smartcards or USB plugs can make a direct circuit connection with the network. In an increasingly-level competitive field, RSA has only reliability and innovation to hold customers and win new ones, like E*TRADE. (OT: RSA has leveraged the SecurID's popularity, and its BSAFE crypto savvy, into an array of oft-lauded products <http://tinyurl.com/3k334> for Identity & Access Management, Single Sign-On, Federated Identity Management, and a 2FA-enabled Microsoft security infrastructure: SecurID for Windows.) Mr. Taft offered a final pessimistic coda: >Fortunately, use of this security system is optional. The RISK is that >nobody will use this scheme because it is too inconvenient. The real RISK here is that someone might be influenced by Mr. Taft. Mr. Taft, maybe, is going to refuse to use the free E*TRADE token? As an E*TRADE customer, that's his privilege. Risk, like convenience, is relative. Threats that move me or others to mitigate a risk may not motivate Mr. Taft enough to get him to type an additional six digits. Mr. Taft, however, seems to be recommending that other E*TRADE customers should reject the E*TRADE 2FA tokens. "Fortunately," he concludes, all distant and academic, they don't have to use the SecurIDs. Is Mr. Taft urging E*TRADE investors to ignore the free E*TRADE tokens? Urging them, instead, to continue to use static passwords, on vulnerable PCs, to execute market trades and access their financial records? That, from a prominent IT professional, strikes me as mischievous, if not irresponsible. PS. My bias is overt. I have been a consultant to RSA since before the first SecurID was brought to market, and an evangelist for OTPs even before that. I beg the indulgence of the List and PGN for length, but its been a quiet weekend on the Net, and a rainy Sunday here. Vin McLellan + The Privacy Guild + <email@example.com> 22 Beacon St., Chelsea, MA 02150
Please report problems with the web pages to the maintainer