-3

I am working on a client server application where to identify each user I was thinking of storing a single database entry:

hash(email + password)

In my opinion, this is enough to stop some known attacks like the ones with pre-compiled tables of hashes to passwords.

My reasons for this approach are:

  • Make the server client authentication more efficient.
  • Not store the email in plain text on the server (more secure in case of breach).
  • Store the same hash on server and on client (only calculate the hash once on each side)
Adi
  • 43,953
  • 16
  • 137
  • 168
John
  • 31
  • 1
  • 5

3 Answers3

2

Obligatory: Don't roll your own crypto....

Based on your comments, you are asking not about any specific algorithm but if changing the hash input from password to email+password provides any additional security.

Given email: bob@example.com with password My @wesome pa$$w0rd FTW YO!!!!

  • So your input into the hash algorithm is now longer and less likely to be in a rainbow table and will take longer to get the complete plaintext
  • As you noted in a comment, you could use the email as a salt, but probably better to use a random value and here
  • Depending on some implementation details, email address could still be exposed; if you don't need the email address and will never use the value anywhere else, why require an email address instead of just a username. You may also run into issues with password resets or user management.

Make the server client authentication more efficient.

Why is this more efficient? A Javascript implementation in the browser could be pretty slow and could be subject to compromise since you have the same level of assurance in the user's browser (not under your control) as on your server. You want your hashing to be slow generally, not fast when it comes to passwords.

Also, for this last part:

Store the same hash on server and on client (only calculate the hash once on each side)

It sounds like you want to reduce server load by calculating the hash at the client and sending to the server? Then in your DB you lookup that value with the value in the database? This may not be doing what you think depending on implementation, for example are sending the hash over the network to be compared with the value in the DB; if the DB is compromised, the attacker has the input value so this is the same as doing a plaintext. You wants to prevent someone who gets the DB from being able to log in over the legit channel. Check out "Challenging challenge: client-side password hashing and server-side password verification"

Community
  • 1
Eric G
  • 9,701
  • 4
  • 31
  • 59
1

The implemenation where you use the email as salt is not good. A salt is preferably cryptographically random generated. This ensures that the salt is globally unique. This means that if you have a person using the same password across two different applications, both passwords will look different. With your scheme where you use the email address as salt, the hashed password between two applications will be the same.

Furthermore I think you should read up on password hashing and which algorithms are acceptable. Currently you can use:

  • scrypt
  • bcrypt
  • pbkdf2

Either of these are good and most libraries will actually generate the salt correctly for you.

Lucas Kauffman
  • 54,229
  • 17
  • 113
  • 196
0

Please don't use a md5/sha/smth hash to store passwords, salted or otherwise. Generic hashes are designed to be fast — I can md5 a 9Gb file on my laptop in 20 seconds. You don't want your password hashes to be fast to compute.

Use something that's actually meant to securely hash passwords — Do any security experts recommend bcrypt for password storage?

If your only aim is to make things fast and simple, you might as well store the password as plaintext; sha1(email + password) can be broken very quickly on today's hardware that it's almost not worth the "trouble".

Community
  • 1
Joel L
  • 1,427
  • 11
  • 12
  • 1
    This cannot be further from the question because OP hasn't specified which hashing algorithm he's using, on which is the whole premise of your answer is based. OP is asking about storing the email with the password as a hash in one field to use for user login. – Adi Apr 27 '14 at 13:53
  • 1
    Guilty as charged I was planning on using Md5 – John Apr 27 '14 at 14:06
  • Thanks for the link I'll investigate bcrypt implementation in Java. Cheers – John Apr 27 '14 at 14:10
  • @Adnan — since the question mentioned salting the password with an email address before hashing, I (apparently correctly) assumed that John's not talking about a password hashing function — you certainly don't (almost?) ever need to salt a correctly-used password hash with an email address. – Joel L Apr 27 '14 at 14:23
  • 1
    I'm glad that assumptions worked out fine this time :) – Adi Apr 27 '14 at 14:28
  • -1 because you make assumptions. Furthermore I want to see you "easily" crack a password of 42 characters in length, even when just using sha-1. Nevertheless you should use either scrypt,brcrypt or PBKDF2 if you want to hash passwords. – Lucas Kauffman Apr 27 '14 at 16:05