0

Is it correct to assume that the idtoken offers no more security than replacing it with a (possibly salted) SHA2 hash of itself in any follow-up communication with the backend server?

The indended flow would be the following:

  1. The Android app obtains an idtoken from Google
  2. The app sends the idtoken to the self-hosted backend server, where it is verified by the backend with the use of gitkitclient.VerifyGitkitToken
  3. The backend creates a SHA2 hash of the token together with the expiry date and the associated user id, and stores it for future reference in a lookup table
  4. The Android app creates the same SHA2 hash of the idtoken and passes it along in the header in any future communication with the backend, instead of using the idtoken for the follow-up communication.

Does this decrease in any way the security of the system?

If a transparent proxy with https inspection (and the according certificates installed on the device, ie legitimately in a corporate environment) would sniff the traffic, it would make no difference if the idtoken is obtained or the SHA2 hash of it, that transparent proxy would be able to act (possibly in a rouge way) on behalf of the Android app for the entire lifetime of the idtoken, right?

My issue is that calling gitkitclient.VerifyGitkitToken on every follow-up communication with the server is too expensive, and not necessary once the validity of the idtoken has been ascertained.

I also don't want the idtoken to be stored on the server for future reference, instead prefer having a hash of it. Is a SHA224 hash of the idtoken enough and is it safe to assume that it would not result in any collisions?

Daniel F
  • 13,684
  • 11
  • 87
  • 116
  • 1
    I'm voting to close this question as off-topic because it is more suited over at http://security.stackexchange.com/ as it's primarily about hash collisions and security between 2 services - not about a specific programming question. – ʰᵈˑ Aug 19 '15 at 07:37
  • @ʰᵈˑis there a way to move the question over there? (I've read that migrating a question deletes its answers, and nvnagr's answer is helpful) – Daniel F Aug 19 '15 at 10:10
  • it's in the close queue, so should be picked up by someone with power to migrate the question. I would [open a new question](http://security.stackexchange.com/questions/ask) over there and self close this question – ʰᵈˑ Aug 19 '15 at 10:13

1 Answers1

1

This requires a long discussion of what should be in an authentication cookie and what are the pros and cons of various approaches. No one solution will be fit for all and depending on the app/site security, performance, scalability requirements a solution should be carefully selected. So I really can not comment on the proposed solution without understanding a lot more details about the app, requirements and threats.

In general, the authentication cookie/token have these basic requirements

  • Should not be forgeable (signed by your server)
  • Should be easy to validate
  • Even if the signing secret is stolen, a hacker should not be able to create tokens for all users (e.g. can be achieved by having a per account nonce)
  • Should be revokable from the server (achieved by maintaining a server side state)
  • Optionally tied to a client to it was issued, so if stolen from a client will make it useless

I'm sure there are a lot more desirable properties. GITKit issues the id_token for a one time authentication use and a developer should use their own cookies/token to continue to keep the session of the app/browser. We know that many developer would like us to help and we are working on a solution that would give a long lived OAuth refresh token (and short lived access token) to the app that it can continue to use with its home server.

nvnagr
  • 2,017
  • 1
  • 14
  • 11