I have started some Java code which is supposed to become something between Minecraft and scratch. In order to share resources, I have teamed up with someone who ports a schedule planer (schedule for humans, not CPUs) from office+macros+emails to the web. And every time I say, we cannot not do this or that because I is not secure it sounds like an excuse. Is there a compact write-up in English or German which explains, why macro-Viruses exist and why even local use of html needs a webserver for security. I got used to this over the years, but I fail to give a short answer or search google.

I could ask this in a more general website, but here is my home ;-) The schedule planer is supposed to run on mobile devices and is very simple. It is meant for casual users. So I am not talking about some high level enterprise app here. Also, the back-end is fixed (in this phase). It is all about the GUI. Tiles. It should look like CandyCrush.

I have almost given up on security. I want to use GoogleAppEngine, and they bill CPU cycles. Security needs almost by definition a lot of CPU and RAM. Probably for production I check that I do not leak UserIds, and switch to google accounts. That means: no beautiful advanced math in my code :-(

Security needs almost by definition a lot of CPU and RAM.

Security was expensive about 20 years ago. These days it has almost no overhead (if done properly). And the RAM overhead is basically negligible.

You can run local HTML on a phone without security problems. This is what Titanium/PhoneGap/Cordova does. We have shipped one such app at work: http://m.imvu.com/ is also available "packeged" in the app stores.

The security comes from enforcing business rules on the server. For example, if you build the server such that anyone can upload "a completely new schedule" then your security exposure might be that an intern presses a button that uploads a blank schedule. Or it may be that someone sniffs an authentication cookie in a public WiFi spot, and makes subtle changes.

Thus, a secure app is split into at least two parts:
1) The "business rules" (and, usually, persistence) that check "who is making this request, and are they allowed to?"
2) The "user interface," which presents system state, and lets the user formulate requests to change system state.

Note that anything that runs on a client-hosted device can and will be hacked if there is incentive to do so. Thus, any business rule you actually care about, must be enforced in part 1).

Whether we're talking scheduling software, empire building games, or bank transactions doesn't really matter -- the approach is generally the same. Only the cost of failure may differ in the different cases :-)

Security is a mindset, not a solution. Your developer friend is right, security is important and not just an excuse, it needs to be factored into online solutions from day one, before any code is written and can't be tacked on at the end and generally can't be bought "off the shelf".

Security has a cost, but the runtime cost is generally low compared to the cost of developing a secure product. Of course, poor security has a cost too, just look at what happened recently to Sony. The cost of security is not obvious to most people, it is hidden but potentially can be catastrophic.

A professional developer should never agree to develop an insecure product, in s similar (but less extreme) way that a doctor should do no harm and architects should not design unstable buildings. People put trust in your product, they deserve to have that respected.

