0

I use a secure one way hash to store passwords on the server. Can I send this same hash to the client to use as a token.

It is supposed to be an unbreakable one way hash (SHA-256 or similar), plus there is noway to tell that it came from the user password or to even know it is there unless you poke around.

Looking for verification if this is O.K. ?

  • 6
    Why would you do that? A better idea would be to use an existing library that uses token based authentication / authorization. There are many libraries available, for free, on all the platforms I can think of. Why reinvent the wheel and leave your application vulnerable? – Igor Nov 22 '17 at 20:36
  • 1
    No! Do not do this! It is a huge security risk to all of your users. Use a GUID or something and map the GUID to the hash. Then store the GUID and use it as a lookup for the user. Never store passwords, encrypted or not, in public storage or on the client like that! – daddygames Nov 22 '17 at 20:38
  • 1
    In addition to what Igor said: NO, it's not OK / safe to send the hash. If the user can use the hash, then so can a bad actor. – random_user_name Nov 22 '17 at 20:38
  • If it is a proper hash that is salted no non-government entity ( giant server farm ) can properly crack. But I take it that if someone intercepts the token, they can than impersonate the client for as long as they are using that hash / token. That is the primary concern then ... impersonation of the hash / token? –  Nov 22 '17 at 21:05

3 Answers3

0

If it's truly one way then I assume your server validates logins using the hash and not the plaintext. Therefore, sending the password hash is effectively the same as sending the key to the inner door of your home. There's still an outer door but why send more than you need/risk it.

You should strongly consider OpenID Connect for securing applications. https://www.scottbrady91.com/OpenID-Connect/OpenID-Connect-Flows

OpenID Connect promotes time-bound authorization codes for web applications. If you're curious why all the indirection and layers, this SO answer is valuable: What is the difference between the 2 workflows? When to use Authorization Code flow?

In summary, no this is a bad idea.

Andy Kong
  • 300
  • 2
  • 8
0

No. The severity of the issue depends on other details of your system, but in any case it is a bad idea.

If it is a salted hash, properly implemented (salt before hashing, unique random salt per user), then the hash alone will not expose the password. However, passwords are rarely changed, so the hash of the password would rarely change, so anyone who intercepted this hash would be able to use it to impersonate the user for an indefinitely long period of time.

If this hash is not salted, the problem gets a lot worse. A bad actor who intercepts such a hash would have a significant chance of being able to crack the actual password from it. It doesn't matter how technically irreversible the hashing algorithm is, there are huge databases of common passwords and their hashes and for a lot of users cracking an unsalted hash is a simple matter of a database lookup. If the user happens to use this password on many sites, as is common, this could turn into full blown identity theft.

The one part of your idea that is ok is using a token for authentication. That token should be purely random and strictly time-limited, however, with a new one generated each time a user logs in.

Douglas
  • 5,017
  • 1
  • 14
  • 28
  • If it is a proper hash that is salted no non-government entity ( giant server farm ) can properly crack. But I take it that if someone intercepts the token, they can than impersonate the client for as long as they are using that hash / token. That is the primary concern then ... impersonation of the hash / token? –  Nov 22 '17 at 21:07
  • @rebeccakan For a proper salted hash, that is pretty much it. Such a hash would be completely unique to your site and non-crackable, so stealing the hash would only breach your site, but it would still be a breach of your site. – Douglas Nov 22 '17 at 23:39
  • But if I'm using https like 90% plus of the internet, it should not be able to be able to be intercepted unless the client machine itself is hacked. –  Nov 22 '17 at 23:42
  • @rebeccakan It's not that simple, and you shouldn't count on the client machine not being hacked either. Internet security is a complicated subject with many different ways to approach cracking something, and you should never assume you've covered them all. Defense in depth is the way to go. – Douglas Nov 22 '17 at 23:48
0

This is a no no for various reasons as pointed out by Douglas. Also should your users discover this you would greatly lose their trust in you and your product, and might hurt you legally which I'm pretty sure is not a desirable :).

I would recommend generating a separate token, that probably expires over time, and sending them this instead.

Plus it's fairly simple to implement, therefore no harm in being cautious.

kurokiiru
  • 303
  • 3
  • 6