6 ms·

Who wants to team up and replace MtGox? This is absurd. Anyone with a clue about anything knows better than to use unsalted MD5 or better yet, can imagine bett

Who wants to team up and replace MtGox? This is absurd. Anyone with a clue about anything knows better than to use unsalted MD5 or better yet, can imagine better ways to partition security for a system to prevent this, and at the very least can implement measures to prevent mass withdrawl without having to revert to transactional rollback after the fact. Really sad. Was MtGox first? Why did they have so much volume anyway?

omouse 15y ago
MtGox was first and they also overcame the barrier of payment processing. Payment processing is ALWAYS a bitch which is why people like bitcoin ;p
lwat 15y ago
Fun fact: not long ago 'MtGox' meant 'Magic the Gathering online exchange'
llambda 15y ago
There's still Trade Hill[0] I guess... Although it would be fun. Edit: And perhaps a good chance to use bcrypt over say MD5 or SHA256. I'm surprised bcrypt wasn't the go-to implementation. [0] https://tradehill.com/ https://tradehill.com/
- Ixiaus 15y ago
  You would be surprised how few developers know about bcrypt. I didn't learn about it till the Gawker attacks and all of the amazing threads by the tptacek and the other crypto guys that wouldn't stop saying "use bcrypt!*.
  - Locke1689 15y ago
    Bcrypt is nice but anyone attempting to kid themselves that they're creating secure webapps should at least know security standards like PBKDF2. It's in practically every good crypto library, as well.
    - llambda 15y ago
      Do you have a good source explaining PBKDF2 and perhaps comparing it with bcrypt in the context of securing web apps?
  - drivebyacct2 15y ago
    I've got people in IRC telling me that MD5+rot13 is good enough, or to just use some SHA implementation. This was after I'd already espoused how trivial bcrypt was. Seriously, there are people in here that don't understand the difference between encryption and hashing, don't understand the benefit of salts, think that there (is/should be) one "secure" salt. The load of just absolutely false security information in here is startling.
    - llambda 15y ago
      Hm, I'd like to know more about why MD5+rot13 is good enough and also why they justify "good enough" over what could be argued as a "good" or perhaps very good solution, e.g. bcrypt?
      - burgerbrain 15y ago
        The only thing MD5+rot13 would have going for it is that you couldn't just trivially google the hashes to get the reversal (as is the case in a disturbing number of cases). Of course this only lasts as long as they don't figure out that it's MD5+rot13.. I'd give that about 5 minutes tops.
deleted 15y ago
[deleted]
- drivebyacct2 15y ago
  I'm hearing a LOT of conflicting information. The version I keep hearing is that most are salted MD5, but that some old ones are unsalted.
  - wcoenen 15y ago
    I deleted my reply (where I stated that the passwords were salted). Apparently the database has a mix of hashing strategies. It started with unsalted MD5 and was improved over time. The format of the PHP crypt output allows you to distinguish between hash types.
