4 ms·

This method isn't secure unless both the website and phone display a code (e.g. a short hash over a Diffie-Hellman, or other, shared secret and the session id)

by nly 11y ago

This method isn't secure unless both the website and phone display a code (e.g. a short hash over a Diffie-Hellman, or other, shared secret and the session id) so you can determine which session you're authenticating. Otherwise, anyone who can determine that you're logging in (traffic analysis is possible even if it's encrypted) can initiate a timing attack. I've also only glanced over the API docs, but it looks like the app just provides a secret to the server with each authentication request. So this is still essentially password authentication, you're just relying on your phone being more secure than a potentially key-logged terminal.

snupa 11y ago
The system has some built-in rules that prevent timing attacks from happening, so that only one authentication request may be active per user. A few other rules run in the background, preventing other similar attacks. In relation to the communication between the service server and our server, we're currently offering the traditional api key/secret method, but we will roll out RSA-enabled calls. In relation to the phone, users may pin-protect (for now, we're looking into additional methods) each individual profile. The main difference is that the user no longer uses the same communication channel (browser-server) to send the full set of credentials, with UNLOQ, a separate channel is used (device-UNLOQ paired connection)
- nly 11y ago
  If you use a PIN, make sure you encrypt the API secret with the PIN and do NOT store a hash or any other means by which to verify that the PIN is correct. I'd also suggest an (UNencrypted) secret device token such that you can actually detect when an app install is being used with a bad (incorrectly decrypted) API key and disable it after N attempts. This will prevent people abusing this policy for DoS against regular friendly usernames. If you do that, enforce TLS/SSL, and display a session code to stop timing attacks (even if you only allow one login at a time, it's still vulnerable to race), then it's not terrible.
  - nly 11y ago
    You should also add an API for session management, so I can always see what sessions are active under my account and kick them out if they look suspicious.

by nly 11y ago

snupa 11y ago

The system has some built-in rules that prevent timing attacks from happening, so that only one authentication request may be active per user. A few other rules run in the background, preventing other similar attacks. In relation to the communication between the service server and our server, we're currently offering the traditional api key/secret method, but we will roll out RSA-enabled calls. In relation to the phone, users may pin-protect (for now, we're looking into additional methods) each individual profile. The main difference is that the user no longer uses the same communication channel (browser-server) to send the full set of credentials, with UNLOQ, a separate channel is used (device-UNLOQ paired connection)

nly 11y ago
If you use a PIN, make sure you encrypt the API secret with the PIN and do NOT store a hash or any other means by which to verify that the PIN is correct. I'd also suggest an (UNencrypted) secret device token such that you can actually detect when an app install is being used with a bad (incorrectly decrypted) API key and disable it after N attempts. This will prevent people abusing this policy for DoS against regular friendly usernames. If you do that, enforce TLS/SSL, and display a session code to stop timing attacks (even if you only allow one login at a time, it's still vulnerable to race), then it's not terrible.
- nly 11y ago
  You should also add an API for session management, so I can always see what sessions are active under my account and kick them out if they look suspicious.