NZ is also (mostly) immune to these problems because banks don't store PINs. All transactions are done online to one big server which has very tight access controls.
The vulnerability requires that you have access to the bank's server and can submit arbitrary function calls to it.
To hack by saving the messages -- assuming that you can intercept and you have a way to generate your own messages, not a trivial assumption -- but then you will still take the 5,000 odd guesses to get the PIN right because you do not have access to specify a decimalisation table, as is required for this attack
You underestimate the unwashed. There are still people around who find the current ATMs scary.
How about a complete overhaul of IPv4 because we're running out of class B addresses? Answers:
- Not everyone agrees on the new protocol
- Can't co-ordinate mass switchover
- Nobody wants to pay for its development
- It's easier to introduce subnetting to avoid the problem
and so on and so forth. BTW 16 digits is good enough. The current system can have longer PINs phased in over time. A lot of the software and HSMs support PINs of up to 12 digits. Perhaps if one bank takes the initiative and upgrades their equipment to 6-digit PINs, customers will join that bank because of security. But perhaps more likely, they will not join it because 6 digits is harder to remember.
Changing software is not as easy in the banking world as it is in the PC world. Any code change has to be audited and approved by authorities, this can take months. Also, installing the new software has to be done in such a way that there is no downtime for the servers.
The vulnerability applies to programmers who have direct access to the database where the PINs are stored. It tells how they can be clever in supplying parameters to the PIN verification API to deduce the correct PIN quickly.
Here they use X.25 (traveling via the PSTN to get to the X.25 network). The X.25 protocol includes security so that you can't forge a source address. The communications aspect is considered to be secure, which is why this attack is happening at the HSM level.
Actually it does. Under the scheme discussed in the article (used by some organizations but not all), they calculate a PIN for you, and when you specify your PIN they store the calculated value and the difference between the two (in clear text). So it seems to you as if you have chosen your own PIN.
How is this better than the coin actually being worth 50c and the merchant sending all the coins with their real values to Peppercoin at the end of the [day / month /...]
The only conceivable advantage I can see in the random coin value is that encrypting the coin is only a matter of encrypting True or False, rather than encrypting an arbitrary integer. So if the coin is hacked then no useful information comes out. Consider then this scenario: I pay for something, and hack my coin and discover it was False. I then go and buy many more things off the website with the same coin. I get free stuff because PepperCoin didnt issue me any new coins so I dont get charged. This is bad, therefore either the Merchant has to validate coins in realtime with PepperCoin (defeating the point), or the coin has to contain other info (eg. trace number, product code), and the Merchant has to be able to decrypt the coin (defeating the coin security). What gives?
Mod this up! Working in the industry, I know how stupidly cheap transactions *should* be, and how expensive they turn out because of greed from the acquirers and the telecommunications companies.
However, I would say that the transaction fee charged is mainly insurance against the huge cost of CC fraud. I wonder if Visa etc. could be persuaded to offer bulk transactions with low / no fees to Peppercoin and other companies, as long as those companies agreed to accept the fraud liability.
So which of the following happens, if a customer buys one 50c MP3 and never buys anything for the rest of his life:
a) His CC never gets charged b) His CC gets charged 50c immediately c) His CC gets charged 50c after a set period of time d) His CC gets charged $10 immediately e) There's a % chance his CC gets charged $10 immediately, otherwise never charge f) There's a % chance his CC gets charged 50c immediately, otherwise never charged
It seems to be that (a) means free goods, (b) means no saving in CC charges, (d) is unfair, (e) means maybe free goods, and (f) is gambling, so probably (c) is correct?
But if (c) or (d) is correct, then PepperCoin is acting as a bank -- ie. the same as Paypal and thus free to rip everybody off with no recourse. Sucky. At least I'd trust Rivest more than I'd trust Paypal.
Next question: the Peppercoin website suggests that the coin is like a cheque, and the merchant collects all the customer's coins and then redeems them to PepperCoin. So why can't each coin contain the actual transaction value? Peppercoin would then aggregate the merchant's coins after a set period and credit the merchant's account.
How is this better than PepperCoin giving the merchant his credit at regular intervals (eg. once $10 has accumulated), like how the customer is billed at regular intervals?
It seems none of us (including me) actually understand the PepperCoin scheme. The linked article certainly doesn't explain how it works.
Not true - posts below the viewer's threshhold are not visible even if it has sub-posts above the threshhold. This is really stupid and makes for disjointed conversation (if you detect disjointed conversation you have to click the 'Parent' link to see the low post).
Therefore, I suggest you help out fellow trolls by using your account to post a sensible reply to the troll that will not get modded down and will make people click the Parent link, so that it can get moded up.
Not really, the original poster is just being confusing. According to Newton, if A exerts force on B then B exerts force on A. Centripetal and centrifugal are actually the same thing. You won't go wrong if you draw your force diagram with centrifugal force.
Not. Heat from air friction is negligible. Stuff burns up from the heat of pressure from compressing the air in front of it. Incidentally, the space elevator will be orbiting with the atmosphere, so there will be no such heat.
My guess would be this: when you do an HTTP download, your ISP's transparent proxy schwomps the file down on its fat pipes, so the speed you end up seeing is only limited by your connection to your ISP (usually,maximum speed). However with FTP every packet is going direct from you to the server, which can have delays and so on.
Slashdot Mirror
The dupes stop..
NZ is also (mostly) immune to these problems because banks don't store PINs. All transactions are done online to one big server which has very tight access controls.
The vulnerability requires that you have access to the bank's server and can submit arbitrary function calls to it.
To hack by saving the messages -- assuming that you can intercept and you have a way to generate your own messages, not a trivial assumption -- but then you will still take the 5,000 odd guesses to get the PIN right because you do not have access to specify a decimalisation table, as is required for this attack
Who modded this as informative? If the poster had read the article, he would have seen that it is the bank servers (HSMs) that are being exploited.
You underestimate the unwashed. There are still people around who find the current ATMs scary.
How about a complete overhaul of IPv4 because we're running out of class B addresses? Answers:
- Not everyone agrees on the new protocol
- Can't co-ordinate mass switchover
- Nobody wants to pay for its development
- It's easier to introduce subnetting to avoid the problem
and so on and so forth. BTW 16 digits is good enough. The current system can have longer PINs phased in over time. A lot of the software and HSMs support PINs of up to 12 digits. Perhaps if one bank takes the initiative and upgrades their equipment to 6-digit PINs, customers will join that bank because of security. But perhaps more likely, they will not join it because 6 digits is harder to remember.
Changing software is not as easy in the banking world as it is in the PC world. Any code change has to be audited and approved by authorities, this can take months. Also, installing the new software has to be done in such a way that there is no downtime for the servers.
When was the last time there was a court case where the defence didn't tell lies?
Rubbish. For example, you can prove mathematically that RSA is secure. You can do the same for other systems.
The vulnerability applies to programmers who have direct access to the database where the PINs are stored. It tells how they can be clever in supplying parameters to the PIN verification API to deduce the correct PIN quickly.
Here they use X.25 (traveling via the PSTN to get to the X.25 network). The X.25 protocol includes security so that you can't forge a source address. The communications aspect is considered to be secure, which is why this attack is happening at the HSM level.
Actually it does. Under the scheme discussed in the article (used by some organizations but not all), they calculate a PIN for you, and when you specify your PIN they store the calculated value and the difference between the two (in clear text). So it seems to you as if you have chosen your own PIN.
This isn't security through obscurity - unless you would include in "obscurity" the need to keep your password secret!
I thought we all hated Covad ?
So the benefit of the scheme is actually that it saves Peppercoin's hard drive space, and not anything to do with transaction costs?
How is this better than the coin actually being worth 50c and the merchant sending all the coins with their real values to Peppercoin at the end of the [day / month / ...]
The only conceivable advantage I can see in the random coin value is that encrypting the coin is only a matter of encrypting True or False, rather than encrypting an arbitrary integer. So if the coin is hacked then no useful information comes out. Consider then this scenario: I pay for something, and hack my coin and discover it was False. I then go and buy many more things off the website with the same coin. I get free stuff because PepperCoin didnt issue me any new coins so I dont get charged. This is bad, therefore either the Merchant has to validate coins in realtime with PepperCoin (defeating the point), or the coin has to contain other info (eg. trace number, product code), and the Merchant has to be able to decrypt the coin (defeating the coin security). What gives?
Mod this up! Working in the industry, I know how stupidly cheap transactions *should* be, and how expensive they turn out because of greed from the acquirers and the telecommunications companies.
However, I would say that the transaction fee charged is mainly insurance against the huge cost of CC fraud. I wonder if Visa etc. could be persuaded to offer bulk transactions with low / no fees to Peppercoin and other companies, as long as those companies agreed to accept the fraud liability.
So which of the following happens, if a customer buys one 50c MP3 and never buys anything for the rest of his life:
a) His CC never gets charged
b) His CC gets charged 50c immediately
c) His CC gets charged 50c after a set period of time
d) His CC gets charged $10 immediately
e) There's a % chance his CC gets charged $10 immediately, otherwise never charge
f) There's a % chance his CC gets charged 50c immediately, otherwise never charged
It seems to be that (a) means free goods, (b) means no saving in CC charges, (d) is unfair, (e) means maybe free goods, and (f) is gambling, so probably (c) is correct?
But if (c) or (d) is correct, then PepperCoin is acting as a bank -- ie. the same as Paypal and thus free to rip everybody off with no recourse. Sucky. At least I'd trust Rivest more than I'd trust Paypal.
Next question: the Peppercoin website suggests that the coin is like a cheque, and the merchant collects all the customer's coins and then redeems them to PepperCoin. So why can't each coin contain the actual transaction value? Peppercoin would then aggregate the merchant's coins after a set period and credit the merchant's account.
How is this better than PepperCoin giving the merchant his credit at regular intervals (eg. once $10 has accumulated), like how the customer is billed at regular intervals?
It seems none of us (including me) actually understand the PepperCoin scheme. The linked article certainly doesn't explain how it works.
Same reason they trust Visa and Mastercard
Not true - posts below the viewer's threshhold are not visible even if it has sub-posts above the threshhold. This is really stupid and makes for disjointed conversation (if you detect disjointed conversation you have to click the 'Parent' link to see the low post).
Therefore, I suggest you help out fellow trolls by using your account to post a sensible reply to the troll that will not get modded down and will make people click the Parent link, so that it can get moded up.
Maybe these dupe stories are practise versions of a stock split
Geez, howcome I got modded to -1 and lost my karma bonus for posting the same comment on a previous dupe.
Genetic mutation allowed X
where X is an element of { all evolutionary developments in human history }
Not really, the original poster is just being confusing. According to Newton, if A exerts force on B then B exerts force on A. Centripetal and centrifugal are actually the same thing. You won't go wrong if you draw your force diagram with centrifugal force.
Not. Heat from air friction is negligible. Stuff burns up from the heat of pressure from compressing the air in front of it. Incidentally, the space elevator will be orbiting with the atmosphere, so there will be no such heat.
My guess would be this: when you do an HTTP download, your ISP's transparent proxy schwomps the file down on its fat pipes, so the speed you end up seeing is only limited by your connection to your ISP (usually,maximum speed). However with FTP every packet is going direct from you to the server, which can have delays and so on.