[snupa]

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]

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]

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.