In basic terms you assume, that if you encrypt data on client side (creating a token) and send token to server over HTTP, it will be secure - this is not true.

Hacker can get the token via network monitoring software (he does not need password) - that's it. Estimated time to bypass this is like less then 15 min.

First, from what I understand, you don't show to user any data from other users, so you don't really have to worry about XSS. If you would show it, then you would have to make some countermeasures, such as character escaping (that actually should be used anyway). Hacked machine and browser security flaws are things you rather can't predict.

Second, the encryption thing you created doesn't really work. Sorry. Unless you are a genious with years of experience in security, but then you wouldn't need to ask this question. Among things that should be considered when designing encryption are:

• Man in the Middle - can someone catch user's data by decrypting data from server on own machine and reencrypt them when sending to client? Attacker may simply ask real server for token, and when pretending to client that he is the server, he has the luxury to generate own set of keys/tokens, which will look as legit as original.
• Network monitoring - are you sure you are not susceptible for instance to replay attack? Assume you order some items in some shop. If attacker records it and replays to the server, the same, encrypted data, will server detect it, or commit transaction again?
• Key generation - are the keys you use completely random, or just predictably random? If attacker can generate the same set of keys your server stores, he doesn't even need to directly attack you, he can just sit back and other implications are pretty obvious. And believe me, standard random with time seed is very predictable.
• Lots and lots more...

There are libraries like SSL that make this for you, made by people with years of experience and, as you probably realize, even they happen to mistakes, but nobody seems to be particularly eager to implement any alternative for some reason.

In case of security, the best option is to use checked and popular solutions, as they are probably also the most safe ones. As there is quite a few open-source and free libraries available, that should not be a problem. Ready encryption supported by browser will probably take care of more problems than you will ever probably imagine there is.

Unless of course I misunderstood you and you were not playing with webapps for webapp part of it, but for security thing. Then keep trying, and remember you will also learn a lot by attacking the app you created.

Don't do that.

OK, first of all you need to understand that even if you go to the ends of the Earth to make your application 'safe', it will never be safe. NEVER.

On a more positive note, let's go over what you could do to reduce the chances. I Googled sjcl and here I am assuming you mean the Stanford Javascrpit Crypto Library.

Whilst the SJCL is powerful on its own (with simple encrypt() and decrypt() methods), you may want to take control of it a bit more using its API.

After you've got that down, as mentioned in the comments, the most important question is really, how secure do you want it to be? From your question, quote:

For play, I built myself a webapp, it uses sjcl to ....

... which suggests to me that you probably aren't looking for a lot of security. But, I also presume that you are probably looking to prepare for a scenario in which you would need a lot of security.

I'm also assuming that the server wants nothing to do with the stuff the client enters.

One more point to keep in mind:

Quote from the link in first comment

... it's about perception. If your users perceive that their data is being treated in a secure manner, then they are likely to be more happy regardless of whether or not this is actually the case.

So, here are the possible options:

• Use server-side encryption. This is the most obvious answer and will protect you from 99% of things that could happen. Even though the server would not need this data, it's still better to keep it somewhere on the network where the server can protect it. But here's the problem:

Today, many cloud service providers deliberately provide server-side security to maintain control. But server-side security requires trying to defend everywhere user data is stored: every disk, every server, every link, every router, and every database. Security is only as good as the weakest link, so it only takes one tiny mistake, vulnerability or mishandling for there to be a data breach.

• Use a backend service. This has its own risks, like every other option you could possibly think of, because this really depends on who you want to trust (like every other thing you could possibly think of). There are actually two options in this case.

  • Whip up your own backend. Here I just gave you a good reference which you should be able to adapt to your needs. This is good option, and makes it really secure, but then again, your server would probably have to make sure this back-end is secure, and that probably creates more problems for you then it solves.
  • Use an existing back-end service. This is recommended, but the problem is which back-end should you use? After all, sending sensitive data to an unknown company is never safe. But I do know a few that are good. I would recommend backbeam.

• Use SecureStore. I've seen many people using this (though never used it myself very much) and they say it yields great results. Basically, it involves not allowing data to stay on the disk forever, and controller encryption keys. More details can be found here.

Quote:

There are two major problem the data storage mechanism in localStorage:

• The data is stored on unencrypted on disk. That means anyone with access to the computer can potentially get access to that data.

• The data remains on disk until either the site removes it or until the user explicitly tells the browser to remove it. That means the data may remain on disk permanently otherwise.

                                   ...
  

  The proposal is based on a few simple concepts that are shared amongst security-conscious companies:

• User data should not be stored on disk unencrypted.

• Even when user data is stored encrypted, the company must control the encryption algorithm and key.
• User data, even when encrypted, should not persist on disk forever.

In the end, whatever you decide to use will, once again, depend on two things:

• Whom you trust, and
• what level of security you want (you can never achieve 100%).

Summary

Here I've just summed everything up for reference.

Assumptions

• sjcl refers to the Stanford Javascrpit Crypto Library

• the server wants nothing to do with the data that the client uses

• you want real security, not perceived security

Possible options (in short):

• Server-side encryption: Rating - 3 / 5
• Back-end, whether custom or existing: Rating - 4 / 5
• SecureStore: Rating - 4.5 / 5