Topic: Copying a visa card? (Read 1412 times)
It is possible but that is a fraud however why are duplicating the card information or plastic if you the rightful owner.
Thank you for explaing it really helped, but i am still not 100% sure i mean when i read about ACID on vikipedia there were no atms mentioned only sending from A to B some errors power loss was mentioned on it.
Power loss is just one example. Here is a very simplified example (real DBMS are more robust). There is a CC account with a balance of $4000 and the card is duplicated. Two attackers start using the ATM at the same time trying to each withdraw $400. They attempt to execute the withdraw as close to simultaneous as possibly by remaining in communication with each other.
Lets ignore the fact that both ATMs are reporting this to the same central location so it is trivially easy for the bank to detect that the same card is being used simultaneously in two different locations (something that can't happen in fraud) and just confiscate both cards as a precaution. Regardless of how well timed the attackers are, one request will be processed first. The A in ACID means that all steps in one logical operation such as withdrawing cash are done as a single atomic operation. Either they all complete or none of them do. The I means that all atomic operations will always have the same outcome as if they were processed sequentially even if the database is handling multiple requests in parallel.
To keep it simple lets say this ATM protocol has three steps in the withdraw cash operation:
Check balance is greater than or equal to withdraw_amount
Dispense withdraw_amount
Deduct amount from balance
I am assuming you think the attack could work like this (T1 is steps for transaction 1, and T2 is steps for transactions 2):
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 check balance ($400) is greater than or equal to $400 = TRUE
T1 dispense $400
T2 dispense $400
T1 deduct $400 from balance. Balance = $0
T2 deduct $400 from balance. Balance = -$400.
Attackers win, $800 dispensed from account with only a $400 balance.
The reality is this problem was solved more than fifty years ago, what actually happens is:
T1 CHECK TO SEE IF EXISTING TX IS IN PROGRESS (if true then wait otherwise start a new transaction)
T1 START TRANSACTION
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS (if true then wait otherwise start a new transaction) <- this is true because T1 transaction is still in progress so the request will just halt and wait
T1 dispense $400
T1 deduct $400 from balance. Balance = $0
T1 TRANSACTION COMMIT
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS (if true then wait otherwise start a new transaction)
T2 START TRANSACTION
T2 check balance $0 is greater than or equal to $400 = FALSE
T2 report insufficient funds
T2 TRANSACTION COMMIT
All Bitcoin exchanges (or any system processing financial requests) should operate the same way. This is very basic fundamentals of database operations. Sadly many exchanges have been created by people who lack even the basic understanding of transaction processing. They have in the past been attacked in a manner similar to the flawed ATM attack model. They attacks should have failed but they didn't and users lost small fortunes. I am sure more than one exchange is still vulnerable to similar attacks today.
I'm not seeing the logic error there, :p. Unless it has to do with checking the balances (and in that time period another transaction could have altered one or both balances, such that the balance in acct 9001 may not still be 900+).
Well upon reflection it isn't the best example as it may not be a problem under all DBMS in all configurations. However under some conditions it would be possible to make the balance check on a second transfer request before the explicit transaction statement executes on the first transfer operation. Thus you were on the right track, the balance check may result in the application being non ACID compliant because it allows a stale read. If we serialize it out the execution could look like this
Code:
T1: if 900 < 900
T2: if 900 < 900
T1: start transaction <- no existing transaction so execution can continue
T2: start transaction <- T1 transaction in progress so halt (but the damage is already done)
....
T2: if 900 < 900
T1: start transaction <- no existing transaction so execution can continue
T2: start transaction <- T1 transaction in progress so halt (but the damage is already done)
....
Now there may be configurations where the code above "might" be safe but I don't like it because it is fragile code. A change in configuration could result in it failing. As a result I prefer everything inside the explicit transaction (the check is part of the atomic operation).
Code:
start transaction
if (select balance from account where Account_Number='9001') < 900
rollback; //if user has insufficient balance then abort
else
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
endif
commit; //if all sql queries succeed
if (select balance from account where Account_Number='9001') < 900
rollback; //if user has insufficient balance then abort
else
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
endif
commit; //if all sql queries succeed
Note that code is still a simplified example. Production code should obviously be more robust. I prefer using a try-catch pattern with exceptions.
Code:
BEGIN TRANSACTION
BEGIN TRY
COMMIT
END TRY
BEGIN CATCH
ROLLBACK
END CATCH
BEGIN TRY
COMMIT
END TRY
BEGIN CATCH
ROLLBACK
END CATCH
So yes the dbms prevents you from needing to re-invent the wheel but like any tool you need to use it properly for it to work as expected.
For example what is wrong with this:
Code:
if (select balance from account where Account_Number='9001') < 900
return false
else
start transaction
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
commit; //if all sql queries succeed
return true
endif
return false
else
start transaction
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
commit; //if all sql queries succeed
return true
endif
The top part verifies whether or not the balance is there. The bottom should be fine as well (logically) since it verified that the account that's being withdrawn from has enough balance already, and the second account's balance should be irrelevant since it's adding on to, not removing from.
I'm not seeing the logic error there, :p. Unless it has to do with checking the balances (and in that time period another transaction could have altered one or both balances, such that the balance in acct 9001 may not still be 900+).
Don't know if this helps, but most modern db's don't do dirty writes.
If "dirty write" means the exploit mentioned previously (with two transactions hitting at once), wouldn't that mean that none of the exchanges (being that they should all be using modern DB's) should be exploitable? That would go against what was stated earlier.
But then a lot of developers circumvent this to optimize speed. Which then leads to the flaws.. Yes, locking sucks and could lead to deadlock contentions, but I rather have a contention than some of the ridiculous things they allow. I don't feel the fiat industry does things like bitcoin exchanges.
Ahhh, I get you now. So basically people take the "easy" way out and get screwed as a result. Seems like there's a life lesson in here somewhere, :p.
A database can't prevent a dirty write (as an example) if you don't inform it that a sequence of transactions are atomic.
Code:
start transaction
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
commit; //if all sql queries succeed
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
commit; //if all sql queries succeed
This is a very simple example and it should have some error checking before making the change (otherwise) you could end up with balances of {-900,1800}. The start transaction and commit commands instruct the database that everything between them is a single atomic operation. Either all updates are successful or none of them are. If the database crashed, or has a powerloss prior to the commit then the partially complete transaction would be rolled back. The same operations without the explicit transaction could be subject to a flooding attack (even if balances were checked).
The DBMS handles the low level plumbing but the developers needs to use those capabilities to ensure the application is also ACID compliant.
For example what is wrong with this:
Code:
if (select balance from account where Account_Number='9001') < 900
return false
else
start transaction
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
commit; //if all sql queries succeed
return true
endif
return false
else
start transaction
select balance from Account where Account_Number='9001';
select balance from Account where Account_Number='9002';
update Account set balance=balance-900 here Account_Number='9001' ;
update Account set balance=balance+900 here Account_Number='9002' ;
commit; //if all sql queries succeed
return true
endif
Don't know if this helps, but most modern db's don't do dirty writes.
If "dirty write" means the exploit mentioned previously (with two transactions hitting at once), wouldn't that mean that none of the exchanges (being that they should all be using modern DB's) should be exploitable? That would go against what was stated earlier.
But then a lot of developers circumvent this to optimize speed. Which then leads to the flaws.. Yes, locking sucks and could lead to deadlock contentions, but I rather have a contention than some of the ridiculous things they allow. I don't feel the fiat industry does things like bitcoin exchanges.
Ahhh, I get you now. So basically people take the "easy" way out and get screwed as a result. Seems like there's a life lesson in here somewhere, :p.
Exactly
Don't know if this helps, but most modern db's don't do dirty writes.
If "dirty write" means the exploit mentioned previously (with two transactions hitting at once), wouldn't that mean that none of the exchanges (being that they should all be using modern DB's) should be exploitable? That would go against what was stated earlier.
But then a lot of developers circumvent this to optimize speed. Which then leads to the flaws.. Yes, locking sucks and could lead to deadlock contentions, but I rather have a contention than some of the ridiculous things they allow. I don't feel the fiat industry does things like bitcoin exchanges.
Ahhh, I get you now. So basically people take the "easy" way out and get screwed as a result. Seems like there's a life lesson in here somewhere, :p.
Don't know if this helps, but most modern db's don't do dirty writes.
If "dirty write" means the exploit mentioned previously (with two transactions hitting at once), wouldn't that mean that none of the exchanges (being that they should all be using modern DB's) should be exploitable? That would go against what was stated earlier.
But then a lot of developers circumvent this to optimize speed. Which then leads to the flaws.. Yes, locking sucks and could lead to deadlock contentions, but I rather have a contention than some of the ridiculous things they allow. I don't feel the fiat industry does things like bitcoin exchanges.
Don't know if this helps, but most modern db's don't do dirty writes.
If "dirty write" means the exploit mentioned previously (with two transactions hitting at once), wouldn't that mean that none of the exchanges (being that they should all be using modern DB's) should be exploitable? That would go against what was stated earlier.
Thank you for explaing it really helped, but i am still not 100% sure i mean when i read about ACID on vikipedia there were no atms mentioned only sending from A to B some errors power loss was mentioned on it.
Power loss is just one example. Here is a very simplified example (real DBMS are more robust). Card has a balance of $400. User duplicates card and two users start using ATM at the same time trying to each withdraw $400 at the "same time". Lets ignore the fact that both ATMs are reporting this to the same central location so it is trivially easy for the bank to detect that the same card is being used simultaneously in two different locations (something that can't happen in fraud) and just confiscate both cards as a precaution.
Regardless of how well timed the attackers are, one request will be processed first. The A in ACID means that all steps in one logical operation such as withdrawing cash are done as a single atomic operation. Either they all complete or none of them do. The I means that all operations will always have the same outcome as if they were processed sequentially.
This super simple ATM has three steps in the withdraw cash operation:
Check balance is greater than or equal to withdraw_amount
Dispense withdraw_amount
Deduct amount from balance
I am assuming you think the attack could work like this (T1 is steps for transaction 1, and T2 is steps for transactions 2).
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 check balance ($400) is greater than or equal to $400 = TRUE
T1 dispense $400
T2 dispense $400
T1 deduct $400 from balance. Balance = $0
T2 deduct $400 from balance. Balance = -$400.
Attackers win, $800 dispensed from account with only a $400 balance. The reality is this problem was solved more than fifty years ago. What actually happens
T1 CHECK TO SEE IF EXISTING TX IS IN PROGRESS = FALSE (start a new transaction)
T1 START TRANSACTION
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS = TRUE (wait and check later)
T1 dispense $400
T1 deduct $400 from balance. Balance = $0
T1 TRANSACTION COMMIT
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS = FALSE (start a new transaction)
T2 START TRANSACTION
T2 check balance $0 is greater than or equal to $400 = FALSE
T2 report insufficient funds
T2 TRANSACTION COMMIT
All Bitcoin exchanges (or any system processing financial requests) should operate the same way. This is very basic fundamentals of database operations. Sadly many exchanges have been created by people who lack even the basic understanding of transaction processing. They have in the past been attacked in a manner similar to the flawed ATM attack model. They attacks should have failed but they didn't and users lost small fortunes. I am sure more than one exchange is still vulnerable to similar attacks today.
Thanks for that very graphical explanation. I wasn't aware that's how things worked either. I don't quite get how the databases are supposed to manage knowing whether or not another write is waiting though. I am one of the people who can code and all, but how do you code in such a way as to determine if you're waiting for something to write to the DB? I think I'm missing the "logic" part of it.
Don't know if this helps, but most modern db's don't do dirty writes.
Thank you for explaing it really helped, but i am still not 100% sure i mean when i read about ACID on vikipedia there were no atms mentioned only sending from A to B some errors power loss was mentioned on it.
Power loss is just one example. Here is a very simplified example (real DBMS are more robust). Card has a balance of $400. User duplicates card and two users start using ATM at the same time trying to each withdraw $400 at the "same time". Lets ignore the fact that both ATMs are reporting this to the same central location so it is trivially easy for the bank to detect that the same card is being used simultaneously in two different locations (something that can't happen in fraud) and just confiscate both cards as a precaution.
Regardless of how well timed the attackers are, one request will be processed first. The A in ACID means that all steps in one logical operation such as withdrawing cash are done as a single atomic operation. Either they all complete or none of them do. The I means that all operations will always have the same outcome as if they were processed sequentially.
This super simple ATM has three steps in the withdraw cash operation:
Check balance is greater than or equal to withdraw_amount
Dispense withdraw_amount
Deduct amount from balance
I am assuming you think the attack could work like this (T1 is steps for transaction 1, and T2 is steps for transactions 2).
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 check balance ($400) is greater than or equal to $400 = TRUE
T1 dispense $400
T2 dispense $400
T1 deduct $400 from balance. Balance = $0
T2 deduct $400 from balance. Balance = -$400.
Attackers win, $800 dispensed from account with only a $400 balance. The reality is this problem was solved more than fifty years ago. What actually happens
T1 CHECK TO SEE IF EXISTING TX IS IN PROGRESS = FALSE (start a new transaction)
T1 START TRANSACTION
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS = TRUE (wait and check later)
T1 dispense $400
T1 deduct $400 from balance. Balance = $0
T1 TRANSACTION COMMIT
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS = FALSE (start a new transaction)
T2 START TRANSACTION
T2 check balance $0 is greater than or equal to $400 = FALSE
T2 report insufficient funds
T2 TRANSACTION COMMIT
All Bitcoin exchanges (or any system processing financial requests) should operate the same way. This is very basic fundamentals of database operations. Sadly many exchanges have been created by people who lack even the basic understanding of transaction processing. They have in the past been attacked in a manner similar to the flawed ATM attack model. They attacks should have failed but they didn't and users lost small fortunes. I am sure more than one exchange is still vulnerable to similar attacks today.
Thanks for that very graphical explanation. I wasn't aware that's how things worked either. I don't quite get how the databases are supposed to manage knowing whether or not another write is waiting though. I am one of the people who can code and all, but how do you code in such a way as to determine if you're waiting for something to write to the DB? I think I'm missing the "logic" part of it.
Thank you for explaing it really helped, but i am still not 100% sure i mean when i read about ACID on vikipedia there were no atms mentioned only sending from A to B some errors power loss was mentioned on it.
Power loss is just one example. Here is a very simplified example (real DBMS are more robust). There is a CC account with a balance of $4000 and the card is duplicated. Two attackers start using the ATM at the same time trying to each withdraw $400. They attempt to execute the withdraw as close to simultaneous as possibly by remaining in communication with each other.
Lets ignore the fact that both ATMs are reporting this to the same central location so it is trivially easy for the bank to detect that the same card is being used simultaneously in two different locations (something that can't happen in fraud) and just confiscate both cards as a precaution. Regardless of how well timed the attackers are, one request will be processed first. The A in ACID means that all steps in one logical operation such as withdrawing cash are done as a single atomic operation. Either they all complete or none of them do. The I means that all atomic operations will always have the same outcome as if they were processed sequentially even if the database is handling multiple requests in parallel.
To keep it simple lets say this ATM protocol has three steps in the withdraw cash operation:
Check balance is greater than or equal to withdraw_amount
Dispense withdraw_amount
Deduct amount from balance
I am assuming you think the attack could work like this (T1 is steps for transaction 1, and T2 is steps for transactions 2):
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 check balance ($400) is greater than or equal to $400 = TRUE
T1 dispense $400
T2 dispense $400
T1 deduct $400 from balance. Balance = $0
T2 deduct $400 from balance. Balance = -$400.
Attackers win, $800 dispensed from account with only a $400 balance.
The reality is this problem was solved more than fifty years ago, what actually happens is:
T1 CHECK TO SEE IF EXISTING TX IS IN PROGRESS (if true then wait otherwise start a new transaction)
T1 START TRANSACTION
T1 check balance ($400) is greater than or equal to $400 = TRUE
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS (if true then wait otherwise start a new transaction) <- this is true because T1 transaction is still in progress so the request will just halt and wait
T1 dispense $400
T1 deduct $400 from balance. Balance = $0
T1 TRANSACTION COMMIT
T2 CHECK TO SEE IF EXISTING TX IS IN PROGRESS (if true then wait otherwise start a new transaction)
T2 START TRANSACTION
T2 check balance $0 is greater than or equal to $400 = FALSE
T2 report insufficient funds
T2 TRANSACTION COMMIT
All Bitcoin exchanges (or any system processing financial requests) should operate the same way. This is very basic fundamentals of database operations. Sadly many exchanges have been created by people who lack even the basic understanding of transaction processing. They have in the past been attacked in a manner similar to the flawed ATM attack model. They attacks should have failed but they didn't and users lost small fortunes. I am sure more than one exchange is still vulnerable to similar attacks today.
No it isn't possible because unlike some Bitcoin exchanges banks learned about the concept of ACID compliant transactions about forty years ago. BTW there is no money "in the card" just like there is no car hidden inside your car key. The key and card are just access mechanisms.
Well said sir !
I just wonder if it is possible for a hacker to use 3D printer to replicate a VISA/MasterCard ?
Well I am not going to help you engage in credit card fraud but it is trivially easy to produce fake magnetic based credit cards. They essentially have absolutely no security (like bitcoin wallet with the private key written right on the front and broadcast in plaintext). This is a big reason the industry is moving to chip & pin based cards because magnetic based cards are horribly insecure.
I seriously think that being able to use credit cards online is a terrible idea. At a physical store, they will at least request a signature, but online, no signature, no password, just have Card No., Expiry date, CVV and you're all set.
I really don't understand the point of CVV.. I thought it's intention was to show you had the card, but since it's needed just as much as the creditcard number, name and date, I just think it's a waste. Once, someone has your data, they have your data.
The credit card number (and other information) can remain the same while the CVV changes. For example, when I requested my custom-picture card, I got one that had identical information but a changed CVV. So it does serve its purpose (as limited as that may be).
No it isn't possible because unlike some Bitcoin exchanges banks learned about the concept of ACID compliant transactions about forty years ago. BTW there is no money "in the card" just like there is no car hidden inside your car key. The key and card are just access mechanisms.
Well said sir !
I just wonder if it is possible for a hacker to use 3D printer to replicate a VISA/MasterCard ?
Well I am not going to help you engage in credit card fraud but it is trivially easy to produce fake magnetic based credit cards. They essentially have absolutely no security (like bitcoin wallet with the private key written right on the front and broadcast in plaintext). This is a big reason the industry is moving to chip & pin based cards because magnetic based cards are horribly insecure.
I seriously think that being able to use credit cards online is a terrible idea. At a physical store, they will at least request a signature, but online, no signature, no password, just have Card No., Expiry date, CVV and you're all set.
I really don't understand the point of CVV.. I thought it's intention was to show you had the card, but since it's needed just as much as the creditcard number, name and date, I just think it's a waste. Once, someone has your data, they have your data.
No it isn't possible because unlike some Bitcoin exchanges banks learned about the concept of ACID compliant transactions about forty years ago. BTW there is no money "in the card" just like there is no car hidden inside your car key. The key and card are just access mechanisms.
Well said sir !
I just wonder if it is possible for a hacker to use 3D printer to replicate a VISA/MasterCard ?
No because you cannot reproduce the magnetic stripe correctly. And you don't need a hacker to use a 3D printer.
and you dont need a 3d printer to do it .. anything that has a magstripe will work and all you need is a mag reader and writer I might even have a msr506 somewhere in the garage still...
to answer the ops question yes you can copy the info on a credit card rather easy .. but if the balance isnt there to support it then its pointless..
and depending on what bank supports the card there fraud algorithm should pick up its being used in two different areas in a rather short period of time.
I seriously think that being able to use credit cards online is a terrible idea. At a physical store, they will at least request a signature, but online, no signature, no password, just have Card No., Expiry date, CVV and you're all set.
My bank doesn't allow transactions from foreign countries without permission, also my billing zip code and the shipping zip code has to match when purchasing online. If you're going to use a dummy card why not just get a CC programmer and make the numbers anything you want, I seen it on mythbusters once.
Lucky for you, we in Spain here don't have that option. Literally no security at all.
A secure password will be enough, but I have no idea why that isn't implemented.
I've seen sites even in the US where no security is there. I've used the card at places where they don't even need the CVC code or whatever it is on the back. And most stores here (physical) don't need to verify cards either. If you purchase less than, I think it's $25, at Walmart, for example, you don't even sign for it. Just swipe real quick and go. Same goes for gas in all cases (*some* will require a zip code, but that's rare).
We were talking about credit cards, and what I meant is that nobody ever has to see your card as long as it's under a certain dollar amount. Plus you don't have to sign anything. You can grab $31 (I'm not sure the cap, but had a purchase the other day of $30.XX) worth of stuff at Walmart, have the checkout person ring up your stuff, swipe your card in the credit card system real quick, and move on as no signature is needed and no visual verification.
Above $35 (I guess? I'm not sure) they require you to sign for it. Above like $150-200, they also have to visually inspect the card.
I seriously think that being able to use credit cards online is a terrible idea. At a physical store, they will at least request a signature, but online, no signature, no password, just have Card No., Expiry date, CVV and you're all set.
My bank doesn't allow transactions from foreign countries without permission, also my billing zip code and the shipping zip code has to match when purchasing online. If you're going to use a dummy card why not just get a CC programmer and make the numbers anything you want, I seen it on mythbusters once.
Lucky for you, we in Spain here don't have that option. Literally no security at all.
A secure password will be enough, but I have no idea why that isn't implemented.
I've seen sites even in the US where no security is there. I've used the card at places where they don't even need the CVC code or whatever it is on the back. And most stores here (physical) don't need to verify cards either. If you purchase less than, I think it's $25, at Walmart, for example, you don't even sign for it. Just swipe real quick and go. Same goes for gas in all cases (*some* will require a zip code, but that's rare).
No it isn't possible because unlike some Bitcoin exchanges banks learned about the concept of ACID compliant transactions about fourty years ago. BTW there is no money "in the card" just like there is no car hidden inside your car key. The key and card are just access mechanisms.
Thank you for explaing it really helped, but i am still not 100% sure i mean when i read about ACID on vikipedia there were no atms mentioned only sending from A to B some errors power loss was mentioned on it. I seriously think that being able to use credit cards online is a terrible idea. At a physical store, they will at least request a signature, but online, no signature, no password, just have Card No., Expiry date, CVV and you're all set.
My bank doesn't allow transactions from foreign countries without permission, also my billing zip code and the shipping zip code has to match when purchasing online. If you're going to use a dummy card why not just get a CC programmer and make the numbers anything you want, I seen it on mythbusters once.
Lucky for you, we in Spain here don't have that option. Literally no security at all.
A secure password will be enough, but I have no idea why that isn't implemented.
I've seen sites even in the US where no security is there. I've used the card at places where they don't even need the CVC code or whatever it is on the back. And most stores here (physical) don't need to verify cards either. If you purchase less than, I think it's $25, at Walmart, for example, you don't even sign for it. Just swipe real quick and go. Same goes for gas in all cases (*some* will require a zip code, but that's rare).
I seriously think that being able to use credit cards online is a terrible idea. At a physical store, they will at least request a signature, but online, no signature, no password, just have Card No., Expiry date, CVV and you're all set.
My bank doesn't allow transactions from foreign countries without permission, also my billing zip code and the shipping zip code has to match when purchasing online. If you're going to use a dummy card why not just get a CC programmer and make the numbers anything you want, I seen it on mythbusters once.
Lucky for you, we in Spain here don't have that option. Literally no security at all.
A secure password will be enough, but I have no idea why that isn't implemented.
Yes, like said you wouldn't be able to double spend you funds if you did infact replicate the card. The money isn't actually stored on the card but rather a key to where your funds are located!
Yeah, that's right. Good thing the latest version of BitcoinGenerator2014 still lets you create gazillions of bitcoins for free!
That thing is simply hilarious.
Jump to: