Wire-desktop: Authentication should always be Key-based

[xloem]

I create this issue to represent the password transmission concerns written up at https://crysp.uwaterloo.ca/opinion/wire/ .

The Wire client authenticates with a central server in order to provide user presence information. (Wire does not attempt to hide metadata, other than the central server promising not to log very much information.) The Wire whitepapers spend an unusual amount of space discussing the engineering details of this part of the protocol. However, the method of authentication is the same as it is on the web: the Wire client sends the unencrypted, unhashed password to the central server over TLS, the server hashes the plaintext password with scrypt, and the hash is compared to the hash stored by the server. This process leaks the user's password to the central server; the server operators (or anyone who compromises the server) could log all of the plaintext passwords as users authenticate.

Wire likely designed the protocol this way in order to make it easier to support web-based clients. Authentication mechanisms like this are standard on the web for historical reasons. However, since Wire has complete control over both the client software and the protocol, it is possible to do better. Wire should use a password-authenticated key agreement or a more sophisticated challenge/response protocol for user authentication. The advantage of these schemes is that they authenticate users without making the passwords vulnerable to data breaches on the central server. While the system would still be vulnerable to attackers capable of releasing malicious Wire updates, this would be a significant improvement.

[ghost]

May I suggest SRP.

https://en.m.wikipedia.org/wiki/Secure_Remote_Password_protocol

It proves that the user has the password without ever sending it, not even a hash. It also authenticates the server to the client as an added bonus.

[raphaelrobert]

This is on the list!

[gregor]

Due to the nature of this being a feature request, I am going ahead with closing the issue. This will continue to be tracked internally. We want to focus on bugs in the public issues list though.