Hacker News Reader

Comment by kenforthewin | Hacker News Reader

In that case, the authenticated device could have the ability to show the public key before accepting a request, and match it with the public key generated on the new device. But yes, at some point you'll have to put trust in the server not doing malicious things like that, which is one reason it's open source

View on HN

Sorry for blunt words, but that's bullshit. If there is no proof a client is secure from malicious server, then this system is useless from the security point of view. You can have open source solution, but you might be running tweaked version.

The key is to have an open source client and a protocol that protects against a malicious server.

One way to do this is to have the new device generate a random passphrase, display it on the screen and require it to be typed into the already authenticated device. Then the devices can use PAKE with that passphrase to establish a secure channel between each other. Even if the data still goes through the server, it's encrypted and the server can't read it.

Another method is to have the new device display its public key as a QR code and have the existing device scan it.

I think the trick is to push the trust up a level to the platform owner (you have to trust someone at some point) via webauthn or something. If you do that, then the browser itself can be the one the be trusted to show the actual public key being added. As long as you are relying on the server itself to serve trustworthy JS to show and validate the new public key, you are kinda stuck.

Reply on news.ycombinator.com