5

Okay, i'm developing an Angular 2 app. I've added auth0 authentication, but to me it handles sessions very insecurely. The jwt token is not encrypted and saved inside localStorage. The claims are visible for anyone, they can easily be decoded and revealed. Not to mention, Web Storage itself isn't a secure place.

I'm opting for JWTs because later i want to transform this web app to desktop app with electron and so i cannot use cookie-sessions. My users will have additional information such as roles, which i don't want to look up in db on every request, that's why i would like to store them in jwt. It makes sense to encrypt the data, but auth0 doesn't seem to provide that function.

If claims like roles are stored in localStorage unprotected, what's stopping me to go to firefox console and change the token, e.g. make myself an admin?

Justas B.
  • 67
  • 1
  • 7

2 Answers2

6

If claims like roles are stored in localStorage unprotected, what's stopping me to go to firefox console and change the token, e.g. make myself an admin?

Because JWT is signed, so any alteration to the content or the signature will be detected during validation

The digital signature, the third part of a JWT token like this hhhhhh.ppppppp.ssssss is created using server private key, and is the way you can verify the identity of the issuer of the token and also that it has not been altered

If you want to hide the payload, the JWT specification allows use encryption (see Json Web Encryption-JWE at RFC). If auth0 does not support it, you have a lot of libraries listed in jwt.io

Community
  • 1
  • 1
pedrofb
  • 37,271
  • 5
  • 94
  • 142
  • 1
    thanks for clarification, seems like i did not understand jwts fully. – Justas B. Jul 19 '16 at 13:47
  • 1
    No problem, your question makes sense – pedrofb Jul 19 '16 at 13:51
  • Now wait a minute. The only way for an attacker to change contents of jwt is to now the secret key. But if he has access to the token, can he like brute force it or something? Get a super computer, generate 40k secrets in a second and crack it? – Justas B. Jul 19 '16 at 14:52
  • Yes, it is theoretically posible. If have unlimited processor and a lot of time you can perform a brute force attack and break the key. At all likely. Nowadays a 2048 RSA key with SHA-256 is considered secure. Also certificates are usually renewed every two years more or less. Read this http://crypto.stackexchange.com/questions/1978/how-big-an-rsa-key-is-considered-secure-today – pedrofb Jul 19 '16 at 16:07
  • @JustasB. if hacker has access to token, he can use token directly in communication with server and get access. I write how to protect token from stolen by hacker in my post below. But remember that you can change often 'secret' key on your server (once a month) and you will be protectet against brute force jwt tokens. – Kamil Kiełczewski Jul 19 '16 at 20:39
0

JWT token has two parts: explicit (codet by base64 algorithm) - with payload data like for example exp time or user Id and role etc. and implicit - hash key which guarantee with extremely high probability that any part of explicit data was not change after token was created (by server using it's private key). So in Local/Session storage you can store this explicit part. The full token should be store in httpOnly cookies - then you will be protected against XSS attack (where hacker want to stole you token).

So you can read and change jwt token payload from firefox, but you will be unable to generate implicit hash - and server will reject your token.

So the answer to title question is: because Auth0 id_token is JWT token :)

Kamil Kiełczewski
  • 85,173
  • 29
  • 368
  • 345
  • Thanks for the solution. However, i am going to create a desktop app (using electron) with the same functionality, so cookies are not applicable here because electron doesn't have it. – Justas B. Jul 19 '16 at 22:30
  • ok, but do you must still deal with XSS attack problem in electron app? – Kamil Kiełczewski Jul 19 '16 at 23:01
  • Well, yes. I think, and i may be wrong, that protecting from xss attacks are easier than protecting from xsrf attacks. It's much easier to escape content from user input and from tokens, than implementing xsrf-tokens on your site. – Justas B. Jul 20 '16 at 18:36
  • in fact is opposit :) whe can easily create machanism to protect csrf attack, but we don't have method to protect xss in automagical way - developer need to alway remember about this kind of attack and filter input values in server side (so a lot of situation where developper can make mistake). To bigger problem is when you start using third-side libraries - and you newer know that libraries dont have bugs allow to xss... If my answer and comments help you, please click on gray up button above points or/and gray 'check' button on left side of this answer. – Kamil Kiełczewski Jul 20 '16 at 19:09