Copying a visa card?

[yakuza699]

Hello everyone, i want to ask if this would be possible if i would send you the card (anonymous visa prepaid card) or it's info  and you would create a card just like i sent to you and is it possible to double-spend  then i have both cards i mean two people come to different ATM's in different parts of the world insert the card same time and withdraw all money that is in card same time? Is there any other way to double-spend the money that is in those cards (not physical ) if so pm me. I would be happy to pay 30$=0.069BTC as same as card costs for copying the card.

Best regards,
yakuza699

[1714202062]

1714202062

[1714202062]

1714202062

[1714202062]

1714202062

[1714202062]

1714202062

[1714202062]

1714202062

[DeathAndTaxes]

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.

[newIndia]

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 ?

[byt411]

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.

[DeathAndTaxes]

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 make bit for bit exact duplicates of magnetic based credit cards.   They have absolutely no security.  It would be like a bitcoin wallet with the private key written right on the front and broadcast in plaintext to anyone you buy goods from (or anyone else who happens to be listening).  

This is a big reason the industry is moving towards chip & pin based cards, magnetic based cards are horribly insecure.

[byt411]

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.

[newIndia]

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.

Where did I say I need a hacker ?  I said if it is possible for a hacker !!! U r seriously...

[newIndia]

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 have absolutely no security.  It would be like a bitcoin wallet with the private key written right on the front and broadcast in plaintext to anyone you buy goods from (or anyone else who happens to be listening).  

This is a big reason the industry is moving towards chip & pin based cards, magnetic based cards are horribly insecure.

So, does it mean a 3D printer can reproduce a magnetic tape ?

[byt411]

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 have absolutely no security.  It would be like a bitcoin wallet with the private key written right on the front and broadcast in plaintext to anyone you buy goods from (or anyone else who happens to be listening).  

This is a big reason the industry is moving towards chip & pin based cards, magnetic based cards are horribly insecure.

So, does it mean a 3D printer can reproduce a magnetic tape ?

No, but it can be made quite easily.

[Wendigo]

How can a 3d printer produce magnetic tape when the consumer grade printers only use plastic spindles?

[d2dtk]

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.

[Dare]

Magstripe cards seem pretty easy to clone (though I've never done it), since reader/writers for them are relatively inexpensive. I've been planning to pick on up to play with for a while. They aren't currently 3D-printable, because of the magstripe, but a pack of blank cards only costs a few cents to a few dollars depending on the type and where you purchase them so it's not really an issue. In total, starting from scratch, duplicating a card would probably cost you around $30-$80 and wouldn't need much in the way of computer skills. You won't be able to double-spend the funds though, for the same reason that duplicating your house key doesn't give you an extra house; it's simply another way to access your funds.

Chip-and-pin cards however, as used in Europe, seem to be more difficult to clone. I haven't done much research on them though so I'm not certain about that.

[ranlo]

Magstripe cards seem pretty easy to clone (though I've never done it), since reader/writers for them are relatively inexpensive. I've been planning to pick on up to play with for a while. They aren't currently 3D-printable, because of the magstripe, but a pack of blank cards only costs a few cents to a few dollars depending on the type and where you purchase them so it's not really an issue. In total, starting from scratch, duplicating a card would probably cost you around $30-$80 and wouldn't need much in the way of computer skills. You won't be able to double-spend the funds though, for the same reason that duplicating your house key doesn't give you an extra house; it's simply another way to access your funds.

Chip-and-pin cards however, as used in Europe, seem to be more difficult to clone. I haven't done much research on them though so I'm not certain about that.

I think it's also worth bringing up why people clone cards: it's not to clone their own, but to swipe someone else's and clone that. Getting the strip info, for example, could be done through social engineering without the person realizing what's happening. I guess the best way to equate it is to stealing the number off a credit card to buy things online (the goal is to use it without the other person knowing the info was even taken), with the difference being that you're creating a physical copy instead of just a textual one.

I think that doing this is highly risky, though, being that pretty much anything you'd use the credit card for is traced in one way or another.

[BitPhotos]

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!

[b!z]

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!

[byt411]

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.

[ranlo]

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

[yakuza699]

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.

[yakuza699]

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

What do you mean by here (what country) and what do you mean by ''don't need to verify cards either'' and what do you mean by ''Just swipe real quick and go'' do you mean that you just put the card in don't even enter the code and go away if so you can wait for a guest?

[ranlo]

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

What do you mean by here (what country) and what do you mean by ''don't need to verify cards either'' and what do you mean by ''Just swipe real quick and go'' do you mean that you just put the card in don't even enter the code and go away if so you can wait for a guest?

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.

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

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