Copying a visa card?

[nitehawk]

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.

[1714220182]

1714220182

[1714220182]

1714220182

[1714220182]

1714220182

[dmpotter]

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.

[ranlo]

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).

[DeathAndTaxes]

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.

[ranlo]

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.

[dmpotter]

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.

[ranlo]

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.

[dmpotter]

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.

[ranlo]

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.

[dmpotter]

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 

[DeathAndTaxes]

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

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

[ranlo]

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

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+).

[DeathAndTaxes]

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)
....

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

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
      <operations which may throw exceptions>
      COMMIT
   END TRY
   BEGIN CATCH
      ROLLBACK
      <exception logging>   
   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. 

[yakuza699]

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.

Thank you for explaining again now i have no doubts that this doesn't work.

[princecash]

It is possible but that is a fraud however why are duplicating the card information or plastic if you the rightful owner.