I run a fair number of sites, and I don't want to hold people's passwords.<p>Today I use auth0 configured as a passwordless solution, i.e. email code + login, or use Google OAuth, etc. You can see it working on sites like <a href="https://www.lfgss.com/" rel="nofollow">https://www.lfgss.com/</a><p>I would consider another solution, but I'm not sure that this is it.<p>The information is sparse, as a site-owner it hasn't really sold me on:<p>1. how this works<p>2. that the first login friction for the user is low/effortless<p>As I understand it, this is not a "password manager", but more along the idea of a "login manager" that you install locally.<p>And, if you do not wish to install something locally then there is a browser bit which I think is in JS and this is "less secure" and "slower"... but this in itself puts me off the whole idea because I think the browser bit is what most people will use, and that security is fairly boolean so "less secure" probably equals "not secure". If this is just a communication of risks, then those are not being communicated.<p>But I'm curious enough to want to know more, so I googled, found his Twitter, looked through and saw others asking similar things to which the author response amounts to "read the code".<p>It feels like a poor sell, because whatever this is may well be the kind of thing I'm looking for. But I just do not know.<p>Changing authentication is such a big thing that I can't see me moving from passwordless auth0 unless the communication is super effective... not just for me as a site owner, but also for end users who will wonder what it is being asked of them and whether to trust it.
I'm a little unclear on how this is more than a serverless password manager with Nacl public keys instead of some symmetric algorithm generating per-site passwords.<p>There are lots and lots of serverless password managers, and their uptake is even lower than that of real password managers.<p>Is the cleverness here that this one is exploiting modern browser API to quietly embed the whole thing in localStorage so that users don't have to install it?
This is a very interesting concept. I'm pretty sensitive to UX issues, and I'm yet to see nicely implemented and secure auth flows. All non-OS-native 2FA solutions (Google Auth, Duo) seem a bit cumbersome (and require additional efforts to implement and to setup for the average user). Apple does auth right with their Touch ID (both for logging in and to confirm transactions). I see a potential for SecureLogin to be as close to that Touch ID user experience as possible.<p>While I see the potential, I understand that this is an initial implementation, so it has UX issues:<p>1. First and foremost, the user has to download an app in order to sign into your service. That's a huge ask. Service providers will be hesitant to implement this, since this will mean losing customers. The implementation has to be really polished for this to gain traction, IMO. Without getting initial traction, it's less likely that this can be implemented natively in browsers/OS, where this technology makes more sense and can have better UX. Kind of a catch 22.<p>2. Related to 1: A 50+MB Electron app is definitely not a casual download. It has to be as lightweight and OS-native as possible. For most likely use case (web app authentication), did you consider using browser extension that would store the data locally? Might be a good alternative to a downloadable app at least for that common use case.<p>3. When signing in, it asks if one has the app installed. I don't want to be asked. If the app is not there, I want to have it installed in one click, and then have the auth retried. And visiting a separate <a href="https://securelogin.pw/" rel="nofollow">https://securelogin.pw/</a> site for downloads is not the best option as well. This bootstrapping process is very important. Again, a browser extension might help with this, since it can communicate with the page and make itself discoverable.<p>4. As I understand, Cobased is your reference demo app. As such, it needs more polishing/explanation (read: some narrative in addition to the UI).<p>---<p>And a non UX-related question: nowadays people not only value security, but anonymity as well. Does SecureLogin have to pass profile email address back to the app? Can the protocol work in the way that simply uniquely identifies the user for the target service via providing some service-unique token but not disclosing an email address? In other words, the protocol might benefit from the fact that no one can link account on service A to the account on service B.
Tried demo on chromebook. It failed. Read github. Requires native app... written in JS? Relies entirely on single password that can be forced out of me. No mention on how to sync across devices. Nice try. I think it has a lot more to work out.<p>"Classic passwords/2FA are poorly designed, hard to backup and inconvenient to use."<p>That's insulting. Stop that. Want to state that as your personal experience, fine. You are really too young to declare that with any authority. Quote a crypto legend or take that out. You will alienate a huge pile of developers you claim to be courting.<p>"SecureLogin's #1 goal is to fix password reuse"<p>That by itself is easy to solve. Generate the password for the user.<p>"Usability: existing onboarding process is a disaster for conversion"<p>Requiring a native app is a disaster.<p>"Central authority"<p>You're confusing out of band authentication with centralization.<p>"no iOS support"<p>SecureLogin can't guarantee their native app won't be pulled from Apple's app store.<p>"open source"<p>LICENSE.txt not found.
I like the idea, but the master password scares me a bit. So if I accidentally type my master password into Slack one day (not that that has ever happened), it seems anyone who saw it would then immediately be able to log into every website using SecureLogin as me.<p>The README addresses a concern about "Master password is single point of failure in this system", but it talks about the case of a user forgetting it, not accidentally disclosing it.
homakov, a lot of work need to be done:<p>TLDR. Your technical writing is bad and it is putting lots of people off.<p>1. Learn to write arguments properly. Your claims are outright wrong and ridiculous. You provided no strong evidence thus just reading your blog post put off lots of people.<p>Examples:<p>"It is production-ready to be used by four Billion people by tomorrow morning" -> no, it is not. You are underestimating the time complexity of integrating your project with existing apps. Show me how many people are using SecureLogin 24 hours from now? By the way "tomorrow morning" without an exact date is vague.<p>"terrible usability. First one offers you to write down backup codes on a paper (which I never did)" -> use your personal anecdote as an evidence is not strong unless you show me statistics of how many people who wrote down backup code (I did).<p>2. Learn to write protocol documentation properly. At least include a figure of the protocol flow and pointer to your code location. No matter how interesting is your concept, many people will be put off digging through your github project to understand the protocol. Not everyone is familiar with Javascript.
This is a pretty cool scheme, but I'm not sure about the UX argument. The login flow itself is good UX, but it's arguably just the happy path, and now I'm responsible for irreplaceable data on my device. My device might fall into a river, or a customs lockbox. I can mitigate that but then I'm doing manual secrets management work that "eh, I'll just trust my email provider" would have prevented.
My email address is not my identity.<p><a href="https://github.com/sakurity/securelogin/issues/3" rel="nofollow">https://github.com/sakurity/securelogin/issues/3</a>
<p><pre><code> > Cryptographic key never leaves your device
</code></pre>
Isn't that a huge usability issue? I use multiple devices, phone, laptop, desktop. How do you propose being able to log into the same website on more than one device if the key is on the original device?<p>Also, have you reviewed Web Authentication specification? It sounds very similar.
Yes! As a site admin in today's world, you should indeed not want to store passwords. Or even personal data for that matter.<p>I applaud this initiative since it lists exactly the reasons why we started Authentiq: Decentralization, usability, privacy, safety for end users (which is very different from merely offering security features that most people don't use).<p>Authentiq is similar in goals and architecture, yet with a more comprehensive feature set, since we aim to support existing standards (like OIDC) as the integration point for developers, and offer a more complete mobile identity to end users so that the site owner doesn't need to store those details either.<p>That said, I'm very keen to see if we can add support for the OP's authentication protocol soon. Check us out here if interested: <a href="https://www.authentiq.com/" rel="nofollow">https://www.authentiq.com/</a>
I had a question about the following passage:<p>>"Currently the only way to have safe authentication is to either enable TOTP (like Google Authenticator) or using a USB stick like U2F.<p>Both you need to do manually so practically nobody is doing that. They both provide terrible usability. First one offers you to write down backup codes on a paper (which I never did), second one is barely supported by anyone."<p>Aren't many people using Google Authenticator/Yubico/Push Duo versions of TOTP for github logins, gmail and bastion hosts? I thought this was becoming increasingly more common. At least its been pretty standard in the shops I have worked at in the last few years.<p>Also Github, DropBox, Fastmail, Gmail, Wordpress, Chrome, GitLab and BitBucket all have support for U2F:<p><a href="http://www.dongleauth.info/" rel="nofollow">http://www.dongleauth.info/</a>
If you hit OK that you have the client, but you actually don't, suddenly you can't do anything at all on the website... Also, imo, asking to install an app, no matter what app, is going to be way less likely to happen then any other kind of login, as I don't like putting trust in random third party software.<p>In addition, the web client seems defective, you "create an account", and then get a control panel, and have to go back and try the login again on the original demo. Very counter intuitive.
Great idea! Exactly this is implemented across pretty much all "important" services in Sweden (Tax office, banks, pension funds, money transfers etc), it's called BankId: <a href="https://www.bankid.com/en/" rel="nofollow">https://www.bankid.com/en/</a><p>It's a great concept but currently somewhat limited to government and financial services, I would love to see something similar get good traction!
Why is Authy called unsafe by the Author and Google Authenticator safe? Ever heard that it is more likely that your smartphone gets lost, broken and stolen than your precious online account getting hacked? I'm very happy I had Authy when I was in a foreign country and my Nexus 5X stopped working (BTW: damn you LG for your poor engineering!)
I think your idea is brilliant but needs a bit o polishing off.<p>Because every website is different everyone has different requirements, and a solution would be to just use the public key as the identifier instead of the email.<p>And for backup purposes as master password, I would suggest making it very similar to Trezor and generate for the user with a good RNG a 24-word mnemonic. I know is a hard task to write down for some but you don't do it every day, and you know you're safe if you lose your device or make use of it on a different device. I wouldn't want to rely on the user to memorise it or generate it, especially when users do not generate a good entropy.<p>I would personally recommend using Trezor as guidance. This is my demo: <a href="https://cl.ly/1P0N0W1t1a3B" rel="nofollow">https://cl.ly/1P0N0W1t1a3B</a><p>I would be happy to implement it in my systems if it follows the principals above.
Hey homakov, nice work. might want to remember to encodeURIComponent() around the keys as well:<p><pre><code> SecureLogin = function(scope){
function toQuery(obj){
return Object.keys(obj).reduce(function(a,k){a.push(k+'='+encodeURIComponent(obj[k]));return a},[]).join('&')</code></pre>
I'm not too familiar with ruby/rails, but does this mean the HTTP request just sits open for up to 20 seconds? Is this common/acceptable practice?<p><pre><code> # user is given 20 seconds to approve the request
20.times{
sleep 1
sltoken = REDIS.get("sl:#{state}")
break if sltoken
}
</code></pre>
<a href="https://github.com/homakov/cobased/blob/master/app/controllers/application_controller.rb#L18" rel="nofollow">https://github.com/homakov/cobased/blob/master/app/controlle...</a>
Cool. I created a similar protocol a couple of years ago but it never got beyond a weekend project, see here for a diagram: <a href="https://github.com/jtwaleson/vault" rel="nofollow">https://github.com/jtwaleson/vault</a><p>The client worked with QR codes so you could login with just your phone. The app would verify authentication using a websocket/long-polling so as soon as you scanned the QR code you'd be logged in. Most banking apps now use a similar technique, which is a good UX imho.
How does revocation work? It sounds like a pain, almost as much as currently.<p>Any credential I can't change is a credential I won't consider.
How does it compare with SQRL? What does SecureLogin better? It like SQRL's QR code approach very much so that you can easily go to a public computer and login by just using pointing your phone to the screen.
About time that this gets addressed where it should - in the browser:<p><a href="https://www.w3.org/TR/webauthn/" rel="nofollow">https://www.w3.org/TR/webauthn/</a>
Interestingly, a few days ago Google Authenticator asked me if I wanted to switch to a simple confirmation (instead of manually entering the 2FA token).
I don't see any discussion about what this does besides decentralisation. Care to explain how it is securing through decentralisation? Is this some blockchain based solution?
I'm already highly sceptical because of the authors previous "solutions" for "a password replacement": just rely on one time password links via email. When the subject of mailbox security is mentioned he responds with "I'm not trying to solve <i>that</i> part of the problem". Right.<p>So of course, we get the ridiculous statements like:<p>- complaining that TOTP provides a system for fallback codes. The author didn't write them down, and of course they're stupid and pointless and let's quickly forget about them because his "solution" has literally no fallbacks.<p>- responses in this thread where the author says "well what if a bank just steals your money?", when someone mentions that even credit cards are easier to revoke: you can call the bank to cancel the card.<p>- responses to questions about it's open source status (because no License was specified) that seem more like a fucking lunch order at Subway: "which one is your favourite?". This leads on to one of <i>my</i> favourite bits in this thread:<p>- This absolute gem (emphasis mine), from the author who claims it's "production ready for four billion people":<p>> I don't want to have any rights or <i>responsibility</i>, just Do Whatever You Want license.<p>The author loves to dismiss current solutions with weird anecdotal evidence. He freely admits he doesn't use TOTP on many sites, even when it's available. He never "signs out" of applications. He claims that users "don't care" if their account on a site is breached.<p>For reference, the "current solution" that I believe still beats this system is:<p>Password managers, with a secure "master" (i.e. keychain on iOS is unlocked by TouchID/ system pin) combined with TOTP are achievable, don't rely on a fucking electron app, and provide fallbacks if a 3nd factor authentication device is lost.<p>But ultimately all of that is just gravy when you look at the most basic of irony in this whole thing:<p>The author's stated <i>goal</i> is to remove the need for passwords, because user's don't create strong passwords, they write them down, etc. His "solution" to that, is a system whereby users <i>entire</i> (for sites using this system) security is based on a single pair: email address, and a "master password" that, you guessed it - the user HAS TO REMEMBER.<p>I'll leave you with one final though: <i>if</i> this ever gets any real-world usage, how long until bad actors start gaming the system, by presenting "Proceed with SecureLogin" buttons that show a dupe of the existing web UI to convince users to enter their email/password, and then hey presto, they have access to <i>all</i> SecureLogin-enabled sites that user has an account on.<p>Edit: formatting.