Excuse me, but were you there at Blackhat? No? Surprise.
Had you attended, you would have noticed that every presenter discussed vulnerabilities only after responsible disclosure. Nobody at Blackhat was surprising any vendors with 0day exploits. Timothy's summary above is full of shit.
Now, I won't say every vendor was responsible about patching their systems upon notification. Too bad for them. But the Blackhat guys were all approaching the topic responsibly.
I'd settle for an e-mail program that just strips out the emoticons and LOLz and makes people write like someone writing, and not like someone writing while simultaneously trying to communicate body language.
Oh, and while you're at it, can you make it so the program pokes the writer in the eye every time he writes the words "win" and/or "fail" in all caps? Thanks.
I think a USB breathalyzer would accomplish much the same task...
You actually write application code that depends on the order of the columns in the result set?
No, I don't actually write application code like that. I do, however, work with some people who write code like that; and then I have to go in and fix it. But it's something that isn't apparent to a beginner, and I considered it something the OP ought to learn, before he starts doing it himself.
The one that I find still surprises people is actually 1NF. 2NF and 3NF are pretty easy to recognize. But think about CUSTOMER(CUST_ID, NAME, STREET_LINE_1, STREET_LINE_2, CITY, STATE, ZIP). Is it really in 1NF? Sure, if you're printing on envelopes. But maybe you need the customer's first name for a personalized letter. Maybe you need the house number and street separated for a GPS application. Or maybe you need the ZIP and ZIP+4 broken out separately for your postage software.
Any time you have the external application parsing your data fields into component values, you've failed at 1NF. But where do you stop? First and last names? Middle initial? Title? Honorific? Nickname? Pronunciation key? Phonetic spelling? You can go ape over-analyzing the data, and still easily miss something your users encounter the first week you deploy; effectively denormalizing the table simply by adopting a convention such as sticking "MR/MS/MRS" as the rightmost characters of the last name field.
Exactly! I want to know, that if the business continues to boom for the next five years, my software won't fall apart, because of bad database design.
In that case you want to always be on the look out for scalability and maintainability topics. Today's million row database might need to be tomorrow's 50 million row database, and you may have to change engines to something more performance oriented.
Something you need to learn is not simply how to model your data, but how to access it through an abstraction layer (such as views or stored procedures) that will allow you to replace the database engine without rewriting the software calling it.
This practice can also help you keep you safe as learn and grow. If you always access your data through the use of stored procedures, you effectively hide your database table schema from your application. So if tomorrow you figure out that by extracting Zip Codes to their own table you can save on postage, you can rearrange the data in the tables, yet still call the old stored procedure SP_GET_CUSTOMER_ADDRESS as long as you keep the signature of the stored procedure the same. You'll be able to reap the benefits of postage savings with no application code changes required.
Other things that aren't always taught include practical data access from within your code. My favorite is seeing something like "select * from MY_TABLE where KEY_VAL=2". This is a trap when it's embedded in your code or your SQL. The asterisk will always return all data columns in schema order. If you try to rearrange the order of columns in your schema (perhaps your modeling method or modeling tool encourages keeping primary key fields in sequential order, and you add a new key field, for example) you will break any code or stored procedures that use the "select *" query. "Select *" is fine for browsing a database by hand, but it doesn't belong in the code as it introduces this hidden dependency.
You also need to learn how to develop a "versioning" convention for naming your stored procedures, so you can continually update them in a backward compatible manner. I haven't seen that kind of advice in the books I've read, but maybe I'm just not reading the right books.
You'll also want to understand the differences between your chosen flavor of SQL and some of the big players, such as Oracle and SQL Server. There are a few annoying syntactical differences in the languages that can make porting between different vendors' databases difficult, and you may be able to avoid future update problems by avoiding certain language features.
To solve some of these problems, consider accessing the data from your application through a mapping library such as iBatis or LINQ. That way you're not writing the application portion of the SQL at all, and differences can often be resolved by updating a value in a configuration file.
Finally, you need to consider security. Unless the database is never actually used by anyone, it's very easy to write code that is vulnerable to SQL injection attacks.
I still don't think those in power understand American motivations. America is driven by a complex mix of money, corporations, special interests, corruption, etc., but at the core is the optimistic attitude of individual freedom, and a genuine belief that the government we see is in control.
Russia never seems to act like they believe that. It's like they are always trying to figure out which politicians are the corrupt ones making the significant decisions; kind of like an international shell game of "Where's Rasputin?" Any student of history knows that every government ever has been abusive and corrupt, and the Russians are famous for studying history. So they never accepted the answer that the U.S. was any different -- they always thought they just hadn't dug deep enough yet to uncover the real truth. And they are also puzzled that if we have these corrupt people, why aren't we using them to get stuff done?
I sometimes think they know more about the dirty undersides of our politics even more than our own FBI.
Your microwave oven operates on the same frequency as Wifi, and 8:30-10:00pm seems like a likely time for it to be running.
Holy crap, dude, what do you cook every night that you have to nuke it for 90 minutes??? Seriously, that's a hell of a long time to run a microwave oven, and really odd that someone would cook the same microwave meal night after night.
If you're that desperate, you're likely cooking Hot Pockets or microwave burritos, and those take only a few minutes to turn from frozen and inedible to warm and inedible.
Unfortunately, too often, it is up to citizens to read all the sources and attempt to extract the truth from the pile of bias.
We used to have an institution that would do that for you, present all sides, including sections that are fact only, plus separate editorial pieces, all in once convenient package. I think they used to call it "the press".
And that's why we need to pay to keep the press alive. If we don't support the news financially, the only news sources we'll be left with are those operated by the $(var)-wing nutjobs to push their agendas.
True fanbois wouldn't say that. What they would say is "this is what Steve had in mind the whole time and we are just now figuring it out!" Also "this represents a significant reduction of radiation that could lead to brain cancer... Steve cares about our health!"
This is disturbingly realistic dialog. Are you sure you're not a true believer?:-)
Next thing you know, holding a cell phone with the thumb and forefinger by the top right corner will become the fashionable way for any of the cognoscenti to hold their phones. Those of us who cradle them in the old fashioned way will be "not of the Body of Jobs", and mocked and ostracized.
That sounds reasonable, until you see Arlington and grasp just how very, very big it really is. There are 300,000 graves on the site. That is a huge task, and would require many people. For a place such as Arlington, volunteers would be plentiful. But even organizing a crowd like that is difficult, much less getting them all to perform a specific task correctly.
While it might sound efficient to put an HD video camera in the hands of a rider and have a 4-wheeler zip up and down the rows of the cemetery, it would not suit the dignity of the place.
Hmm... I bet someone could build a gravestone locator that watched a stream of video, identified the markers using some image recognition software, and targeted them with a motorized-mount SLR with a zoom lens. (It sounds rather a lot like a project I've recently seen on hackaday.com, except substituting markers for little brothers and cameras for chain-fed nerf guns.) By sticking to the roads, it wouldn't even have to be an undignified vehicle zooming around the place. And the regularity of the tombstones would permit automated searching for missing information, ensuring it was properly collected.
I lost interest at this point. Wake me up when biochemists and medical doctors get a chance to run test case groups about the adverse effects of lithium in their localized atmosphere, typically inhaled into the lungs and later causing one's sense of reality to become skewed.
Isn't this where the reavers came from? Lithium chloride in the atmosphere to calm the population, caused 99% of the people to give up and die, and sent 0.1% into a psychotic rage?
Oh, right. That was a science fiction movie. I always get those confused with reality.
It's pretty obvious that BP didn't intend to cause a spill. But when you get to be as big as BP, the size of the potential mistakes grows. If the point of the article is that we're going to make mistakes no matter what, then the logical conclusion is that nobody should be permitted to get big enough where their mistakes could cause more than xxx of damage, where xxx could be monetary, human lives, ecological impact, or whatever.
TFA is discussing the Maestro card being tested by MasterCard in Turkey that has an on-card display of an authorization number. This is identical in practice to an RSA SecurID token. The number proves that the card is authentic and not a clone. Since this number can be keyed by the customer in place of the PIN, the mechanisms exist today for authenticating it. That's a weakness in usability, but a serious improvement in security. It also has the potential to cost the merchants nothing, as it can be used with the existing mag stripe readers. But it will cost the banks significant amounts of money in terms of hardware and card costs.
The Maestro system has four significant weaknesses. The first is that the customer has to read the number from the card, and key it in the merchant's PIN pad. That is harder than simply swiping a card, and will require customers to learn a new thing. This is a decrease of usability from today, (but keep in mind that any secure solution is going to require changes to authenticate the human (which this does not.))
As mentioned above, the next weakness is that it does not authenticate the holder of the card (the cardholder is not required to key a secret PIN to unlock it.) The card can be stolen and used by someone else, up until the time it is reported stolen to the bank.
Another failure is it does not ensure that the customer is not the victim of a man-in-the-middle attack (a phishing web site, for example.) There is no way for the customer to say "I am paying Ikea for this furniture."
Another related failure is that it does not ensure the customer is paying only the amount requested by the merchant. If the merchant says "You owe $123.45", once you enter the number, the merchant could charge you $9999.99 and you would not know until you got your bill.
None of these are show-stopping weaknesses, and the strengths that the solution provides are that it uses actual cryptographic security, not some manufacturing difficulty. Is it the best? No, but it's a step in the right direction, and not some temporary feel-good patch.
To truly define a secure system, you have to understand the underlying problems that need to be solved, and produce a solution that addresses all of the issues, not just some of them. What is ultimately needed is a way to positively identify all the parties in a transaction: the cardholder, the bank, the cardholder's account number at that bank, and the payee. The other need is for the authorization of the cardholder for the bank to give a specific amount of money from their account to the payee. And all this has to be done in a manner that is easy to use for the customers and the merchants.
Current systems, such as mag stripes and CVV2 numbers, the magtek fingerprinting solution, the EMV CAP system, and the Maestro cards described above, are all focused on trying to make something work in the existing easy-to-use world of mag stripes, PIN pads, cash registers, and VisaNet. But their main problem is that by trying to constrain themselves to the existing hardware and networks and protocols and ease-of-use, (or worse by providing for backward compatibility,) they ultimately are unable to perform all of the tasks required to ensure the security of the transaction. Until the system is redesigned, they are all doomed to failures of some sort.
The ultimate irony is that Visa and MasterCard are no longer needed in a secure system. If the protocols are secure, the transactions can travel over a dirty network without risk. Visa makes their money by taking a cut from transactions traversing their "secure" network. So Visa has every incentive to NOT fix the current security model, as it cuts deeply into their only reason to exist. So don't look for Visa to fix the problems -- they won't. It has to come from the banks and the merchants (who already hate Visa for cutting into their margins.)
Once criminals get a hold of the new read heads, and learn how to measure the "fingerprints" they will be able to clone the mag stripes. If you can read it magnetically, you can copy it digitally, and you can create a clone that passes the digital tests perfectly. I am not saying I can personally clone the cards yet, but it is inevitable that if this new technology becomes the standard, it will be broken by criminals with the resources to do so. It has not been broken yet simply because it is not widely deployed to the world, and so is not profitable for the criminals -- yet.
Even if it were technically impossible to break the magtek system, it can do nothing to stop web fraud. A new smart-card based system will have to be put in place anyway in order to work over the web.
The main reason that telling the merchants to buy the magtek system now is such a bad idea is one of history. In the last few years the merchants spent lots of money buying new systems to comply with PCI, and they were unhappy at spending so much money on security. But they were told PCI was going to solve their security problems.
Now the banks are saying "All that PCI security you paid for last year, well, it was not good enough. But this magtek system is the greatest security system ever." The merchants will grudgingly buy it (having little say in the matter) and they will all spend lots more money to upgrade.
Next year, when the cloners start producing fraudulent cards (as they inevitably will), the banks will say "well, we knew that was not so good, but try these new smart cards, they're the greatest security system ever." The merchants will finally tell the banks "screw you, we spent millions last year when you said it was the greatest security ever, and you lied. We will not listen to you anymore."
It doesn't matter what the bank managers think of the system. Most of the bank managers are likely ordinary managers who believe the magtek salesmen, and are not asking qualified cryptographers who can understand the failings of relying on these "fingerprints". Besides, the bank managers are only too happy to hear a solution that passes the bill to the merchants, rather than pay for the real cryptographic security themselves by issuing smart cards.
Merchants ordinarily buy their POS equipment once every 10 or 20 years, no more often than until it falls apart. Being told that they must buy new hardware every other year because of the new security thing will lead to revolt. And we need to get smart cards deployed before that happens. The magtek system will waste money and burn any remaining goodwill that PCI had.
The problem is you still cannot prove that you are paying your money to Ikea or to Big Tony's House of Theft. You personally don't know Ikea's account number, so you could still be falling victim to a spoofed site. The likely avenue of attack for Big Tony is to find a patsy to register a legitimate looking business with the banks, generate a usable account number, run a few fast scams, and tale off with the money once enough suckers have fallen for the bait.
The only truly secure way to avoid this kind of MITM attack is for you to enter the name of your intended payee into your pad and have that incorporated into the authorization code exchange. You can't trust a barcode, because humans can't read stripes. You could trust a camera to take a picture of their logo, though, or to do optical character recognition. It just has to be some data that both you and your pocket device can both understand.
Modern cryptographic (RSA-based) smart cards have demonstrated a consistently high cost of attack, and attacks currently require the destructive opening of the chip and a high resolution microscope and probe, or that they be hooked up to a precision power supply and are subjected to thousands of attacks on the power and timing, not to mention requiring the presence of a PhD to interpret the results. There is some speculation of an RF based attack on the timing as well, but that hasn't been demonstrated yet.
So far, smart cards appear to be quite safe from the waiter/skimmer type of casual attacks. They are certainly the most cost effective solution for widespread deployment. And they are recommended by serious three letter agencies for use in protecting US military assets and secrets. I'm not convinced that your speculation that they are inherently flawed is valid.
You missed that I was replying to the GP poster who said that the magtek solution (a discriminating read head is installed on the POS terminals) was a good one. It is not. The magtek solution is a terrible solution for all the reasons I mentioned.
This new card solution mentioned in the article has an actual basis in cryptography for being more secure than mag stripes. Yes, it can still be MITM and browser hijacked, and will still be susceptible to unauthorized stored reuse (keeping your card on file for automatic payments, for example) but the authentication will absolutely prevent cloning with the level of assurance that the crypto algorithms provide, instead of the faint hope that cloners will never figure out how to build good quality cloning hardware.
Slashdot Mirror
Invoking Ohm's law automatically ends the discussion...
Is that like Wheatstoning a tech thread?
I saw a brilliant slide at Blackhat last week that sums it up perfectly (same vendor, different product)
Native Security Functionality of Adobe Flash
[ This slide intentionally left blank ]
Excuse me, but were you there at Blackhat? No? Surprise.
Had you attended, you would have noticed that every presenter discussed vulnerabilities only after responsible disclosure. Nobody at Blackhat was surprising any vendors with 0day exploits. Timothy's summary above is full of shit.
Now, I won't say every vendor was responsible about patching their systems upon notification. Too bad for them. But the Blackhat guys were all approaching the topic responsibly.
I have a buddy who wants his email postings from Saturday night delayed until Sunday evening, so he can take them all back after he sobers up.
I'd settle for an e-mail program that just strips out the emoticons and LOLz and makes people write like someone writing, and not like someone writing while simultaneously trying to communicate body language.
Oh, and while you're at it, can you make it so the program pokes the writer in the eye every time he writes the words "win" and/or "fail" in all caps? Thanks.
I think a USB breathalyzer would accomplish much the same task...
You actually write application code that depends on the order of the columns in the result set?
No, I don't actually write application code like that. I do, however, work with some people who write code like that; and then I have to go in and fix it. But it's something that isn't apparent to a beginner, and I considered it something the OP ought to learn, before he starts doing it himself.
The one that I find still surprises people is actually 1NF. 2NF and 3NF are pretty easy to recognize. But think about CUSTOMER(CUST_ID, NAME, STREET_LINE_1, STREET_LINE_2, CITY, STATE, ZIP). Is it really in 1NF? Sure, if you're printing on envelopes. But maybe you need the customer's first name for a personalized letter. Maybe you need the house number and street separated for a GPS application. Or maybe you need the ZIP and ZIP+4 broken out separately for your postage software.
Any time you have the external application parsing your data fields into component values, you've failed at 1NF. But where do you stop? First and last names? Middle initial? Title? Honorific? Nickname? Pronunciation key? Phonetic spelling? You can go ape over-analyzing the data, and still easily miss something your users encounter the first week you deploy; effectively denormalizing the table simply by adopting a convention such as sticking "MR/MS/MRS" as the rightmost characters of the last name field.
I don't have an answer, it's just not fair. :-(
Exactly! I want to know, that if the business continues to boom for the next five years, my software won't fall apart, because of bad database design.
In that case you want to always be on the look out for scalability and maintainability topics. Today's million row database might need to be tomorrow's 50 million row database, and you may have to change engines to something more performance oriented.
Something you need to learn is not simply how to model your data, but how to access it through an abstraction layer (such as views or stored procedures) that will allow you to replace the database engine without rewriting the software calling it.
This practice can also help you keep you safe as learn and grow. If you always access your data through the use of stored procedures, you effectively hide your database table schema from your application. So if tomorrow you figure out that by extracting Zip Codes to their own table you can save on postage, you can rearrange the data in the tables, yet still call the old stored procedure SP_GET_CUSTOMER_ADDRESS as long as you keep the signature of the stored procedure the same. You'll be able to reap the benefits of postage savings with no application code changes required.
Other things that aren't always taught include practical data access from within your code. My favorite is seeing something like "select * from MY_TABLE where KEY_VAL=2". This is a trap when it's embedded in your code or your SQL. The asterisk will always return all data columns in schema order. If you try to rearrange the order of columns in your schema (perhaps your modeling method or modeling tool encourages keeping primary key fields in sequential order, and you add a new key field, for example) you will break any code or stored procedures that use the "select *" query. "Select *" is fine for browsing a database by hand, but it doesn't belong in the code as it introduces this hidden dependency.
You also need to learn how to develop a "versioning" convention for naming your stored procedures, so you can continually update them in a backward compatible manner. I haven't seen that kind of advice in the books I've read, but maybe I'm just not reading the right books.
You'll also want to understand the differences between your chosen flavor of SQL and some of the big players, such as Oracle and SQL Server. There are a few annoying syntactical differences in the languages that can make porting between different vendors' databases difficult, and you may be able to avoid future update problems by avoiding certain language features.
To solve some of these problems, consider accessing the data from your application through a mapping library such as iBatis or LINQ. That way you're not writing the application portion of the SQL at all, and differences can often be resolved by updating a value in a configuration file.
Finally, you need to consider security. Unless the database is never actually used by anyone, it's very easy to write code that is vulnerable to SQL injection attacks.
I still don't think those in power understand American motivations. America is driven by a complex mix of money, corporations, special interests, corruption, etc., but at the core is the optimistic attitude of individual freedom, and a genuine belief that the government we see is in control.
Russia never seems to act like they believe that. It's like they are always trying to figure out which politicians are the corrupt ones making the significant decisions; kind of like an international shell game of "Where's Rasputin?" Any student of history knows that every government ever has been abusive and corrupt, and the Russians are famous for studying history. So they never accepted the answer that the U.S. was any different -- they always thought they just hadn't dug deep enough yet to uncover the real truth. And they are also puzzled that if we have these corrupt people, why aren't we using them to get stuff done?
I sometimes think they know more about the dirty undersides of our politics even more than our own FBI.
They will soon find out that their price point will have to be below that of an ipad, or they'll sell zero of them.
Your microwave oven operates on the same frequency as Wifi, and 8:30-10:00pm seems like a likely time for it to be running.
Holy crap, dude, what do you cook every night that you have to nuke it for 90 minutes??? Seriously, that's a hell of a long time to run a microwave oven, and really odd that someone would cook the same microwave meal night after night.
If you're that desperate, you're likely cooking Hot Pockets or microwave burritos, and those take only a few minutes to turn from frozen and inedible to warm and inedible.
This app sounded interesting so I checked the app store for it. Apparently it is no longer available on non-jailbroken iPhones.
Thus, the spirit jailbreak was born. You'll seriously not regret it nearly as much as buying the damn locked down phone in the first place.
Here's a cheap build-it-yourself spectrum analyzer: http://hackaday.com/2010/03/17/im-me-spectrum-analyzer/ The IM-ME can be had for about $15 or so, and is purportedly very hackable.
Unfortunately, too often, it is up to citizens to read all the sources and attempt to extract the truth from the pile of bias.
We used to have an institution that would do that for you, present all sides, including sections that are fact only, plus separate editorial pieces, all in once convenient package. I think they used to call it "the press".
And that's why we need to pay to keep the press alive. If we don't support the news financially, the only news sources we'll be left with are those operated by the $(var)-wing nutjobs to push their agendas.
True fanbois wouldn't say that. What they would say is "this is what Steve had in mind the whole time and we are just now figuring it out!" Also "this represents a significant reduction of radiation that could lead to brain cancer... Steve cares about our health!"
This is disturbingly realistic dialog. Are you sure you're not a true believer? :-)
Next thing you know, holding a cell phone with the thumb and forefinger by the top right corner will become the fashionable way for any of the cognoscenti to hold their phones. Those of us who cradle them in the old fashioned way will be "not of the Body of Jobs", and mocked and ostracized.
That sounds reasonable, until you see Arlington and grasp just how very, very big it really is. There are 300,000 graves on the site. That is a huge task, and would require many people. For a place such as Arlington, volunteers would be plentiful. But even organizing a crowd like that is difficult, much less getting them all to perform a specific task correctly.
While it might sound efficient to put an HD video camera in the hands of a rider and have a 4-wheeler zip up and down the rows of the cemetery, it would not suit the dignity of the place.
Hmm... I bet someone could build a gravestone locator that watched a stream of video, identified the markers using some image recognition software, and targeted them with a motorized-mount SLR with a zoom lens. (It sounds rather a lot like a project I've recently seen on hackaday.com, except substituting markers for little brothers and cameras for chain-fed nerf guns.) By sticking to the roads, it wouldn't even have to be an undignified vehicle zooming around the place. And the regularity of the tombstones would permit automated searching for missing information, ensuring it was properly collected.
Yeah, it's doable.
I lost interest at this point. Wake me up when biochemists and medical doctors get a chance to run test case groups about the adverse effects of lithium in their localized atmosphere, typically inhaled into the lungs and later causing one's sense of reality to become skewed.
Isn't this where the reavers came from? Lithium chloride in the atmosphere to calm the population, caused 99% of the people to give up and die, and sent 0.1% into a psychotic rage?
Oh, right. That was a science fiction movie. I always get those confused with reality.
There, there. It's OK that you're wrong and stupid.
It's pretty obvious that BP didn't intend to cause a spill. But when you get to be as big as BP, the size of the potential mistakes grows. If the point of the article is that we're going to make mistakes no matter what, then the logical conclusion is that nobody should be permitted to get big enough where their mistakes could cause more than xxx of damage, where xxx could be monetary, human lives, ecological impact, or whatever.
I don't think that will be the answer, however.
TFA is discussing the Maestro card being tested by MasterCard in Turkey that has an on-card display of an authorization number. This is identical in practice to an RSA SecurID token. The number proves that the card is authentic and not a clone. Since this number can be keyed by the customer in place of the PIN, the mechanisms exist today for authenticating it. That's a weakness in usability, but a serious improvement in security. It also has the potential to cost the merchants nothing, as it can be used with the existing mag stripe readers. But it will cost the banks significant amounts of money in terms of hardware and card costs.
The Maestro system has four significant weaknesses. The first is that the customer has to read the number from the card, and key it in the merchant's PIN pad. That is harder than simply swiping a card, and will require customers to learn a new thing. This is a decrease of usability from today, (but keep in mind that any secure solution is going to require changes to authenticate the human (which this does not.))
As mentioned above, the next weakness is that it does not authenticate the holder of the card (the cardholder is not required to key a secret PIN to unlock it.) The card can be stolen and used by someone else, up until the time it is reported stolen to the bank.
Another failure is it does not ensure that the customer is not the victim of a man-in-the-middle attack (a phishing web site, for example.) There is no way for the customer to say "I am paying Ikea for this furniture."
Another related failure is that it does not ensure the customer is paying only the amount requested by the merchant. If the merchant says "You owe $123.45", once you enter the number, the merchant could charge you $9999.99 and you would not know until you got your bill.
None of these are show-stopping weaknesses, and the strengths that the solution provides are that it uses actual cryptographic security, not some manufacturing difficulty. Is it the best? No, but it's a step in the right direction, and not some temporary feel-good patch.
To truly define a secure system, you have to understand the underlying problems that need to be solved, and produce a solution that addresses all of the issues, not just some of them. What is ultimately needed is a way to positively identify all the parties in a transaction: the cardholder, the bank, the cardholder's account number at that bank, and the payee. The other need is for the authorization of the cardholder for the bank to give a specific amount of money from their account to the payee. And all this has to be done in a manner that is easy to use for the customers and the merchants.
Current systems, such as mag stripes and CVV2 numbers, the magtek fingerprinting solution, the EMV CAP system, and the Maestro cards described above, are all focused on trying to make something work in the existing easy-to-use world of mag stripes, PIN pads, cash registers, and VisaNet. But their main problem is that by trying to constrain themselves to the existing hardware and networks and protocols and ease-of-use, (or worse by providing for backward compatibility,) they ultimately are unable to perform all of the tasks required to ensure the security of the transaction. Until the system is redesigned, they are all doomed to failures of some sort.
The ultimate irony is that Visa and MasterCard are no longer needed in a secure system. If the protocols are secure, the transactions can travel over a dirty network without risk. Visa makes their money by taking a cut from transactions traversing their "secure" network. So Visa has every incentive to NOT fix the current security model, as it cuts deeply into their only reason to exist. So don't look for Visa to fix the problems -- they won't. It has to come from the banks and the merchants (who already hate Visa for cutting into their margins.)
Once criminals get a hold of the new read heads, and learn how to measure the "fingerprints" they will be able to clone the mag stripes. If you can read it magnetically, you can copy it digitally, and you can create a clone that passes the digital tests perfectly. I am not saying I can personally clone the cards yet, but it is inevitable that if this new technology becomes the standard, it will be broken by criminals with the resources to do so. It has not been broken yet simply because it is not widely deployed to the world, and so is not profitable for the criminals -- yet.
Even if it were technically impossible to break the magtek system, it can do nothing to stop web fraud. A new smart-card based system will have to be put in place anyway in order to work over the web.
The main reason that telling the merchants to buy the magtek system now is such a bad idea is one of history. In the last few years the merchants spent lots of money buying new systems to comply with PCI, and they were unhappy at spending so much money on security. But they were told PCI was going to solve their security problems.
Now the banks are saying "All that PCI security you paid for last year, well, it was not good enough. But this magtek system is the greatest security system ever." The merchants will grudgingly buy it (having little say in the matter) and they will all spend lots more money to upgrade.
Next year, when the cloners start producing fraudulent cards (as they inevitably will), the banks will say "well, we knew that was not so good, but try these new smart cards, they're the greatest security system ever." The merchants will finally tell the banks "screw you, we spent millions last year when you said it was the greatest security ever, and you lied. We will not listen to you anymore."
It doesn't matter what the bank managers think of the system. Most of the bank managers are likely ordinary managers who believe the magtek salesmen, and are not asking qualified cryptographers who can understand the failings of relying on these "fingerprints". Besides, the bank managers are only too happy to hear a solution that passes the bill to the merchants, rather than pay for the real cryptographic security themselves by issuing smart cards.
Merchants ordinarily buy their POS equipment once every 10 or 20 years, no more often than until it falls apart. Being told that they must buy new hardware every other year because of the new security thing will lead to revolt. And we need to get smart cards deployed before that happens. The magtek system will waste money and burn any remaining goodwill that PCI had.
The problem is you still cannot prove that you are paying your money to Ikea or to Big Tony's House of Theft. You personally don't know Ikea's account number, so you could still be falling victim to a spoofed site. The likely avenue of attack for Big Tony is to find a patsy to register a legitimate looking business with the banks, generate a usable account number, run a few fast scams, and tale off with the money once enough suckers have fallen for the bait.
The only truly secure way to avoid this kind of MITM attack is for you to enter the name of your intended payee into your pad and have that incorporated into the authorization code exchange. You can't trust a barcode, because humans can't read stripes. You could trust a camera to take a picture of their logo, though, or to do optical character recognition. It just has to be some data that both you and your pocket device can both understand.
Modern cryptographic (RSA-based) smart cards have demonstrated a consistently high cost of attack, and attacks currently require the destructive opening of the chip and a high resolution microscope and probe, or that they be hooked up to a precision power supply and are subjected to thousands of attacks on the power and timing, not to mention requiring the presence of a PhD to interpret the results. There is some speculation of an RF based attack on the timing as well, but that hasn't been demonstrated yet.
So far, smart cards appear to be quite safe from the waiter/skimmer type of casual attacks. They are certainly the most cost effective solution for widespread deployment. And they are recommended by serious three letter agencies for use in protecting US military assets and secrets. I'm not convinced that your speculation that they are inherently flawed is valid.
You missed that I was replying to the GP poster who said that the magtek solution (a discriminating read head is installed on the POS terminals) was a good one. It is not. The magtek solution is a terrible solution for all the reasons I mentioned.
This new card solution mentioned in the article has an actual basis in cryptography for being more secure than mag stripes. Yes, it can still be MITM and browser hijacked, and will still be susceptible to unauthorized stored reuse (keeping your card on file for automatic payments, for example) but the authentication will absolutely prevent cloning with the level of assurance that the crypto algorithms provide, instead of the faint hope that cloners will never figure out how to build good quality cloning hardware.