First of all, fuck off too. I was a DJ for many years and took pride in my work because I researched music very much, as well as always being alert and trying to understand my customers. If you have something insightful to add then do it. But don't try to counter my argument by giving a reference to DJ hero (Which I have never heard before). It's just stupid
And about the original comment, troll? Wtf? I am sorry for the anonymous coward that I responded to, but someone who doesn't have a say in what he plays is just another gear in the Music Industry, and the expectation of potenial employers from me to do the same thing is the main reason I stopped DJing professionally.
Now if someone has to add something to that, please use arguments
So you are not a DJ, you are just the person who changes the tracks. A DJ is a person who chooses the music he plays. Have you ever thought that by doing this job, you are part of the problem?
I don't think it matters that much if the terminal is hacked because if it is, it cannot communicate with the bank host (assuming that the terminal wasn't already tampered when the bank injected the cryptographic keys). Also, even if the user is tricked into giving the PIN, the card cannot be copied so it has to be stolen from the user. In the case of genuine terminals, in order to accept EMV cards they are tested and certified to be secure
About the PIN, The decision whether the PIN goes online or stays offline has more factors than just the acquiring bank so I have a feeling it would be very confusing to the average cardholder.
In the end I have to say that the whole process is secure enough and in practice credit card fraud has dropped with EMV. However I don't think it's secure enough (and I think it will never be) to eliminate the receipt signature and to pass the fraud liability to the cardholder
having programmed EMV terminals, first of all the pin is encrypted by the card chip so there is a way for the bank to verify that the card is authentic. In order for the terminals to be EMV certified, the terminal prompts are saved on a seperate file that has to by digitally signed by the terminal vendor in order to be used, so if the prompts are misleading they can be traced back to the person who signed the prompts, usually by the development team. The terminal is not validated by the card (it's not possible because there are way to many issuers/acquirers), but it is validated by the bank server. The terminals are tamper responsive which means that if an instrusion is detected the terminal deletes all the keys that reside on the secure cryptoprocessor and locks down. Sometimes if we hit the terminal too hard or it fell, it would lock and we had to reset it and program new keys. There are some attacks like the MITM that is described in wikipedia but are hard to perform on a large scale and easy to get caught. In the case of the tampering of the terminals that wikipedia describes, it is the banks/vendors fault for not having enough security in the terminal manufacture process.
From my experience EMV terminals with EMV cards are very secure, but as with everything in IT, they are not unbreakable
And we should be thankful that this will cause a DOS compatibility issue because we will finally see more tools that use modern systems. I actually will be very happy if I never see the DOS prompt again. This is a perfect opportunity for linux to become the standard for low level maintenance (with the appropriate proprietary tools) the way it became the standard for embedded devices.
You can't sue dell, because they don't advertise that you can run OS/2 on their current systems. You could sue them if they disabled the installation of Vista after the windows 7 release
Although you have a point, sometimes I think it's better to constantly upgrade on non mission critical systems because if at some point in the future you need to upgrade it's 100x times more difficult than applying small upgrades. Regarding the repository, I think after some time they move the old repositories to archives and you need to change the package manager configuration in order for it to work (At least in ubuntu that is the case)
Although I agree that this is probably a stunt, the reason these people work there has nothing to do with free will. People find it very difficult to migrate from one place to another in order to find better working conditions (even in the same country). If every single job is like that then there is no free will because you are f*cked no matter where you go. Even if you migrate you have to deal with new cultures, racism etc. So no, there is no free will.
If the GUI tool acts as a frontend which accepts plugins to generate and apply rules to specific router implementations, then you could have access to the scripts that were generated (we are after all talking about something non-existent). Also, with a GUI you can have workstation/server/router/user groups that you can use to apply common rules. Also you could use inheritance among the groups to apply additional rules to certain subgroups. With a GUI you have everything on a single interface so you don't need to keep a handwritten network map so you can troubleshoot simple network errors, or explain to someone else the network
I am not arguing that CLI is the best solution available right now but I am pretty sure that a good GUI management app is not impossible
I know both and I am sure a (well built) GUI tool would make my life easier. Just because CLI has a steeper learning curve doesn't mean that it is better or more 31337.
I don't get it. Why do this to slashdot where most of the users use adblock and even if they don't,they won't click on the ads (I hope...) just because it's a typo-squatted domain. Then again I appreciate their honesty...
On a closer look it seems you are correct. Not sending the PIN on the cryptogram is a very very stupid thing to do. Let's just hope it's not practical to carry all this equipment and use the attack without being seen
If things go that way, you will end up in court (and probably win). I have never heard of a case that went to court but I know many cases that the bank (or the merchant) just paid up. But if you just accept the bullshit a low management bank employee tells you, you are screwed anyway. Nevertheless if the bank is determined not to pay it is gonna get ugly
In order for the transaction to be authorized by the server, the PIN is encrypted and sent by the terminal using a symmetric key that the bank gives the terminal vendor. So no this is not possible
If you can't *prove* a crime was committed, they don't have to pay.
If they can't prove a transaction was initiated by you then you don't have to pay
In case of a dispute of a transaction with a magnetic card (and sometimes with EMV cards), in order for the bank to prove that the transaction is legitimate the receipt must have a signature that matches the signature on your ID. If the signature is not the same according to law you have no obligation of paying up and if the amount is big enough you can sue the bank or just don't pay the amount and wait to get sued by the bank.
The main reason magnetic cards were replaced by EMV cards is that the fraud costs had to be covered by the bank and by the merchant (because they did not check an ID). With EMV cards if a signature is not required and somehow someone makes a transaction with your card, you are screwed
Actually in the EMV specifications the terminal has to authenticate the card via a key exchange, however this is not used to encrypt the communication between the card and the terminal.
On the bright side this attack can only work on offline transactions which must be below a bank specified floor limit (the upper limit that the transaction can be authorized on the floor). For online transactions the PIN is also sent to the bank so this will fail. In practice some banks have a zero floor limit so all transactions have to be authorized online. Even if the floor limit is not zero, it never is over about 10 euro or something like that
The salt can be user and website dependent (4 bytes user/4 bytes website for an 8 byte salt). Although I think that the added complexity won't be welcomed by the website owners
The salt is not exactly supposed to be obscure. If it was then it would be just a password, and this is not the case as it would be called a password and not a salt. The salt should be available to the entities generating the hash (in this case the web sites). Now find me a practical way to distribute the salt to the legitimate web sites without the bad guys knowing...
The email matching process for 80871 users takes about one hour (from TFA). Adding a three digit salt would increase the matching process to 999 hours or about 41 days which is not much considering that this is a brute force attack and I believe the user would be unwilling to remember a salt longer than 3 digits. An alternative would be if gravatar would automatically generate a salt and the web site could retrieve this salt (over ssl maybe, for the paranoid among us) on user registration. Then again the user must authorize which sites can retrieve the salt (through an email authorization link maybe?) which would also add complexity to the registration process.
Slashdot Mirror
Left/Right effect sure. But Front/Back? Could you please give an example of such a recording?
First of all, fuck off too. I was a DJ for many years and took pride in my work because I researched music very much, as well as always being alert and trying to understand my customers. If you have something insightful to add then do it. But don't try to counter my argument by giving a reference to DJ hero (Which I have never heard before). It's just stupid
And about the original comment, troll? Wtf? I am sorry for the anonymous coward that I responded to, but someone who doesn't have a say in what he plays is just another gear in the Music Industry, and the expectation of potenial employers from me to do the same thing is the main reason I stopped DJing professionally.
Now if someone has to add something to that, please use arguments
Yeah, we can argue about this all day, but I think you understood what I meant
So you are not a DJ, you are just the person who changes the tracks. A DJ is a person who chooses the music he plays. Have you ever thought that by doing this job, you are part of the problem?
Yes. In high school. If you can't substitute values, you shouldn't be in college
I don't think it matters that much if the terminal is hacked because if it is, it cannot communicate with the bank host (assuming that the terminal wasn't already tampered when the bank injected the cryptographic keys). Also, even if the user is tricked into giving the PIN, the card cannot be copied so it has to be stolen from the user. In the case of genuine terminals, in order to accept EMV cards they are tested and certified to be secure
About the PIN, The decision whether the PIN goes online or stays offline has more factors than just the acquiring bank so I have a feeling it would be very confusing to the average cardholder.
In the end I have to say that the whole process is secure enough and in practice credit card fraud has dropped with EMV. However I don't think it's secure enough (and I think it will never be) to eliminate the receipt signature and to pass the fraud liability to the cardholder
having programmed EMV terminals, first of all the pin is encrypted by the card chip so there is a way for the bank to verify that the card is authentic. In order for the terminals to be EMV certified, the terminal prompts are saved on a seperate file that has to by digitally signed by the terminal vendor in order to be used, so if the prompts are misleading they can be traced back to the person who signed the prompts, usually by the development team. The terminal is not validated by the card (it's not possible because there are way to many issuers/acquirers), but it is validated by the bank server. The terminals are tamper responsive which means that if an instrusion is detected the terminal deletes all the keys that reside on the secure cryptoprocessor and locks down. Sometimes if we hit the terminal too hard or it fell, it would lock and we had to reset it and program new keys. There are some attacks like the MITM that is described in wikipedia but are hard to perform on a large scale and easy to get caught. In the case of the tampering of the terminals that wikipedia describes, it is the banks/vendors fault for not having enough security in the terminal manufacture process.
From my experience EMV terminals with EMV cards are very secure, but as with everything in IT, they are not unbreakable
And we should be thankful that this will cause a DOS compatibility issue because we will finally see more tools that use modern systems. I actually will be very happy if I never see the DOS prompt again. This is a perfect opportunity for linux to become the standard for low level maintenance (with the appropriate proprietary tools) the way it became the standard for embedded devices.
You can't sue dell, because they don't advertise that you can run OS/2 on their current systems. You could sue them if they disabled the installation of Vista after the windows 7 release
I don't think so since mickey mouse appears in the same episode as himself as well as in a previous episode
Although you have a point, sometimes I think it's better to constantly upgrade on non mission critical systems because if at some point in the future you need to upgrade it's 100x times more difficult than applying small upgrades.
Regarding the repository, I think after some time they move the old repositories to archives and you need to change the package manager configuration in order for it to work (At least in ubuntu that is the case)
Although I agree that this is probably a stunt, the reason these people work there has nothing to do with free will. People find it very difficult to migrate from one place to another in order to find better working conditions (even in the same country). If every single job is like that then there is no free will because you are f*cked no matter where you go. Even if you migrate you have to deal with new cultures, racism etc. So no, there is no free will.
If the GUI tool acts as a frontend which accepts plugins to generate and apply rules to specific router implementations, then you could have access to the scripts that were generated (we are after all talking about something non-existent). Also, with a GUI you can have workstation/server/router/user groups that you can use to apply common rules. Also you could use inheritance among the groups to apply additional rules to certain subgroups. With a GUI you have everything on a single interface so you don't need to keep a handwritten network map so you can troubleshoot simple network errors, or explain to someone else the network
I am not arguing that CLI is the best solution available right now but I am pretty sure that a good GUI management app is not impossible
I know both and I am sure a (well built) GUI tool would make my life easier. Just because CLI has a steeper learning curve doesn't mean that it is better or more 31337.
I don't get it. Why do this to slashdot where most of the users use adblock and even if they don't,they won't click on the ads (I hope...) just because it's a typo-squatted domain. Then again I appreciate their honesty...
TNT neither absorbs nor dissolves in water, which allows it to be used effectively in wet environments.
So, did you actually read the article you are linking to?
On a closer look it seems you are correct. Not sending the PIN on the cryptogram is a very very stupid thing to do. Let's just hope it's not practical to carry all this equipment and use the attack without being seen
If things go that way, you will end up in court (and probably win). I have never heard of a case that went to court but I know many cases that the bank (or the merchant) just paid up. But if you just accept the bullshit a low management bank employee tells you, you are screwed anyway. Nevertheless if the bank is determined not to pay it is gonna get ugly
In order for the transaction to be authorized by the server, the PIN is encrypted and sent by the terminal using a symmetric key that the bank gives the terminal vendor. So no this is not possible
If you can't *prove* a crime was committed, they don't have to pay.
If they can't prove a transaction was initiated by you then you don't have to pay
In case of a dispute of a transaction with a magnetic card (and sometimes with EMV cards), in order for the bank to prove that the transaction is legitimate the receipt must have a signature that matches the signature on your ID. If the signature is not the same according to law you have no obligation of paying up and if the amount is big enough you can sue the bank or just don't pay the amount and wait to get sued by the bank.
The main reason magnetic cards were replaced by EMV cards is that the fraud costs had to be covered by the bank and by the merchant (because they did not check an ID). With EMV cards if a signature is not required and somehow someone makes a transaction with your card, you are screwed
Actually in the EMV specifications the terminal has to authenticate the card via a key exchange, however this is not used to encrypt the communication between the card and the terminal.
On the bright side this attack can only work on offline transactions which must be below a bank specified floor limit (the upper limit that the transaction can be authorized on the floor). For online transactions the PIN is also sent to the bank so this will fail. In practice some banks have a zero floor limit so all transactions have to be authorized online. Even if the floor limit is not zero, it never is over about 10 euro or something like that
No. If you get a gun and start pointing it at people you will be arrested, even though you didn't kill anyone (assuming that gun possession is legal)
The salt can be user and website dependent (4 bytes user/4 bytes website for an 8 byte salt). Although I think that the added complexity won't be welcomed by the website owners
The salt is not exactly supposed to be obscure. If it was then it would be just a password, and this is not the case as it would be called a password and not a salt. The salt should be available to the entities generating the hash (in this case the web sites). Now find me a practical way to distribute the salt to the legitimate web sites without the bad guys knowing...
The email matching process for 80871 users takes about one hour (from TFA). Adding a three digit salt would increase the matching process to 999 hours or about 41 days which is not much considering that this is a brute force attack and I believe the user would be unwilling to remember a salt longer than 3 digits. An alternative would be if gravatar would automatically generate a salt and the web site could retrieve this salt (over ssl maybe, for the paranoid among us) on user registration. Then again the user must authorize which sites can retrieve the salt (through an email authorization link maybe?) which would also add complexity to the registration process.