Question about SHA1/256 (github issue #60)

Farjo

  • "a valuable asset to the community"
  • Posts: 492

CerealGuy

  • Posts: 336
Re: Question about SHA1/256 (github issue #60)
« Reply #1,  »Last edited
Bcrypt would be the algorithm i would choose too. But I don't know what i should think of the password_hash() functions. It's always a bit critical if you change the password hashing algorithm. Because in the database you still have the hashes with the old algorithm, so you have to hash it once with the old algorithm to make sure it's the correct password and after that insert/update the hashed password with the new algorithm. It's getting even more complicated because wedge already hashes the password on client side to don't transfer the password in plaintext (which i like). I want to change it, but it's a bit critical and I'm not an expert for this. Therefore I want to do it well planned and with a bit more knowledge as i have in the moment. The thing I worry about with password_hash() is that if you use a database backup from a new php version on an old php version where the password_hash() function would use a different (less secure) algorithm, this would maybe break things. But I only scanned the documentation.
Besides that, it's not super important to change the hashing algorithm now, as we "only" use it for passwords. So if you don't have to fear NSA or something like that, your passwords aren't currently in danger.

Farjo

  • "a valuable asset to the community"
  • Posts: 492
Re: Question about SHA1/256 (github issue #60)
« Reply #2,  »
Thanks for the reply, very interesting. How does Wedge hash on client side?

Perhaps my next question is to the Elkarte crew - why, after you'd looked into it all, did you choose SHA256 over bcript / password_hash() ?

I see that Nao has posted to issue #60 and I will watch with interest.

CerealGuy

  • Posts: 336
Re: Question about SHA1/256 (github issue #60)
« Reply #3,  »
On client side, if the browser supports js, the password gets hashed once without any salt and with sha1. If the browser doesn't support js, it doesnt get hashed. The hashed or unhashed password gets send to the server, if it's unhashed/plain, wedge hashes it first. Now it's in any ways hashed once with sha1. Now it gets hashed again with sha1 but this time with the salt connected to this user. If the hash is now the same as in the Database, it's the correct password.
This hashing on the client side was quite cool when you didn't had ssl in all places because you don't send your password in plain. Still if someone can hijack the Session (mitm attack) he/she can readout the hashed password and log in with that again at any time (until you Change your password).
I didn't dig through all the code, so not 100% sure it works exactly like this. Especially this 2x hashing + salting is interesting, it makes all of it a bit harder to crack.

Nao

  • Dadman with a boy
  • Posts: 15,997
Re: Question about SHA1/256 (github issue #60)
« Reply #4,  »
If I do password_hash() with PASSWORD_DEFAULT, then it means I can't be sure what algorithm will be used to hash the password, right..?

So, how exactly can I hash the password on the client side if I don't know which kind of crypt system PHP will use to compare it with my own hash...?

CerealGuy

  • Posts: 336
Re: Question about SHA1/256 (github issue #60)
« Reply #5,  »
Quote from Nao on April 16th, 04:13 PM
If I do password_hash() with PASSWORD_DEFAULT, then it means I can't be sure what algorithm will be used to hash the password, right..?

So, how exactly can I hash the password on the client side if I don't know which kind of crypt system PHP will use to compare it with my own hash...?
As long as you always hash it with the same algorithm on client side, it wouldn't matter, because you always hash it again on server side. The problem i see is that the unclear nature of password_hash() would result in inconsistencies across different php versions. So you couldn't use a backup from a newer php version on one with a server with an older php version.

Suki

  • Posts: 59
Re: Question about SHA1/256 (github issue #60)
« Reply #6,  »
If there are any changes, it will be known pretty early, any change in the default algo will be made in the next full release after a proposed algo was included. Plenty of time IMO.

And you will always know what thing was changed and to what. Theres a similar problem if you chose an user defined algo, sooner or later you will have to upgrade your script to get rid of obsolete ones.

Nao

  • Dadman with a boy
  • Posts: 15,997

Suki

  • Posts: 59
Re: Question about SHA1/256 (github issue #60)
« Reply #8,  »
I pop up every once in a while and since I'm dealing with the same thing myself I chime in.


I wouldn't use bcrypt on the client side, too much of an issue and as far as I know it wasn't designed to do hashing but to encrypt.  Besides, everyone is going towards https so client hashing will become less of an issue.

So, use bycrypt yes but on server side only.