Wedge

Try it with chrome.

Take a screenshot and show it to us ;)
Than we can tell you what's maybe wrong.

Wedge works very good on chrome, but maybe not on other mobile browsers.
Maybe this could be solved by adding more user agents to wedge, but i didn't
look into it. @Nao ?

I liked the client side hashing, but could be hard to do on client side, because we would
need to pass costs and salts to client (if we use bcrypt). Or we use another algorithm on client
side, which could make things worse. Or we use stable values for this. Costs of 20, salt of blubb.
As long as we don't get hash collissions on the first round, this shouldn't be a big problem?
Besides that, client side hashing doesn't  protect against mitm. Simply serving a evil js would
destroy all the benifits. Only scenario where this could help is if there's no ssl. But as soon
as an evil person can hook between server and user, this doesn't help anymore.

I looked into password_hash function, i think it's safe to use. Because in the resulting
hash there are information about the algorithm (bcrypt), the salt, and costs (some bcrypt
specific parameter which defines how many rounds of bcrypt shall be used to make brute
force attacks harder.) and therefore password_verify will take the right algorithm and parameters
to verfify the password.
Things to think about:
- how to define costs for bcrypt, Settings.php?
- How do we change the password values in running environments? We have to plan this for the future
(if the default hash algo changes) and for now.


EDIT:
Easiest thing would be to send the passwords always in plain text, on server side check if we have an old password saved with sha1, if so, hash it in the old way and verify it. If it's fine, hash it in the new way and update the value. If not, password's wrong, error message and so. If it's already with the new algo, just do password_verify.

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.

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.

Updated the github repository.
https://github.com/C3realGuy/CountLikes