Comments: Microsoft - will they bungle the security game?

"And, they stress, all this can be done with non-Microsoft technologies, including Java and Linux. "The only Microsoft bit here is Infocard," said Turner."

"CardSafe will be built into Windows Vista, and will be available for Windows XP and Windows Server 2003, the company says."

Aren't these two statements contradictory? Sure, you can code your web site on any platform. But, if you actually want to access your web site, you MUST be using Windows XP or Vista. Windows 98 through 2000, Linux, and Mac need not apply.

Posted by Scott at June 17, 2006 03:42 PM

a little cross-over from the naked transactions and chip&pin fraud series ....
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV

Ten reasons Chip 'n' Pin cards are bad
http://www.vigay.com/misc/chipandpin.html
The weakness in combo chip/mag stripe cards
http://bankwatch.wordpress.com/2006/05/06/the-weakness-in-combo-chip-mag-stripe-cards/
Chip and pin 'makes fraud even easier'
http://business.timesonline.co.uk/article/0,,9558-2178933,00.html
Fears over Chip and Pin
http://business.timesonline.co.uk/article/0,,9558-2170865,00.html
Eight arrested in chip and pin fraud racket
http://www.24dash.com/content/news/viewNews.php?navID=34&newsID=5478
Hundreds of drivers caught out by GBP1m chip-and-PIN sting
http://www.tmcnet.com/usubmit/2006/05/06/1639848.htm
CHIP AND PIN CARDS IN CHAOS
http://www.tmcnet.com/usubmit/2006/05/07/1639879.htm
Fraud, Phishing and Financial Misdeeds: Chip and PIN, Another Chapter in the Attack on Debit Cards
http://fraudwar.blogspot.com/2006/05/chip-and-pin-another-chapter-in-attack.html

can you say "yes card"? ...
http://www.garlic.com/~lynn/aadsm24.htm#1
http://www.garlic.com/~lynn/aadsm24.htm#2

some chip & pin trials in the UK as early as 1997 and the current chip&pin "yes card" vulnerability was well documented by at least 2002
http://www.garlic.com/~lynn/2006l.html#32
http://www.garlic.com/~lynn/2006l.html#33

by 1998, work on aads chip strawman was to have higher security than any DDA technology at a lower cost than any SDA technology (and be able to meet transit contactless requirements)
http://www.garlic.com/~lynn/aadsm23.htm#56

part of this was based on detailed vulnerability study part of x9.59 standards work started in the mid-90s
http://www.garlic.com/~lynn/aadsm23.htm#56
http://www.garlic.com/~lynn/x959.html#x959

the same aads chip strawman designed for both POS and internet financial transactions also did duty as authentication in RADIUS as well as Kerberos (the major authentication infrastructures deployed in the world today) ... i.e. not just the same technology ... but the objective was that a users same, exact card (with no changes) ...
http://www.garlic.com/~lynn/aadsm23.htm#56
http://www.garlic.com/~lynn/subpubkey.html#radius
http://www.garlic.com/~lynn/subpubkey.html#kerberos

AADS Radius implementation was demonstrated spring of 1999
at PC WORLD in NYC by one of the participants of the AADS conference co-sponsored by Atalla and Tandem/Compaq held in Jan99 (radius is typically the authentication infrastructure used by ISPs world-wide)
http://www.garlic.com/~lynn/aepay3.htm#riskm

and the company that m'soft had subcontracted the original windows Kerberos implementation to (basis for the current/existing windows authentication infrastructure) demonstrated a number of different AADS chip strawman applications at the world-wide retail banking (BAI) show Dec99 in Miami
http://www.garlic.com/~lynn/99.html#217
http://www.garlic.com/~lynn/99.html#224

and NACHA was gearing up to do the AADS internet trials
about the same time
http://www.garlic.com/~lynn/x959.html#nacharfi

Posted by Lynn Wheeler at June 17, 2006 11:19 PM

Steve Summit wrote a concurring opinion over at http://www.securityabsurdity.com/archives/11#comment-44 (crossposted by Iang):
May 10th, 2006 at 9:02 pm

If you’re going to be a heretic and point out the truth about the Emperor’s new clothes :-), you might as well go whole-hog and pin the blame for all these problems where 90% of it belongs: Microsoft.

A lot of people will claim that’s not fair, that it’s too facile, that it’s not Microsoft’s fault (it’s the *bad guys’* fault!), that security is a *really hard* problem that Microsoft couldn’t be expected to get right, that Microsoft’s only problem is its popularity, that if the other, allegedly more secure platforms (Linux, Mac OS X) were as popular as Windows is, the bad guys would be targeting them and showing up just as many problems with them, too.

But as anyone who truly understands security will tell you, all those claims are bogus.

It *is* possible to do a better job, a much better job, on computer security. We’ve known how to for 20 or 30 years. We’ve known, for example, how to compartmentalize code, so that only critical OS code runs with full permissions, and that the majority of less-critical code runs in a restricted environment where it can’t do as much damage.

But Microsoft never really cared about any of that, and they very successfully implicitly trained a whole and much larger generation of computer users that security and other problems are mostly inevitable and have to be lived with, like bad weather or something.

As a wise man once said, “Other computer companies have spent years working on fault-tolerant computers. Microsoft has spent its time more fruitfully, working on fault-tolerant *users*”

Now that people are finally starting to demand some real security, it is in many ways too late: too many of the fundamental design decisions which underlie the insecurity are now utterly entrenched, and (apparently) can’t realistically be changed.

The most obvious example of the utter culpability of Microsoft software when it comes to security problems is: e-mail viruses. Where is it written that an executable attachment should be executed when you “open” it? Why is it the *user’s* responsibility to decide which attachments are safe (plain data) and which are dangerous (executable code)? The computer knows this, it can’t get confused by tricks to hide the filename, so why doesn’t it just refuse to execute the executable attachments? But somehow this straightforward solution is never adopted, evidently because there are one or two people who need to be able to click and run programs that they receive as email attachments but which aren’t viruses. Instead we run around deploying reactive “antivirus” tools that, as you’ve correctly pointed out, can never be perfectly reliable.

Posted by Steve Summit at June 20, 2006 06:56 AM
Post a comment









Remember personal info?






Hit Preview to see your comment.
MT::App::Comments=HASH(0x565411174d58) Subroutine MT::Blog::SUPER::site_url redefined at /home/iang/www/fc/cgi-bin/mt/lib/MT/Object.pm line 125.