You need to hash the password with a salt. And send the hashed salted password to the webservice which should already know the salt. You then verify it is the correct password by salting(with the same salt) the password in the db and comparing the two hashes. But make sure to generate the salt for every login new(on the server, not on the client) - otherwise the hash became the password which everyone could just copy to login.
Besides - the password in the db should also be saved salted and hashed.
Your solution assumes that the salt is know on both sides, the server and the client. You also require a new salt with every login. How do you ensure that both sides have the same salt? If you create a new salt on the client side and send it with the salted password, then the password in the database will have to be stored in clear text, which isn't a good idea neither.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think this is how it could work (again: I'm in no way experienced doing things like that, I only read about these technics)
Client: asks for Login-Page
Server:
generate fresh salt stores the salt in the PHP-Session
send salt in plain + login page to client
Client:
User enters Password
S = hash (entered password)
P = hash (S + salt from server)
send username + P to server
Server(got P and username from client):
A = Hash of password which is saved in DB
B = Hash of (A+ Salt from PHP-Session) # Never use a salt the client sent to you! or else you could sent credentials you eavesdropped earlier)
compare B and P if it's a match the user entered the right password
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. Sounds all very reasonable. Now I have to find a way to implement it and make sure there is smooth transition from the old authentication to the new one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I find this a non problem. I would recommend that the DMS session should be run over https anyway. Not only password should be protected, sensitive documents might be transferred as well.
If you decide to implement something like the above, please take care not to break LDAP login. I am no security expert but I dont see how LDAP login could coexist with described method.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should not feel embarrassed, I could imagine many scenarios in where you want to archive and maintain non secret documents, but save the hassle in setting up certificates and what have you.
In that case you still want to be able to login securely to maintain your system. Writing the above I was focusing on my own use cases - which is based on LDAP support.
My suggestion is to change this ticket from bug to a feature request. And for now add a notice to the setup documentation recommending the use of https.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any suggestion how to solve this?
You need to hash the password with a salt. And send the hashed salted password to the webservice which should already know the salt. You then verify it is the correct password by salting(with the same salt) the password in the db and comparing the two hashes. But make sure to generate the salt for every login new(on the server, not on the client) - otherwise the hash became the password which everyone could just copy to login.
Besides - the password in the db should also be saved salted and hashed.
I have only basic knowledge of these things. This guy https://crackstation.net/hashing-security.htm seems to know what he's talking about.
Last edit: BenjaminH 2015-09-18
Your solution assumes that the salt is know on both sides, the server and the client. You also require a new salt with every login. How do you ensure that both sides have the same salt? If you create a new salt on the client side and send it with the salted password, then the password in the database will have to be stored in clear text, which isn't a good idea neither.
I think this is how it could work (again: I'm in no way experienced doing things like that, I only read about these technics)
Client: asks for Login-Page
Server:
generate fresh salt stores the salt in the PHP-Session
send salt in plain + login page to client
Client:
User enters Password
S = hash (entered password)
P = hash (S + salt from server)
send username + P to server
Server(got P and username from client):
A = Hash of password which is saved in DB
B = Hash of (A+ Salt from PHP-Session) # Never use a salt the client sent to you! or else you could sent credentials you eavesdropped earlier)
compare B and P if it's a match the user entered the right password
Thanks. Sounds all very reasonable. Now I have to find a way to implement it and make sure there is smooth transition from the old authentication to the new one.
I find this a non problem. I would recommend that the DMS session should be run over https anyway. Not only password should be protected, sensitive documents might be transferred as well.
If you decide to implement something like the above, please take care not to break LDAP login. I am no security expert but I dont see how LDAP login could coexist with described method.
I'm really embarrassed by my earlier opinion. Sorry. HTTPS is the desired solution.
You should not feel embarrassed, I could imagine many scenarios in where you want to archive and maintain non secret documents, but save the hassle in setting up certificates and what have you.
In that case you still want to be able to login securely to maintain your system. Writing the above I was focusing on my own use cases - which is based on LDAP support.
My suggestion is to change this ticket from bug to a feature request. And for now add a notice to the setup documentation recommending the use of https.
Closes, because this is not an issue if https is used.