2

Shall I hash users of my portal when password is generated by server and user cannot change it? Logically:

  1. User can't use this passwords anywhere else as it is server-generated.

  2. Even when somebody access database illegally, they can change password and see it, but it is useless for them as it is not used anywhere else.

Am I right? Or hashing still should be implemented...?

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
TN888
  • 7,659
  • 9
  • 48
  • 84
  • A user can gain access to any other user's account if they gain access to DB. Also employees could gain access to client(s) accounts with passwords (employees could get in other ways but a bit more work). – chris85 Jun 20 '15 at 18:23
  • @chris85 Yes, but when they have access to DB they can change every one password and eneter any account – TN888 Jun 20 '15 at 18:24
  • Yes, but client may/will know the password was changed unless it is restored to its original value. – chris85 Jun 20 '15 at 18:26
  • You should concretize why you want to avoid it. Where exactly is the benefit of being lazy? For everyday web apps, hashed passwords aren't an issue. Only if you were to implement Digest authorization, then uncrypted passwords would make sense. – mario Jun 20 '15 at 18:27

3 Answers3

5

Security is something done in layers and each layer is designed to raise the cost of doing something you don't want them to. Do security guards prevent robberies? No, but they raise the cost of committing one to where most people won't bother.

Hashes don't prevent people from hacking your users but an unencrypted password is an open invitation for anyone who gains access to that data to log into your users' accounts freely for as long as it takes you to discover the hack.

Machavity
  • 30,841
  • 27
  • 92
  • 100
  • OK, now I got it. He may do not know how to generate password in order to change them. Thanks for this answer. – TN888 Jun 20 '15 at 18:27
  • The best deal for the hacker is not to generate a new password but to freely let you have the false sense of security thought that your trousers aren't down. He just uses the hash. Were you to use SSL and onetime keys your trousers get lifted up quite high – AsConfused Jun 20 '15 at 18:45
  • @AsConfused You can't just use the hash like that. The whole point of a hack would be to obtain the users credentials in such a way they don't know you have them. Check out [password_hash](http://php.net/manual/en/function.password-hash.php) on how a secure hashing system really works – Machavity Jun 20 '15 at 19:57
  • If i have a hash i am in. I have several here and they work great on systems i am not supposed to be in. Like i said, false sense of security – AsConfused Jun 20 '15 at 21:02
  • Sounds like a bad implementation rather than a bad methodology – Machavity Jun 21 '15 at 01:14
2

Hashing should be implemented because hashing is to protect against a server compromise, not a client / end user compromise. For more security you should use a salt and password hashing algorithm when hashing passwords as well.

The reasoning is that if your server is compromised, either through an outside attack (e.g. SQL injection, SSH heartbleed, etc.) or an inside attack (e.g. malicious employee if you have them), then the passwords or hashes can be retrieved. If they are retrieved, you want to make it very difficult for the attacker to use the retrieved data to compromise your system. Hashed passwords with salts are much harder for an attacker to use than a plaintext password which they can use with the right username.

  • Non-hashed passwords: If someone can retrieve non-hashed passwords, they can directly use them to impersonate end users.
  • Hashed passwords without salt: If someone can retrieve hashed passwords that are created without salts, they can perform a dictionary or brute-force attack to find the passwords by hashing words in a dictionary or all strings.
  • Hashed passwords with salt: If you add a salt, then the attacker that has retrieved your hashed passwords will also need to know your salt to efficiently attack the passwords, e.g. via a dictionary attack.

Additionally, when hashing passwords, you should use a hashing algorithm specifically designed for passwords, e.g. bcrypt, and not a general purpose hashing algorithm like SHA. This is because general purpose algorithms are designed to be very fast, making it easier for an attacker to perform a dictionary or brute force attack. A password hashing algorithm like bcrypt is slow to hash so it will slow down the attacker.

Grokify
  • 15,092
  • 6
  • 60
  • 81
  • If you don't use a secure transmission channel it's all a mute point. – AsConfused Jun 20 '15 at 18:57
  • There are many aspects to security and that's certainly a very important component which is why many sites are switching to TLS now. I didn't add it above because it didn't appear to be in the scope of the question. – Grokify Jun 20 '15 at 18:59
  • I'm with ya. In crypto we always say better no security than a false sense of it :) which may sound ridiculous but there is worth in uderstanding the phrase – AsConfused Jun 20 '15 at 19:02
-1

always hash passwords never store them in plain text, even if you think only you will ever see/use it.

gavtaylor
  • 653
  • 8
  • 21
  • OK. As below: Why? Can you explain? I have heard this opinion already, but you do not give me any reasons for it... It makes your answer useless... I gave my arguments... – TN888 Jun 20 '15 at 18:22
  • you should never make any exception when storing passwords. if you need to be able to recover the password for internal use, you should look into encrypting the data with AES or similar. – gavtaylor Jun 20 '15 at 18:28
  • @Ty221 https://stackoverflow.com/questions/287597/why-should-i-care-about-hashing-passwords-anyway – Marki555 Jun 20 '15 at 18:40
  • @gavtaylor for example if you want to support challenge-response auth methods (as in SMTP SASL), you need cleartext password. – Marki555 Jun 20 '15 at 18:41
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. – tjati Jun 20 '15 at 21:45
  • @omeinusch why does it not provide an answer? the question was 'should I hash my passwords if my users wont see/use it', my response does answer that question, it just didn't explain my reasons why in enough details Ty221 wanted. – gavtaylor Jun 21 '15 at 08:07