Why doesn't Tornado have session

I've heard that cookies is less secure than the session.

You must have misinterpreted something. In fact HTTP sessions are usually implemented using cookies.

I'm thinking that if I could get &^*Y()UIH|>Guho976879, I can still forge the cookie, right?

Sure you can change the cookie, but will it be accepted by the server as valid? If you take an actual look at the documentation you'll see:

Cookies are not secure and can easily be modified by clients. If you need to set cookies to, e.g., identify the currently logged in user, you need to sign your cookies to prevent forgery. Tornado supports signed cookies with the set_secure_cookie and get_secure_cookie methods. ...
Signed cookies contain the encoded value of the cookie in addition to a timestamp and an HMAC signature. If the cookie is old or if the signature doesn’t match, get_secure_cookie will return None just as if the cookie isn’t set.

Thus, if you try to manipulate the secure cookie the framework will notice and treat the cookie as invalid, i.e. like the cookie was never sent in the first place.

I think the other answers fail to address the primary attack which is being protected against here, which is not forging the cookie, but tampering with it, or inspecting it.

If you send a cookie to a browser saying "current_user=tom", the user can send you back an alternative cookie saying "current_user=dave". If you have nothing to validate the cookie against, your application will assume they are logged in as "dave".

This could be mitigated by signing the cookie using a secret key - the tampered cookie would not have the correct signature, so would be rejected.

However, there may still be a problem: if part of the state you want to store is secret. For instance, you might want to store the cost price and markup of the products in the user's basket; clearly a plaintext cookie that the user can read is not appropriate here.

This leaves you with two solutions:

• Encrypt the contents of the cookie, so that it can be neither read nor amended without knowing the private key.
• Store the actual data locally (e.g. in a disk or memory store) and send only an identifier in the cookie. This is generally known as "session data".

Sessions are relatively easy to implement and are provably safe against these particular attacks. However, they place burdens on your back-end infrastructure, because your web / application servers need to be able to write and read the data; this can be tricky in complex load balancing setups, for instance. As such, encrypting a small amount of data directly in the cookie may be a sensible alternative, since now the only data that needs to be shared between your application servers is the private key.

Note that neither of these protect directly against other attacks, such as hijacking, where a malicious user simply clones the cookies from a genuine session. Session tokens may also be vulnerable to a related attack called "session fixation", where an attacker chooses the identifier before a genuine user connects, and can thus create identical cookies to them; this would not be possible with an encrypted cookie, but I'm sure there are other attacks unique to it in turn.