Sending secret key over HTTPs

[kaosdynamics]

Secret key is supposed to be unpredictable and kept secret because anyone who knows the secret can generate the code at any time.

Speakeasy sends it over an HTTPs request.

While we're sending it to Google - can we trust it? Some might say 'yes', some might say 'no'; infosec says 'no' - we're sending it over an HTTPs GET request: even if it is a request over SSL, it doesn't secure the data passed via GET, and so the secret is exposed while it gets transmitted to any party who has control over the network.

Speakeasy should thus try to generate a QR-Code on the server side.

[markbao]

Kaos, thanks for your comment. I agree—I personally wouldn't send over keys to the Google API—but it's an option that is set to false by default:

qr_codes (default false): generate links to QR codes for each encoding (ASCII, hexadecimal, and base32). It uses the Google Charts API and they are served over HTTPS. A future version might allow for QR code generation client-side for security.

Security-conscious folks should use a library such as node-qrcode.

I'm hesitant to add a dependency to node-qrcode and do this by default since that might add bloat, but I'm happy to hear other opinions.

[gcochard]

even if it is a request over SSL, it doesn't secure the data passed via GET

@kaosdynamics This is completely untrue. GET queries are still encrypted in a TLS connection. Try loading up https://google.com/?q=tls with wireshark/tcpdump watching. You'll see the TLS handshake (with the domain name if your browser supports SNI). That's the extent of the visibility into a TLS GET request.

It's true that you should not send secrets to a third-party, as it is bad practice and opens you up to additional attack vectors. Querystring parameters can (and do, by default) get logged by most web servers, and they are shown in the clear in the browser history. It's not as dire as you're implying however.

Just wanted to set the record straight.

[rvdmla]

If I would use node-qr to generate the QR on my server rather than using Google's service, could the secret key still be reverse engineered by someone intercepting the QR using MITM between my Node server and my client?

[gcochard]

If you are using https, then nobody should be able to MITM the connection. if they do MITM, the secret will be compromised.

[rvdmla]

That's what I thought, thanks for confirming @gcochard

Might be something worth stressing in the README. If any part of the key or QR are sent over non-secure HTTP the entire system becomes easy to compromise and basically moot. This might not be obvious to first time users.