4 ms·

This to me seems like faux security. The server can just send its own custom key to an already authenticated device, which will gladly encrypt the main private

This to me seems like faux security. The server can just send its own custom key to an already authenticated device, which will gladly encrypt the main private key and hand it back to the server which can decrypt it. Even if the previously authenticated devices tries to directly communicate with the new device not via the server, presumably the server could also give its own IP as the new endpoint. I get that security is a bunch of trade-offs, but this seems post seems to present it as a fool-proof method, since the goal is to prevent the server from being able to see the private key ("how can the user's private key be transmitted in a way that doesn't reveal their credentials to the server"), and the given solution doesn't actually fulfil this goal.

kenforthewin 8y ago
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
- enedil 8y ago
  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.
  - zrm 8y ago
    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.
- ptoomey3 8y ago
  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.
sneak 8y ago
It is important to remember that this security model is not that much different than every other javscript app in which the app logic is delivered from the server. "We only handle keys clientside" is irrelevant when the server can ship code, at any time, that delivers keys, passphrases, or plaintext anywhere they like.

kenforthewin 8y ago

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

enedil 8y ago
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.
- zrm 8y ago
  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.
ptoomey3 8y ago
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.

sneak 8y ago

It is important to remember that this security model is not that much different than every other javscript app in which the app logic is delivered from the server. "We only handle keys clientside" is irrelevant when the server can ship code, at any time, that delivers keys, passphrases, or plaintext anywhere they like.