In this respect this is no worse at all. In one case, you have exactly one card that can be compromised, and cause this, in the other case, you have exactly one card that can be compromised and cause this PLUS you have another card that can be compromised and cause a bunch of hassle.
Your bank issuing cards with both chip and PIN, and NFC on them, does not imply that chip and PIN means NFC. These two things are completely different. If you don't like NFC, complain about that, not about chip and PIN.
Uh why on earth would this shift risk? When you use it you choose whether you use it as a credit or a debit card. The level of risk for both is identical.
Because in practice, the audits never happen, so chip-and-PIN is two factor (even if one of the factors is relatively weak), while chip-and-sign is one factor.
Why on earth is this a less bad solution? You go from two factor authentication with something you have (the card), and something you know (the PIN), to one factor authentication with something you have (the card), and something no one ever checks (the signature).
In practice, it is far more secure to use a written signature than a 4-digit password that is exposed to eavesdroppers, video cameras, interception devices and a plethora of other attacks. That's secure for the person, you understand: it prevents the bank from saying "you must have lost your pin".
The problem is, in practice, a written signature is not used to verify that the cardholder is present. No one ever checks the signature. That's the problem that chip-and-pin fixed. Add that to the fact that chip-and-pin would never have exposed sensitive data to a card reader's firmware like in the target hack, and you get an added bonus!
Why is the US behind everyone, well because we were first to come up with the initial infrastructure, by the time something new came along, we had a large complete infrastructure. So now the infrastructure is out of date, this happens. But when it does we need to try to invest into the next step, not the current, otherwise we will always be catching up.
You think europe didn't have a large and complete credit card infrastructure a decade ago when chip-and-pin came along?
Our infrastructure was out of date too... We recognised that it was a problem at the time, and we sorted it, you didn't.
... RFID is orders of magnitude less secure than a regular magnetic strip.
Lucky that chip-and-pin cards don't have RFID on them then;). They must be inserted into the reader for the chip to be used, and even then, the chip is not (and can not be) read, instead, it's used to encrypt, and sign your PIN, so that the bank can verify that it's really you (or someone who knows your PIN, and has your card – whee, two fold security, something you know, and something you have) there.
As this article points out, the opt-in is strongly incentivised by telling the vendors that they're responsible for any fraudulent payments if they haven't opted in.
It actually really frustrates me that the banks don't hand out verification tokens, so that the web site could give you a challenge, you stick your card in the verification token and type in your pin, and the token gives you a response to type back into the web site.
That would give you the ability to do cardholder-not-present transactions securely, without the need for revealing the PIN.
Not until they manage to drop the cheques; provide free, instant electronic transfers between accounts at different banks; support IBANs;... they aren't.
systemd was not a GNU project, so to suggest this is a GNU/linux distro is as fallacious as claiming that it's Poettering/Sievers/Linux distro.
What it is, is Linux. This particular project has some parts written by the GNU, and some parts written by Poettering/Sievers, and some other parts written by some other people. Stop trying to imply that the GNU is the be all and end all of user land software on Linux.
Chain of responsibility. The FCC tells the building owner to fix their building (which is emitting RF interference), the building owner take the lights down, replace them, and tell the maker of the lights to refund them or replace the lights with correctly working ones.
Well, profit is actually a pretty good metric. The money given to you is a measure of how much society values the thing that you are doing. If you can't make a profit, and can make a profit doing something else, the implication is that that other thing is more valuable to society just now.
Two guys argue about the value of x. One says x=2. The other says x=3. The first guy says "I have yet to see an x=3er willing to stand up and offer their points in a setting where x=2."
And yet the x=3ers want to teach about x=3ism in x=2 class.
It's incredibly cost effective, a typical nuclear plant will cost $8-12bn just in construction costs, so this is already 1/12th the price of nuclear in terms of construction.
Worse than that, the locations of the "normal", "overweight" etc bands on the BMI scale were decided at a very similar time with no scientific backing to them.
Recent studies have demonstrated that they're actually located one whole position too low. That is, mortality rates are lowest in people in the "overweight" category, they're second lowest in the "obese" category, third lowest in "normal". Finally, "underweight" is less healthy even than "morbidly obese".
C can't do it as anywhere near as neatly or safely as C++ though because it has no concept of privacy or encapsulation.
Sure there's a concept of privacy –simply don't let the compiler see the private stuff (i.e. don't put it in your header), and of course there's a concept of encapsulation – it's called writing functions that accept a data structure as their first argument, and only exposing the public ones via headers. C actually does a much *better* job of privacy and encapsulation than C++, as C++ requires you to write about private implementation details in public places (the header).
You also couldn't do things like implicit conversions to sql_safe_string to make it more friendly (assuming you want that).
You certainly can't do an implicit conversion, no. You can of course do an explicit one, but this is true of C++ too, and of course the programmer is a moron if they do this.
(And Joel is still wrong and Javascript still rubbish, which is more important than starting a C vs. C++ thread...)
Agreed, this is literally the example I use to demonstrate to people why they want a more strongly typed language than the one they're using. People seem not to realise that the type system can prove a lot more things than simply "you're passing a boolean to that if statement", and when exploited correctly can be made to prove some seriously important safety properties of your program. Another example that I use (which is very similar) is having a file transmitted over the network, and requiring verification that the file is actually valid, and is not giving all kinds of crazy values we don't expect, and may crash us. We can then trivially use the type system to prove that that verification actually happens before doing any real work with the file.
Yeah I hate the fact that none of the Javascript implementations actually scale past one core, and this is a serious problem. Yes there is the ability to use threads, but it's so useless since it's equal to forking a new process that has no access to anything of the parent process.
Good!
Anyone with even 5 minutes of experience writing multithreaded code will realise that no shared memory, and message passing is far superior as a method of thread synchronisation.
Slashdot Mirror
In this respect this is no worse at all. In one case, you have exactly one card that can be compromised, and cause this, in the other case, you have exactly one card that can be compromised and cause this PLUS you have another card that can be compromised and cause a bunch of hassle.
Your bank issuing cards with both chip and PIN, and NFC on them, does not imply that chip and PIN means NFC. These two things are completely different. If you don't like NFC, complain about that, not about chip and PIN.
While many banks issue cards with NFC, this is not part of chip and PIN.
Uh why on earth would this shift risk? When you use it you choose whether you use it as a credit or a debit card. The level of risk for both is identical.
Because in practice, the audits never happen, so chip-and-PIN is two factor (even if one of the factors is relatively weak), while chip-and-sign is one factor.
o.O
Why on earth is this a less bad solution? You go from two factor authentication with something you have (the card), and something you know (the PIN), to one factor authentication with something you have (the card), and something no one ever checks (the signature).
In practice, it is far more secure to use a written signature than a 4-digit password that is exposed to eavesdroppers, video cameras, interception devices and a plethora of other attacks. That's secure for the person, you understand: it prevents the bank from saying "you must have lost your pin".
The problem is, in practice, a written signature is not used to verify that the cardholder is present. No one ever checks the signature. That's the problem that chip-and-pin fixed. Add that to the fact that chip-and-pin would never have exposed sensitive data to a card reader's firmware like in the target hack, and you get an added bonus!
Why is the US behind everyone, well because we were first to come up with the initial infrastructure, by the time something new came along, we had a large complete infrastructure. So now the infrastructure is out of date, this happens. But when it does we need to try to invest into the next step, not the current, otherwise we will always be catching up.
You think europe didn't have a large and complete credit card infrastructure a decade ago when chip-and-pin came along?
Our infrastructure was out of date too... We recognised that it was a problem at the time, and we sorted it, you didn't.
... RFID is orders of magnitude less secure than a regular magnetic strip.
Lucky that chip-and-pin cards don't have RFID on them then ;). They must be inserted into the reader for the chip to be used, and even then, the chip is not (and can not be) read, instead, it's used to encrypt, and sign your PIN, so that the bank can verify that it's really you (or someone who knows your PIN, and has your card – whee, two fold security, something you know, and something you have) there.
As this article points out, the opt-in is strongly incentivised by telling the vendors that they're responsible for any fraudulent payments if they haven't opted in.
It actually really frustrates me that the banks don't hand out verification tokens, so that the web site could give you a challenge, you stick your card in the verification token and type in your pin, and the token gives you a response to type back into the web site.
That would give you the ability to do cardholder-not-present transactions securely, without the need for revealing the PIN.
Except if america caught up with the rest of the world, each of those credit and debit pairs would be one card ;).
Not until they manage to drop the cheques; provide free, instant electronic transfers between accounts at different banks; support IBANs; ... they aren't.
systemd was not a GNU project, so to suggest this is a GNU/linux distro is as fallacious as claiming that it's Poettering/Sievers/Linux distro.
What it is, is Linux. This particular project has some parts written by the GNU, and some parts written by Poettering/Sievers, and some other parts written by some other people. Stop trying to imply that the GNU is the be all and end all of user land software on Linux.
Chain of responsibility. The FCC tells the building owner to fix their building (which is emitting RF interference), the building owner take the lights down, replace them, and tell the maker of the lights to refund them or replace the lights with correctly working ones.
Well, profit is actually a pretty good metric. The money given to you is a measure of how much society values the thing that you are doing. If you can't make a profit, and can make a profit doing something else, the implication is that that other thing is more valuable to society just now.
Two guys argue about the value of x. One says x=2. The other says x=3. The first guy says "I have yet to see an x=3er willing to stand up and offer their points in a setting where x=2."
And yet the x=3ers want to teach about x=3ism in x=2 class.
It's incredibly cost effective, a typical nuclear plant will cost $8-12bn just in construction costs, so this is already 1/12th the price of nuclear in terms of construction.
Worse than that, the locations of the "normal", "overweight" etc bands on the BMI scale were decided at a very similar time with no scientific backing to them.
Recent studies have demonstrated that they're actually located one whole position too low. That is, mortality rates are lowest in people in the "overweight" category, they're second lowest in the "obese" category, third lowest in "normal". Finally, "underweight" is less healthy even than "morbidly obese".
Just like a battery truck could drive across america if it hooked up all the batteries it was carrying to it's electric motor... What's your point?
OK, *some* of it applies to C.
C can't do it as anywhere near as neatly or safely as C++ though because it has no concept of privacy or encapsulation.
Sure there's a concept of privacy –simply don't let the compiler see the private stuff (i.e. don't put it in your header), and of course there's a concept of encapsulation – it's called writing functions that accept a data structure as their first argument, and only exposing the public ones via headers. C actually does a much *better* job of privacy and encapsulation than C++, as C++ requires you to write about private implementation details in public places (the header).
You also couldn't do things like implicit conversions to sql_safe_string to make it more friendly (assuming you want that).
You certainly can't do an implicit conversion, no. You can of course do an explicit one, but this is true of C++ too, and of course the programmer is a moron if they do this.
(And Joel is still wrong and Javascript still rubbish, which is more important than starting a C vs. C++ thread...)
Agreed, this is literally the example I use to demonstrate to people why they want a more strongly typed language than the one they're using. People seem not to realise that the type system can prove a lot more things than simply "you're passing a boolean to that if statement", and when exploited correctly can be made to prove some seriously important safety properties of your program. Another example that I use (which is very similar) is having a file transmitted over the network, and requiring verification that the file is actually valid, and is not giving all kinds of crazy values we don't expect, and may crash us. We can then trivially use the type system to prove that that verification actually happens before doing any real work with the file.
Yeah I hate the fact that none of the Javascript implementations actually scale past one core, and this is a serious problem. Yes there is the ability to use threads, but it's so useless since it's equal to forking a new process that has no access to anything of the parent process.
Good!
Anyone with even 5 minutes of experience writing multithreaded code will realise that no shared memory, and message passing is far superior as a method of thread synchronisation.
No idea why you say none of this applies to C, this can trivially be done there too.
The UK has however in that time had several systems that reached hurricane strength, just none of them were ever called cyclones.
Actually, the UK has a higher rate of tornadoes than tornado alley in the US. It just happens they're generally somewhat smaller.