Should Google User ID's be hashed when stored in the database

Question

I'm currently developing an auth backend that allows for both Google and Email/Password as authentication methods.

I'm basically treating the Google ID and Password as credentials here. I'm already one-way hashing passwords but I'm not sure if I need to go this extra length with Google ID's as well.

I followed the best practices outlined in Google's docs which include sending the JWT token signed by Google from the client to server, which is then verified and used to get the User ID (all on the server). So I'm not worried about someone potentially using a stolen User ID to get access to an account; however I'm a bit worried about possible compromises of the database and, if in that case, the User ID from Google should be encrypted.

Answer 1

If you hash the google ID you must then rely on the hash function having no collisions, also as you need to use a plain hash like SHA256 not a salted hash like Bcrypt2, because for lookups you need a hash that can be repeated with zero information. For passwords you want a salted hash like Bcrypt2 to prevent rainbow-table attacks.

Hashing the google id (and the email addresses) gives greater protection if your database is compromised, but it's only an option if you don't need that information while the user is logged out (when they are logged in you can remember what they used to log in). If you do need that information while they are logged out you can use reversable encryption or just store it in plaintext.

Answer 2

No. The secret is password, not user ID. Hashing any user IDs has no sense.

Furthermore, is seems you store hashed Google passwords. It makes no sense. Normal users will not tell you (your application) their Google passwords.