Tichy 15y ago
Is there even a way to make a server unhackable? I am really not sure :-( I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/
- drivebyacct2 15y ago
  Uh, seeing as this was an SQL injection vulnerability, just using GAE wouldn't protect against that at all. An unhackable server is probably possible, but a non-trivial unhackable server probably isn't. But you can still create sites that are secure, even if hackable. If the hackers had accessed a database of bcrypted passwords and if the site would have locked down when it detected erroneous volume of transactions, there would be no headliner here.
  - Tichy 15y ago
    I am not that worried about writing a web application properly. But I am just an amateur when it comes to administrating a server. I would be more worried about some security hole in some random service that is running on the server by default, that I never even heard about. GAE doesn't even use SQL, btw. At least last time I checked they didn't - they seem to be planning to support it in the future, though. However, even if the server is secure, I suppose if it was known that I am the admin of a BitCoin bank, my home computer would become a target, too. If my home computer would be hacked and I logged into the server, I would be screwed, too. It just seems too risky...
    - biot 15y ago
      App Engine uses GQL which is effectively the same as SQL: http://code.google.com/appengine/docs/python/datastore/gqlreference.html http://code.google.com/appengine/docs/python/datastore/gqlre... You can still directly append unescaped user input to your query and execute that against your datastore, though the limited capabilities of GQL does limit the attack surface somewhat.
    - jerf 15y ago
      "I am not that worried about writing a web application properly.... I would be more worried about some security hole in some random service that is running on the server by default, that I never even heard about." While the latter can happen and is broadly easier for a script kiddie, believe me, the former is nontrivial and very rarely done correctly. Your average web app is full of vulnerabilities, and while scanning can't quite be fully automated it's definitely something you can use automation to help with, so don't think you're secure-through-obscurity.
Ixiaus 15y ago
I'm thinking about it... In any case, it would be a cool project. This would be a great opportunity to try out Erlang for web app development...
sunchild 15y ago
I think the replacement solution needs four key components: 1) Stronger logical security 2) A triggering mechanism for halting suspicious trading 3) Clear rules for halting and rolling back market activity 4) Some measure of coverage for trading loss I'm no expert in equity markets, but I would imagine someone who is can weigh in on how these specific issues are handled.
- byrneseyeview 15y ago
  If you guys do work on this, send me an email (email is in the profile). Halting is not the right way to run an exchange, because it creates "air pockets" of liquidity given sufficiently sophisticated traders. This is what lead to the "flash crash" last year: high-frequency traders didn't want to be caught with illiquid positions in the event of a halt, so they sold as quickly as they could, making a halt more likely. It creates a situation quite similar to a bank run. (Instead, you might want the people who organize the exchange to also do some market-making, and to stabilize prices in order to grow volume, leading to a more profitable business overall.)
  - HockeyPlayer 15y ago
    As a market maker, I do NOT want the exchange also making markets, which puts them in direct competition with me.
    - byrneseyeview 15y ago
      For sufficiently fungible products, the "Market Maker as Exchange" model works really well. What you'd basically have is high spreads for retail investors, and lower spreads for institutional investors. So your consumer-facing company would make a spread and then flatten its exposure by trading with other market-makers. This gives the "Exchange" more flexibility than Mt. Gox has. It can offer more competitive prices when it's worthwhile, and pull back if trading with retail customers gives it too much net exposure. That's better than having a fixed fee for matching people with market-makers. This is a rough approximation of how forex works.

omouse 15y ago

MtGox was first and they also overcame the barrier of payment processing. Payment processing is ALWAYS a bitch which is why people like bitcoin ;p

lwat 15y ago

Fun fact: not long ago 'MtGox' meant 'Magic the Gathering online exchange'

llambda 15y ago

There's still Trade Hill[0] I guess... Although it would be fun. Edit: And perhaps a good chance to use bcrypt over say MD5 or SHA256. I'm surprised bcrypt wasn't the go-to implementation. [0] https://tradehill.com/ https://tradehill.com/

Ixiaus 15y ago
You would be surprised how few developers know about bcrypt. I didn't learn about it till the Gawker attacks and all of the amazing threads by the tptacek and the other crypto guys that wouldn't stop saying "use bcrypt!*.
- Locke1689 15y ago
  Bcrypt is nice but anyone attempting to kid themselves that they're creating secure webapps should at least know security standards like PBKDF2. It's in practically every good crypto library, as well.
  - llambda 15y ago
    Do you have a good source explaining PBKDF2 and perhaps comparing it with bcrypt in the context of securing web apps?
- drivebyacct2 15y ago
  I've got people in IRC telling me that MD5+rot13 is good enough, or to just use some SHA implementation. This was after I'd already espoused how trivial bcrypt was. Seriously, there are people in here that don't understand the difference between encryption and hashing, don't understand the benefit of salts, think that there (is/should be) one "secure" salt. The load of just absolutely false security information in here is startling.
  - llambda 15y ago
    Hm, I'd like to know more about why MD5+rot13 is good enough and also why they justify "good enough" over what could be argued as a "good" or perhaps very good solution, e.g. bcrypt?
    - burgerbrain 15y ago
      The only thing MD5+rot13 would have going for it is that you couldn't just trivially google the hashes to get the reversal (as is the case in a disturbing number of cases). Of course this only lasts as long as they don't figure out that it's MD5+rot13.. I'd give that about 5 minutes tops.