Remember, a secure product doesn't just protect you from hackers, but also yourself. For example, if the quote and edit button's functinoality were accidentally swapped in the next www.gamedev.net update, having the server check whether the forum member has permission to perform the action on that post can help limit the damage (e.g. people editing each other's posts).

To develop a secure product, you have to think like an attacker. It is not about what your product can or should do, but rather what a malicious individual can make it do. Thus, to justify a particular technical approach for security, you just have to think of an example of what would be possible without that approach. For example, a hosted system must validate input data on the backend even if the frontend does validation - as frontend validation is controlled by the client and could be by-passed. If you cannot justify a particular approach, then it isn't necessarily more secure. Arbitrary rules are security theater, and a distraction from actually security threats / weaknesses.

It is good to have some attacker personas to give some structure and context to security discussions. To take your schedule planner as an example, one persona might be a jealous ex trying to stalk one of your users. Another persona could be a spammer who wants to insert fake plans into the schedule to promote themselves. Now you can run through your application's functionality, and evaluate whether there is any risk, and how you can mitigate it.

For a great example of what happens when developers don't care about security, just take a look at what happened to moonpig.com last week.

They basically allowed any user to edit any other users account by simply changing an account id whilst logged in. When someone told them about the problem they did nothing for 18 months until the security researcher got fed up and made it public.

A great example of how NOT TO act regarding security...

Thanks for all the replies. They all apply to web pages. The do not explain, why even on a local machine the user cannot easily give my JavaScript code full access to the machine. Besides on my computer there is another user without admin rights so.. But still, why does chrome not say: "okay that html and js file and all is on your local harddrive, would you mind it having access to your documents folder?". Isn't it this way that IE6 was used in cooperate environments for like 20 years? Of course our webPages are supposed to be cross-browser compatible, so taking IE6 as a target is a bit strange. Do I have to say: "

homo homini lupus

"

It seems people are so naive. I miss the old times when there was no money on the web and trolls where only a minor annoyance.

I have problems understanding server side security. Even on less technical articles on slashdot, I can be read that password lists are stolen all the time, and therefore nobody stores passwords on the server. They store at least md5 hashes. Now md5 should be avoided because RAM and CPU is cheap today to brute force break it (okay some math also goes into this, reducing the attackers need for resources by a million or what not). More security can be gained by more RAM and CPU intensive hashes. And with more, I mean they have to be expensive in real currency. More expensive for bank accounts, less expensive for our scheduler or educational/game stuff. Also as RAM and CPU gets cheaper, the passwords need to be replaced and more expensive hashes need to be recalculated.

So if for any reason, my site gets interesting for attackers, they can throw amazon EC2 on me. Me on the other hand starts with the free quotas on GAE. This is Goliath against David. I think I have to preset the passwords for the users. Otherwise they reuse their banking account, some jealous ex-adim puts the password table through some shady online tool to crack it, and then all hackers around the world have access to the bank account of my customers!

I think you are conflating three different things here:

*Web Browsers* do not give access to the local machine, because doing so would expose pretty big security holes in practice.

*JavaScript* can have access to your local machine as much as you want. Just install node.js, for example.

*HTML applications* can also have access to your local machine -- use a system such as Cordova with the "desktop" target.

if for any reason, my site gets interesting for attackers, they can throw amazon EC2 on me. Me on the other hand starts with the free quotas on GAE. This is Goliath against David

I understand how you feel!

The good news is that, the main reason a dedicated attacker would want to get to you, would be financial. And if you are a target that's rich enough to warrant attacks by dedicated hackers, hopefully you're actually making enough money that you can pay for better hosting and management!

There are some cases where this may not be enough. For example, if you are a "free speech" site of some sort, that hosts political or religious dissident speech, you may be targeted by states that disagree with you, even though you may not be making any money off of the speech. Doing the best you can with what you have is even more important there...

Also, using bcrypt() with 16000 iterations (14 "rounds") is likely good enough for the next 5years, at least -- there are so many sites that use less strong mechanisms, that you likely won't be the target of choice. And even then, brute forcing 16000 iterations of bcrypt has a real, financial cost.

Finally, the idea of mailing a strong password to the user (ideally in a link they can click) is not bad. It moves the cost of protecting user data away from your system, and into the user's email. And if the user's email is compromised, the user is compromised in many, many, ways! There are still some problems, such as URL history in browsers being available to other users on the same machine, that you have to consider as far as attack vectors go -- it all depends on what particular problem you're trying to defend against!

I do not know if I ever ramp the system up. Then I will pay some cents for security . But design issues with security will be hard to fix later. I thought that bcrypt is rather exotic, but you mention it, too. That encourages me to use it.

I am conflating different things because that is how it is in the real world. The user base is heterogeneous, but all have a browser which in turn is capable of ECMAscript. For me this is the only reason to use that language. Likewise the user is not likely to install anything. With office files they only have to allow for makros, whose source they can look up, and not sell their soul to an installer, which on mobile devices want so many rights and information. I am not sure if Cordova or Node.js are that cross-platform compatible. Everybody claims they can ease development for iPhone. But then, when Apple updates the SDK, all things break down.