Live data from Hacker News

Passwordless login done right

programming.tudorconstantin.com

21–30 of 56 posts

Re: Passwordless login done right

#21
> Think Fort Knox like. We use the same algorithms approved for top secret information like AES 256, SHA3 and public-private key encryption.

statements like this make me very very nervous as AES by itself is basically useless and the impotent part being how they use AES.

Re: Passwordless login done right

#22

I'm intrigued! But a few questions/comments: * How is this two-factor? I only see one factor (a thing you have, your phone). Email adresses are not secret. * Again, email adresses are not secret. How do you limit login-spamming? I don't want to wake up in the middle of the night because someone is trying to break into my account. * What about timing attacks? If i stand over your shoulder while you're in the library -…

I have a question too. How do you avoid being spammed by someone creating a new account with your email or sending "forgot password" over and over?

Re: Passwordless login done right

#23
I thought this would be a write-up on SQRL https://www.grc.com/sqrl/sqrl.htm that uses QR codes and a secure identity database on your phone to authenticate you. Unlike the article, SQRL is an open protocol that can be developed and used by anyone. It is in alpha stages but I have used a prototype and it works really well.

Re: Passwordless login done right

#24

> Basically, this is an extremely secure, 2 form factor, idiot proof login system As far as I know, factors are 1. Something you know (password) 2. Something you have (a dongle or phone) 3. Something you are (iris or fingerprint) With only pressing a button on a phone, how can this be two-factor? There is no password ("passwords are obsolete" and usernames are not a knowledge factor in multi auth) and nothing of biom…

I suspect some people have started to assume that "two-factor authentication" literally just means "phone/dongle".

Re: Passwordless login done right

#25
post #22

I'm intrigued! But a few questions/comments: * How is this two-factor? I only see one factor (a thing you have, your phone). Email adresses are not secret. * Again, email adresses are not secret. How do you limit login-spamming? I don't want to wake up in the middle of the night because someone is trying to break into my account. * What about timing attacks? If i stand over your shoulder while you're in the library -…

I have a question too. How do you avoid being spammed by someone creating a new account with your email or sending "forgot password" over and over?

Good point, you don't. But on the other hand, filtering out an email you don't want is easy (in most email clients), so you won't get a notification each time. I'm assuming this app has no filtering, so if someone wanted to DOS me with this, they could - there's no way i could (or would) handle a ton of login requests per second to try to find the login request i initiated. You can't DOS someone with account signups or the "forgot password" functionality, as they could still log in to whatever service they need (while their mailbox fills up).

Re: Passwordless login done right

#26
post #15

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 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)

Re: Passwordless login done right

#27
post #22

Earlier quoted context omitted.

I have a question too. How do you avoid being spammed by someone creating a new account with your email or sending "forgot password" over and over?

Good point, you don't. But on the other hand, filtering out an email you don't want is easy (in most email clients), so you won't get a notification each time. I'm assuming this app has no filtering, so if someone wanted to DOS me with this, they could - there's no way i could (or would) handle a ton of login requests per second to try to find the login request i initiated. You can't DOS someone with account signups…

The app actually has a firewall, preventing DOS attacks on the user. The main rule is that only one authentication request can be active per user, so the user will always receive ONE push request at a time. Also, when you create an app, you can specify the number of authentication requests you expect, coming from your app. You can (currently) set it from 1 to 25 requests / second. So if somebody would try and DOS you, UNLOQ will limit and filter these requests.

Re: Passwordless login done right

#28
post #26
post #15

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 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 pho…

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.

Re: Passwordless login done right

#30
post #5

Earlier quoted context omitted.

Push notification to your phone. They don't have iOS support yet which counts me out from trying it out.

I have quite a few android devices, but the play store tells me that "This app is incompatible with all of your devices". But I'll keep an eye on this, seems nice. I guess it's two-factor enough, because I have a password on my phone.

I'm curious, what device/android version do you have?
Post reply on HN