deleted 15y ago

[deleted]

drivebyacct2 15y ago
I'm hearing a LOT of conflicting information. The version I keep hearing is that most are salted MD5, but that some old ones are unsalted.
- wcoenen 15y ago
  I deleted my reply (where I stated that the passwords were salted). Apparently the database has a mix of hashing strategies. It started with unsalted MD5 and was improved over time. The format of the PHP crypt output allows you to distinguish between hash types.

Tichy 15y ago

Is there even a way to make a server unhackable? I am really not sure :-( I would try to put the whole thing on Google App Engine, at least then the burden would be on Google for the most part :-/

drivebyacct2 15y ago
Uh, seeing as this was an SQL injection vulnerability, just using GAE wouldn't protect against that at all. An unhackable server is probably possible, but a non-trivial unhackable server probably isn't. But you can still create sites that are secure, even if hackable. If the hackers had accessed a database of bcrypted passwords and if the site would have locked down when it detected erroneous volume of transactions, there would be no headliner here.
- Tichy 15y ago
  I am not that worried about writing a web application properly. But I am just an amateur when it comes to administrating a server. I would be more worried about some security hole in some random service that is running on the server by default, that I never even heard about. GAE doesn't even use SQL, btw. At least last time I checked they didn't - they seem to be planning to support it in the future, though. However, even if the server is secure, I suppose if it was known that I am the admin of a BitCoin bank, my home computer would become a target, too. If my home computer would be hacked and I logged into the server, I would be screwed, too. It just seems too risky...
  - biot 15y ago
    App Engine uses GQL which is effectively the same as SQL: http://code.google.com/appengine/docs/python/datastore/gqlreference.html http://code.google.com/appengine/docs/python/datastore/gqlre... You can still directly append unescaped user input to your query and execute that against your datastore, though the limited capabilities of GQL does limit the attack surface somewhat.
  - jerf 15y ago
    "I am not that worried about writing a web application properly.... I would be more worried about some security hole in some random service that is running on the server by default, that I never even heard about." While the latter can happen and is broadly easier for a script kiddie, believe me, the former is nontrivial and very rarely done correctly. Your average web app is full of vulnerabilities, and while scanning can't quite be fully automated it's definitely something you can use automation to help with, so don't think you're secure-through-obscurity.

Ixiaus 15y ago

I'm thinking about it... In any case, it would be a cool project. This would be a great opportunity to try out Erlang for web app development...

sunchild 15y ago

I think the replacement solution needs four key components: 1) Stronger logical security 2) A triggering mechanism for halting suspicious trading 3) Clear rules for halting and rolling back market activity 4) Some measure of coverage for trading loss I'm no expert in equity markets, but I would imagine someone who is can weigh in on how these specific issues are handled.

byrneseyeview 15y ago
If you guys do work on this, send me an email (email is in the profile). Halting is not the right way to run an exchange, because it creates "air pockets" of liquidity given sufficiently sophisticated traders. This is what lead to the "flash crash" last year: high-frequency traders didn't want to be caught with illiquid positions in the event of a halt, so they sold as quickly as they could, making a halt more likely. It creates a situation quite similar to a bank run. (Instead, you might want the people who organize the exchange to also do some market-making, and to stabilize prices in order to grow volume, leading to a more profitable business overall.)
- HockeyPlayer 15y ago
  As a market maker, I do NOT want the exchange also making markets, which puts them in direct competition with me.
  - byrneseyeview 15y ago
    For sufficiently fungible products, the "Market Maker as Exchange" model works really well. What you'd basically have is high spreads for retail investors, and lower spreads for institutional investors. So your consumer-facing company would make a spread and then flatten its exposure by trading with other market-makers. This gives the "Exchange" more flexibility than Mt. Gox has. It can offer more competitive prices when it's worthwhile, and pull back if trading with retail customers gives it too much net exposure. That's better than having a fixed fee for matching people with market-makers. This is a rough approximation of how forex works.