6 ms·
Passwordless login done right
- struct 11y agoCool idea, how is re-authentication handled beyond the initial sign up? Do you get a text message each time?
- millsuk 11y agoPush notification to your phone. They don't have iOS support yet which counts me out from trying it out.
- namochan 11y agoI 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.
- snupa 11y agoI'm curious, what device/android version do you have?
- mpatachi 11y agoWe've just sent today the iPhone app for review. Hopefully we'll have it in App store in a couple of weeks.
- esusatyo 11y agoWhat happens when you lose the phone?
- millsuk 11y agoYou can easily deactivate it. Would I use this for sensitive data? probably not as I use a password vault, but for non sensitive sites this looks like quite a slick approach.
- glaberficken 11y agoUsers understand the Username/Password workflow. Every attempt I've seen at improving this fails by introducing some new unexpected workflow complexity such as "sign in with google, fb etc" or "use your phone" I think devs should instead focus their efforts on making that standard Username/Password flow work as effortlessly as possible.
- sageabilly 11y agoMeeting users where their understanding is now and not trying to drag them along to where their understanding should be is definitely a challenge with replacing traditional workflows (like username/password, swiping a credit card, letting the waiter carry your card off for swiping, etc). The issue I see with this is that it's introducing another step into the process instead of removing a step or making it easier. Now, instead of just remembering a username/password combo, you have to 1) remember a username 2) Remember that the website that you're visiting has the option to use unloq.io (because they're probably going to offer both unloq.io and the standard username/password) 3) enter in username 4) find your phone 5) unlock your phone 6) wait for confirmation on your phone 7) hit allow 8) look up, reorient yourself to your monitor and mouse, and continue. Good UX involves taking away steps and streamlining flow, and until flow is streamlined and easier than the previous process users won't accept it.
- glaberficken 11y agoCouldn't agree more. Brings to mind the "unlocking a car door with a smartphone app" story that I read via HN a while ago
- olemartinorg 11y agoI'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 - and i try to log in using your email address a few seconds before/after you, wouldn't you think "oh, probably a fluke" and allow my login? How would you differentiate between logins? * If you're not that security-minded, you could have a desktop client as well - so you don't have to rely on your phone. At that point you could probably just have a browser plugin that does it all for you. (And at this point you're pretty close to what i already do with LastPass, although the site i'm visiting doesn't have to do anything special other that implementing a regular username/password login system.) EDIT: Also, as far as i can see from the Play Store screenshots, the app only asks you "Do you want to log in at <site>?". A far better solution would be to show the user a number sequence (or a cute cat or dog picture) on both the login page and the phone. If those two mismatch, the login attempt is not from your session.
- snupa 11y ago* Once you create an application, you can set how you want your users to provide their identity. You can ask just for the email, email+digits or just their phone number. However, when you deny a notification from your phone, the user is required to provide the second identifier (email requires additional last 3 digits, phone number also requires email, and email+digits requires the full number in addition) * The system only allows a single login per user, so if you have initiated the request first, somebody else would have to wait for you to finish the request until they can initiate it). There are additional limitations happening in the background that prevents spammy logins to reach the user's phone. * We're still trying to improve our UX, so we might take that in consideration for future releases
- olemartinorg 11y ago* So if i deny the login attempt on my phone, an attacker who knows my phone number can still log in to my account? Email + phone number is not two factors, it's zero (neither is a secret). * So what if the attacker started a login request a few milliseconds before i did? How can i differentiate between the attackers login attempt and mine?
- juriansluiman 11y ago> 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 biometrics. Am I missing something? By the way, not entering passwords is a fantastic way to login. I have been using the Passwordless [1] method for some time and it works great. [1]: https://passwordless.net/ https://passwordless.net/
- chrisfarms 11y agoI guess if the phone has a pin/pattern unlock... that could be argued as the "something you know" part.
- snupa 11y agoyes, currently the app has an optional pin unlock that you can set per profile. However, we're looking to add additional "something you know"'s on the user's part to minimize unauthorized access to the device.
- nodata 11y agoPerhaps the timing of the press is a factor.
- mfoy_ 11y agoI suspect some people have started to assume that "two-factor authentication" literally just means "phone/dongle".
- jackreichert 11y agoThe very fact that they claim that makes me uncomfortable with their knowledge of security.
- nly 11y ago
- daigoba66 11y agoIt's not two-factor. Your phone becomes an access card. Which is cool because you don't have to remember a password. But it's not two-factor.
- anExcitedBeast 11y agoThis isn't multifactor. Use an actual multifactor solution, like Google Authenticator or password+SMS.
- fixxer 11y agoThe fact that this made it to the front page is concerning.
- Globz 11y agoI fail to see the 2 form factor but here's something I found inside the documentation an application can request the last 3 digits of a user phone number + valid email to allow a successful login. http://unloq.readme.io/v1/docs/authenticate http://unloq.readme.io/v1/docs/authenticate DIGITS_REQUIRED Please provide the last 3 digits of your profile's phone number. (Only when application has its authentication type set to email and digits
- nly 11y agoThis 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 agoThe 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 agoIf 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
- cwmma 11y ago> 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.
- jrasmussen0 11y agoI thought this would be a write-up on SQRL https://www.grc.com/sqrl/sqrl.htm 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.
- cm2187 11y agoIt also has other merits. It is stateless (so all you need is to save the master key offline). And it doesn't rely on a third party (so no one else that you and the website you log in to knows about your relationship).
- nly 11y agoSQRL is worse in many respects. While it uses public key cryptography, which helps in the MITM scenario, it suffers from only weakly addressing the complexities of spoof protection (A malicious site, or a trustworthy but compromised site, can display a QR code for a different website or session). UNLOQ avoids some of this because it relies on direct notifications from the server to your phone (hopefully over TLS, which makes MITM unlikely)
- cm2187 11y agoBut do you know any system that can eliminate a MITM attack?
- korijn 11y agoI like how "extremely secure, 2 form factor, idiot proof login system" is bold and "once the user has the unloq app installed and configured" is not.
- buro9 11y agohttps://unloq.io/#/ https://unloq.io/#/ It's Free! (up to 10,000 users) And what happens then? What does it cost?
- shark234 11y agoBeing a bit paranoid, how do I know you won't login as any of my users without their permission? Or in other words, if your systems get compromised, how can I be sure that my system won't get unauthorised logins?
- tom_mellior 11y agoThe article starts with the words "Imagine you want to try the service offered by a site, but you have to log in to be able to do it." That's a problem statement, and the solution is clear: Let users try your service without forcing them to log in. That's it. It's that simple: Offer a demo. No third-party two-factor-authentication-by-people-who-don't-understand-what-two-factor-means stuff needed. Once you have people hooked, they will gladly open an account if they intend to return.
- nly 11y agoExactly. You can always create a demo session with a long-lasting cookie, and then associate it with a new users account when they eventually do register.
- mpatachi 11y agoFirst of all, thanks for all the great feedback. We’ve just launched in beta and we are striving to make UNLOQ the simplest authentication system. We know that we have a long way ahead of us so we appreciate all the feedback. Here’re a few answers to the comments I’ve seen above: 1. We believe it is a two factor: something you have = your phone; something you are = you’re fingerprint (for the phones that comes with this option and it is enabled); something you know = you’re PIN (you can set additional PIN’s on your profile). 2. Regular two factor provides you with a code to insert in the browser after you authenticated with username and password. We make use of two channels in order to authenticate a user: the browser used to provide the identity and the service’s server - UNLOQ server - device to provide proof of identity. We believe that this makes the system harder to break through man-in-the-middle type of attacks. 3. We know we still have to work on user experience, but entering just your email and then approving on the phone the request seems easier than entering the full set of credentials followed by another security code (as 2fa proposes)
- MacsHeadroom 11y agoEven if it is two-factor, for the reasons you described, it's all over a single channel. There is no out of band mechanism- meaning this can easily be MITM'd. UNLOQ is poor authentication security in more ways than one. By the way, the founders of Duo Security hold the patent on completing an authentication from a smartphone. Something to keep in mind. http://www.google.com/patents/US20110219230 http://www.google.com/patents/US20110219230
- devinegan 11y agoIt looks like that patent had a final rejection in 2013. http://portal.uspto.gov/pair/PublicPair http://portal.uspto.gov/pair/PublicPair (13/039,209)
- jasonlotito 11y ago> Well, the above scenario is not science fiction anymore. Proceeds to describe something that is not the above scenario. Secondly, this ignores the reality that phones in the hands of real users are not a reliable means of identification. People lose or change their phones all the time. Next, this creates a massive road block for users in trying to sign up. As it stands now, unloq limits itself to a single email for a single user. This also ties your authentication to a third party service. What assurances does unloq provide should they go the way of seemingly every other startup these days? What happens when Google buys them? The "Passwords are obsolete" mantra is built around one assumption: "Specifically, the ability to send an email or SMS to users reliably and quickly." And the problem with that assumption is that it's wrong. Wrong, wrong, wrong. 100% wrong. Relying on a system like this will cause problems for your users, and it will be impossible to fix with software.
- mpatachi 11y agoThanks for the feedback. A few answers: "As it stands now, unloq limits itself to a single email for a single user." -> We do offer the option to create additional profiles on others email a user might have. "that phones in the hands of real users are not a reliable means of identification" -> We do agree that phones by themselves are not secure enough. Currently we do offer the option to add a secondary PIN on each profile, but we are thinking to enforce it to the application level.
- jasonlotito 11y ago> We do offer the option to create additional profiles on others email a user might have. I looked at the API, and it didn't offer that feature. > Currently we do offer the option to add a secondary PIN on each profile, but we are thinking to enforce it to the application level. So a password.