I however have one big problem with this method : f(password) has here the roughly same security as password : if the database leaks, any attacker could authenticate as anybody else. This method provides an anti-replay functionality : an attacker could not capture the data and replay it later to authenticate. It also invalidates the challenge to invalidate any future attempt using this challenge. The server verifies with the username's data and the challenge the response and if so, authenticates the user.The client would send in "plain text" the username and the challenge and an hash (with a SHA2 or SHA3 algorithm) of challenge || username || f(password),į(password) being how the password is stored in the database (a SHA256 of password for instance).The server would set up a random set of bytes (the challenge), set a timeout at the end of which the challenge wouldn't be authorized. If you want security, transmitting authentication data through TLS is a big start.īut let's assume the websocket is already set up over TLS.Ī solution I would recommend would be based on a challenge-response mechanism :
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |