"Is there even a way to make a server unhackable? I am really not sure :-("

Its a pretty difficult thing, the simple answer it turn it off :-) however you're second comment is more relevant.

"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 :-/"

Google does a good job of securing their servers, however the risk is not that the 'server' gets hacked, rather its the application running on the server. So for example someone can't log into your server but they can SQL inject a command to dump your web site's password list and they don't have to log in.

Good secure design would start with really really strong testing around the applications 'mutation' points (which is to say where it changes in response to user input). When I was at Google products had to go through a security audit before being released and those guys were pretty good at their jobs. This is one of those cases where seeing a lot of ways people try to attack services gives you a leg up on looking for common weak points.

Anything can be hacked if it has information on it. There's even those terrifying "cold hacks" where you yank the memory stick from a machine that's powered off, chill it to preserve lifespan, and plug it into another machine to read it, the thing coughing up the contents like some zombie.

Nothing can ever be fully secure, but you can make it secure for all practical considerations.

If the MtGox site didn't have a giant hole in it (SQL injection), this would have never happened.

Sure, but it seems most sites end up having such holes in them. I am pessimistic in that I assume it is next to impossible to prevent.

It's definitely not impossible to prevent issues like this, it just requires effort.

Securing a network/host/application is like getting (and staying) in shape. It's a process that requires an ongoing effort. There's nothing you can buy that will take care of it forever.

Most breaches aren't the result of "impossible to prevent" attacks, they're the result of basic due diligence not being followed. You're right though, that it seems some days like that's the rule and not the exception.

While you can't have an "unhackable" site (or an "uncrackable" safe), it's all a matter of risk vs. reward. You can certainly ensure that your site doesn't have any vulnerabilities listed in the OWASP Top 10 (and test it repeatedly over time to make sure it stays that way).

And that's not even getting into a more mature vulnerability management process that involves outside assessments, source code reviews, and threat modeling. All those things are also nice to haves (or may be required, depending on your industry and the type of data you have access to).

It's totally understandable to be a pessimist about the state of security in our industry, but preventing these types of issues is not a Sisyphean task.

SQL injection problems are trivially preventable.

Maybe, but only if your awareness and concern for security is non-trivial.

If you're running a currency exchange, your concern for security should be quite high.

Sure, but they are not the only possible security problems.

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.

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

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

App Engine uses GQL which is effectively the same as SQL: 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.