18 ms·

SecureLogin Authentication Protocol 1.0

ben0x539 9y ago
Curious to read more about the planned DoubleSign thing, not sure if it's spelled out anywhere.
- homakov 9y ago
  So DoubleSign is pretty cool for financial apps because it signs `scope` on two devices. First prototype had that feature. But it was very unclear to the users. So it was removed, but will be added back if this 1.0 version gets used by well... anyone at all :)
ben0x539 9y ago
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.
- level3 9y ago
  It seems like your device is completely replaceable in this scheme. The keypair is derived solely from the email address and the master password, so you can just generate the same keypair on a new device.
  - homakov 9y ago
    Exactly - everything can be derived from password. It's simplest backup strategy possible.
    - ben0x539 9y ago
      Ah, so it's like sharing one password for everything? Edit: Yeah, with the crucical difference that you don't need to worry about the server's user database getting leaked along with your password.
      - homakov 9y ago
        There are many differences, because your password used just once to create root hash. From root hash private key is generated, and no one is sharing password anymore
tchow 9y ago
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?
- rocqua 9y ago
  It's essentially the offline password manager idea with some kinks worked out. The offline password doesn't use an encrypted database, but instead used a key-derivation function based on a master password and e.g. the service name to get deterministic passwords. In the case of a password manager, there are issues with password requirements and service name reuse. Here, by switching to a signing protocol, those issues are mitigated. At the same time, because this isn't the password protocol, it forces users to use this app. Meanwhile, you can't force users to use a password manager, leading to horrible password reuse. The big downside I see is the immediate compromise upon revealing your master password. In the case of a PW manager, your opponent needs to get to your database first. This might give you time to roll-over your passwords. Another thing I don't see is key-revocation. What to do when you fear your master password is compromised? That might just be done by essentially the same as a password change though.
  - level3 9y ago
    If this protocol got implemented widely, I think there would be some value in creating an alternative app that essentially combines this with a local password database. The app could automatically generate site-specific keypairs, and you would still only need to memorize your master password. This combination would solve the problem of your master password being disclosed (your opponent still needs to get your database), while retaining the benefit of giving sites only your public key instead of a usable password.
    - smichel17 9y ago
      The biggest problem here is multi-device support. Right now you can enter the same email + mpw on a different device and it just works. Adding a local secret means you must manually transfer that to any new device. Seems like a good feature for people with stronger security requirements (eg, journalists), but not the average user.
TrickyRick 9y ago
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: https://www.bankid.com/en/ https://www.bankid.com/en/ It's a great concept but currently somewhat limited to government and financial services, I would love to see something similar get good traction!
- arnarbi 9y ago
  BankId is not even close to this. It's a centrally managed PKI, which exists in many countries. This is another password=kdf(site data, master pwd) protocol.
  - homakov 9y ago
    Not another... It's more flexible kdf(site data, consumer, scope, expiration, master pwd) protocol, allows to prevent many other attacks and replace OAuth all in one.
    - arnarbi 9y ago
      Why replace OAuth? That's an authorization protocol. Do you mean OpenId Connect? In any case, I strongly believe these things should be managed by user agents: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.
      - homakov 9y ago
        Check "change password" section for rotation of one profile to another. It's quite simple Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)
kennydude 9y ago
This, to me, sounds like Mozilla Persona
- homakov 9y ago
  The goal is similar, but not execution. I don't know all specs of Persona - learnt about it when it was being deprecated - but the key difference SecureLogin cannot be deprecated. "All user data stored on the persona.org services will be destroyed, including registered email addresses and password hashes" And hey, there's nothing on SL servers.
- floatboth 9y ago
  More like SQRL, but without the ability to authenticate from a different device (smartphone)
  - homakov 9y ago
    Yes, you can only auth from current app installed on current device. No QR codes involved :)
tptacek 9y ago
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. There are lots and lots of serverless password managers, and their uptake is even lower than that of real password managers. 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?
- homakov 9y ago
  Thomas, many times I made a point that if auth solution is not enforceable it's not going to be popular. You like 1Password and it has reasons to be loved. But let's take it real and look at password reuse problem. Can you admit that password managers and/or 2fa are not what we need and where we should stop for securing users? We always needed an __enforceable__ protocol that has clear flow for the user. Button. Download, Generate profile, use to login anywhere. I thought it was made clear that it has nothing to do with password managers. It's an authentication protocol that's 1) decentralized 2) extremely usable 3) scalable. That's all it is.
  - tptacek 9y ago
    I'm not saying people should use 1Password instead of this. I'm actually not recommending anything, just trying to get my head around the concept. Reading the Github page, the impression I was left with was that this was essentially the same thing as an auto-installed site-specific serverless password manager. Is that incorrect?
    - homakov 9y ago
      It's mostly correct, but it really is not a password manager. Manager is a helper for some people, protocol is a requirement for all. So I want to draw a line between protocol and a manager. It's like https://getclef.com/ https://getclef.com/ or SQRL or Mozilla Persona, but not exactly a manager. By being a protocol it can be _legitimately_ deterministic (you know why deterministic managers aren't great, Tony Arcieri wrote a good post) By being deterministic it can be absolutely free and scalable By being scalable and free I hope it has a chance for being popular (no vendor lock-in). No real innovation, definitely, but in little details it's a good balance of existing things.
therealmarv 9y ago
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!)
- homakov 9y ago
  Authy service (one where they send you SMS) is centralized. It's not that it's safe or unsafe, but generally decentralized is better option.
  - zwily 9y ago
    Authy also can backup your TOTP tokens (encrypted with passphrase on device). This is super handy when switching devices, but weaker than Google Auth where the TOTP private bits never go back to Google in any form.
    - homakov 9y ago
      Yes, sorry, that TOTP backup thing is great. Always hated that GAuth cannot back up. But what was meant is the SMS service they make money on.
  - rocqua 9y ago
    There have been quite a few cases where SMS authentication proved unsafe. It's gone so far as NIST recommending against SMS as a 2nd factor. In short, providers are rather too willing to transfer a mobile phone number.
- avenoir 9y ago
  Just a few days ago I received an email from Coinbase asking to switch from Authy to Google Authenticator. The reasoning was: > Authy and SMS are vulnerable to phone porting attacks. Device based Authenticator apps like Google Authenticator mitigate this by being linked to your device, not your phone number.
zwily 9y ago
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. 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 9y ago
  It's more about password hygiene. Do you have any advice how to prevent disclosing not making UX harder? I would happily implement it.
  - zwily 9y ago
    Agreed on the hygiene... However, we're humans, and even the best of us will make a mistake at some point. The impact of that mistake in that scheme seems potentially catastrophic in a way that's different from traditional password managers. I don't see an easy way to fix it given your design goals (which I really like!)
    - homakov 9y ago
      I never really tried to type my password and hit Send, so I never worried about this case. Hygiene has to be reshaped to understand how important master pw is compared to all pw we used to type, like 123456.
      - zwily 9y ago
        The times I've seen people type passwords into Slack has usually been because they had the wrong field focused, and autopilot typed the password and hit Enter. (To be clear, this complaint applies to all schemes that rely on passwords derived from a master password.)
        GordonS 9y ago
purvis 9y ago
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? # user is given 20 seconds to approve the request 20.times{ sleep 1 sltoken = REDIS.get("sl:#{state}") break if sltoken } https://github.com/homakov/cobased/blob/master/app/controllers/application_controller.rb#L18 https://github.com/homakov/cobased/blob/master/app/controlle...
- homakov 9y ago
  It's not common, but the quickest way I could find to reduce # of roundtrip requests. Happy to hear why unacceptable.
  - purvis 9y ago
    My initial concern was an aggressive server timeout on nginx/haproxy. I think the defaults should be long enough, but it's entirely possible to have something lower than 20 seconds. (and the app developer might not even be aware of this) I have no reason to think it's unacceptable, was just curious. Interesting project!
  - zwily 9y ago
    It just means you're tying up a thread (or whole process, if your rails app isn't running with threads) waiting for the response.
    - homakov 9y ago
      It's not a requirement though: one may ping from the client side with setInterval.
leni536 9y ago
What about making client side public key auth not a UX disaster in all major browsers?
- homakov 9y ago
  In my opinion SL does exactly that: another take on client side public key auth. It's not built in the browser on purpose for flexibility.
buro9 9y ago
I run a fair number of sites, and I don't want to hold people's passwords. 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 https://www.lfgss.com/ https://www.lfgss.com/ I would consider another solution, but I'm not sure that this is it. The information is sparse, as a site-owner it hasn't really sold me on: 1. how this works 2. that the first login friction for the user is low/effortless As I understand it, this is not a "password manager", but more along the idea of a "login manager" that you install locally. 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. 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". 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. 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.
- homakov 9y ago
  >1. how this works So if you are a developer, your best bet is "How it works?" here: https://github.com/sakurity/securelogin https://github.com/sakurity/securelogin If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/ https://sakurity.com/) Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL: With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves. > If this is just a communication of risks, then those are not being communicated Correct, that message is not very informative. I think it will be removed.
deleted 9y ago
[deleted]
bogomipz 9y ago
I had a question about the following passage: >"Currently the only way to have safe authentication is to either enable TOTP (like Google Authenticator) or using a USB stick like U2F. 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." 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. Also Github, DropBox, Fastmail, Gmail, Wordpress, Chrome, GitLab and BitBucket all have support for U2F: http://www.dongleauth.info/ http://www.dongleauth.info/
- homakov 9y ago
  Supporting != users are using it. Especially outside of tech bubble. I myself always cringe when forced to setup TOTP. Yes, I seriously would rather take the risk of my gmail reset compromise than dealing with TOTP again.
  - bogomipz 9y ago
    They were two different sentiments: 1) "practically nobody is doing that" - TOTP. The "tech bubble" is not an insignificant number of people. 2) "barely supported by anyone" - U2F. If you look at the link I posted there are a number of services with extremely large user bases that are supporting it.
    - homakov 9y ago
      >The "tech bubble" is not an insignificant number of people. Count # downloads of G Authenticator on Play Store - ~10M. To 4B of internet users. By anyone I meant platform support. U2F on iOS? U2F outside Chrome? etc.
      - bogomipz 9y ago
        The count of Google Authenticator in the Play store is between 10,000,000 - 50,000,000 [1] The MS authenticator has between 1,000,000 and 5,000,000 [2] These stats are just for Android devices not iOS. 10's of millions of users is not insignificant. Why does the global number of internet users matter here? [1] https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en https://play.google.com/store/apps/details?id=com.google.and... [2] https://play.google.com/store/apps/details?id=com.azure.authenticator&hl=en https://play.google.com/store/apps/details?id=com.azure.auth...
danjoc 9y ago
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. "Classic passwords/2FA are poorly designed, hard to backup and inconvenient to use." 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. "SecureLogin's #1 goal is to fix password reuse" That by itself is easy to solve. Generate the password for the user. "Usability: existing onboarding process is a disaster for conversion" Requiring a native app is a disaster. "Central authority" You're confusing out of band authentication with centralization. "no iOS support" SecureLogin can't guarantee their native app won't be pulled from Apple's app store. "open source" LICENSE.txt not found.
- derefr 9y ago
  > Requiring a native app is a disaster. Not if this is a reference implementation of a protocol that ends up built into operating systems. If the point is to be a reference implementation, though, I'd rather it was a reference implementation of, say, better OS/browser handling, syncing, and UI for TLS client certificates.
  - zyx321 9y ago
    It baffles me that no one else mentioned client certificates. That's like Crypto 101, but the author of this software seems unaware it even exists (it's not mentioned in the comparison on the GitHub page)
    - homakov 9y ago
      I'm aware. It's the thing nobody uses. There's no need to compare with it. I'd rather add https://www.youtube.com/watch?v=VgC4b9K-gYU https://www.youtube.com/watch?v=VgC4b9K-gYU
      - 9y ago
borplk 9y ago
How does this compare with SQRL?
- homakov 9y ago
  I couldn't find any working clients of SQRL/demo? Will happily add it to comparison table.
  - botto 9y ago
    I use the android SQRL client https://play.google.com/store/apps/details?id=net.vrallev.android.sqrl https://play.google.com/store/apps/details?id=net.vrallev.an... Then you can see the headers that are exchanged. https://www.grc.com/sqrl/diag.htm https://www.grc.com/sqrl/diag.htm
mtarnovan 9y ago
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).
- voltagex_ 9y ago
  I'm guessing that's only supported with Google services though.
  - mtarnovan 9y ago
    Indeed, at least for now.
joshka 9y ago
My email address is not my identity. https://github.com/sakurity/securelogin/issues/3 https://github.com/sakurity/securelogin/issues/3
iafan 9y ago
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. While I see the potential, I understand that this is an initial implementation, so it has UX issues: 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. 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. 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 https://securelogin.pw/ https://securelogin.pw/ 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. 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). --- 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.
- lobster_johnson 9y ago
  The enterprise version of Duo apparently works by having the mobile app wake up to ask you for confirmation for the login -- similar to how Apple's Touch ID automatically opens to confirm things like Apple Pay if you initiate from the desktop -- rather than making the user open the app, select the account and generating a number. I don't know what protocol is used, and I've never tried it, because it's not part of the single-user Duo Mobile app. But this always struck me as a much more user-friendly way of doing 2FA than the Google Authenticator style that generates numbers that you then have to manually enter.
skion 9y ago
Yes! As a site admin in today's world, you should indeed not want to store passwords. Or even personal data for that matter. 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). 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. 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: https://www.authentiq.com/ https://www.authentiq.com/
- homakov 9y ago
  > I'm very keen to see if we can add support for the OP's authentication protocol soon It doesn't sound plausible, it only works without a middlemen.
  - skion 9y ago
    There are probably several angles on this. One is to let our Authentiq ID mobile app support and sign in to SecureLogin sites. Another to let websites that use Authentiq automatically support sign-ins with SecureLogin. These look feasible at first sight. A third, replacing our current auth flow with SecureLogin indeed isn't likely to work for reasons you mention.
Gehinnn 9y ago
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.
florincm 9y ago
I think your idea is brilliant but needs a bit o polishing off. 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. 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. I would personally recommend using Trezor as guidance. This is my demo: https://cl.ly/1P0N0W1t1a3B https://cl.ly/1P0N0W1t1a3B I would be happy to implement it in my systems if it follows the principals above.
- kusmi 9y ago
  Why not just use the fingerprint scanner that's on every mobile phone these days to authenticate.
  - florincm 9y ago
    Bacause you cant use that on your computer, i think the idea here is to be cross-platform.
- homakov 9y ago
  >to just use the public key as the identifier instead of the email. it's exactly how it is now. Email has no "weight", it's just a label. What are your systems? What about 24-word mnemonic as a second option? I personally hate those, and don't want to enforce it.
  - florincm 9y ago
    I understand is a label, but some bad devs might use it as a way of matching the user, and end users might get confused especially when you can write any email as there is no verification for it in place. Let them choose it, or you make the first one to speed up the process and let them edit it if they don't like "Account 1". In terms of master password, what do you think is easier to write down as a backup? This: ?A[ZSOO{PBs&Y]5.6iwm=_t}]t<DOk Or this: remove maple runway unable empty little swing zebra lava interest secret admit To create this you can even use the bitcoin libraries, so you don't have to write your own, and you will only need to work on the clients. If you do it similar to what Trezor did but on a desktop app, you're protocol is built for the web pretty fast. If is good for money is definitely good for Facebook/Twitter/whatever. If you don't have a lot of experience with bitcoin, you can try to use https://copay.io/ https://copay.io/ is cross-platform, open source and very secure. Exactly what you're after from my understanding. You can even change this remove all the bitcoin wallet stuff and make it as an authentication app. It generates the words for you and forces you to back them up to avoid any pain later on. This follows all the principles mentioned. P.S. This version is visually better imo https://github.com/bitpay/copay/releases/tag/v2.7.0 https://github.com/bitpay/copay/releases/tag/v2.7.0
missingencoding 9y ago
Hey homakov, nice work. might want to remember to encodeURIComponent() around the keys as well: SecureLogin = function(scope){ function toQuery(obj){ return Object.keys(obj).reduce(function(a,k){a.push(k+'='+encodeURIComponent(obj[k]));return a},[]).join('&')
- homakov 9y ago
  Thanks! internal toQuery works with predefined a-z keys only so I think it is ok to be this way?
  - missingencoding 9y ago
    better safe than sorry, as I'm sure you know ;)
Vendan 9y ago
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. 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.
- homakov 9y ago
  Thanks for a fresh look. Yes, first encounter can be putting off. Clicking "OK" makes it open local app which you don't have, but it would be silly to have "clear localStorage" button right? 3rd party software is getting better sandboxed every year, hopefully it soon will be in Mac App Store. Counter intuitive parts of enrollment will be fixed.
  - Vendan 9y ago
    Also, do all of the companies linked to on https://sakurity.com/securelogin https://sakurity.com/securelogin actually support this protocol? If not, linking to that page as "Who supports SecureLogin now?" is a bit disingenuous.
JepZ 9y ago
TLDR: One password for all pages without telling any page the actual password.
Osiris 9y ago
> Cryptographic key never leaves your device 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? Also, have you reviewed Web Authentication specification? It sounds very similar.
- Operyl 9y ago
  So, that's kind of a weird half truth. The key is determined from your email + master key, and will always be the same as long as those two details are the same. The downside, and what I'm not a fan of, is neither can be changed without massive work. At least, that's what it seems like based on the README but it might be a little vague ...
  - stephenr 9y ago
    > The downside What about offline generation of thousands/millions of combinations, for later attempts against SeucreLogin enabled sites. The password is something the user has to remember, so it's still not going to be particularly strong for the vast majority of people.
    - homakov 9y ago
      > What about offline generation of thousands/millions of combinations Definitely not millions. It takes 20 seconds on a modern chip, it's memory hard scrypt so yeah, even few thousands are too expensive to crack.
geezk7 9y ago
homakov, a lot of work need to be done: TLDR. Your technical writing is bad and it is putting lots of people off. 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. Examples: "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. "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). 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.
- arekkas 9y ago
  Other blog entries suffer the same thing, for example https://sakurity.com/blog/2017/04/24/owasp.html https://sakurity.com/blog/2017/04/24/owasp.html
  - btasker 9y ago
    Oh god, there are so many things in that post which make me sad. > Unfortunately OWASP is out of touch with reality. First Top10 was released in 2003 and back then the web was a mess. CSRF? Everywhere. XSS? Give me a minute. SQL injection? Just try another parameter. This is idealistic to say the least. Those things are still very much issues, and sadly are likely to continue to be for some time.
- homakov 9y ago
  Regards 1) why do I need statistics for such self-evident things? How on Earth writing down secret codes can be called convenient? No one said yet "wait a second, I actually love all this hassle" > You are underestimating the time complexity of integrating your project with existing apps This is not a relevant blocker for being production-ready: websites _can_ read the docs and use it. The server could go down (valid blocker), but not that.
stephenr 9y ago
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 that part of the problem". Right. So of course, we get the ridiculous statements like: - 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. - 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. - 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 my favourite bits in this thread: - This absolute gem (emphasis mine), from the author who claims it's "production ready for four billion people": > I don't want to have any rights or responsibility, just Do Whatever You Want license. 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. For reference, the "current solution" that I believe still beats this system is: 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. But ultimately all of that is just gravy when you look at the most basic of irony in this whole thing: The author's stated goal 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 entire (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. I'll leave you with one final though: if 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 all SecureLogin-enabled sites that user has an account on. Edit: formatting.
aruggirello 9y ago
About time that this gets addressed where it should - in the browser: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/
- homakov 9y ago
  I've looked closely after standards in auth area and left very disappointed. They are painfully slow. FIDO is founded on 2013, and they never tried to get rid of passwords, but only sell overpriced plastic sticks. I doubt webauthn will be less bureaucratic
JepZ 9y ago
How do I change my master password? I mean I don't want to change it ever month, but maybe every 3-5 years?
- homakov 9y ago
  https://github.com/sakurity/securelogin#7-how-do-i-change-master-password https://github.com/sakurity/securelogin#7-how-do-i-change-ma...
jimktrains2 9y ago
How does revocation work? It sounds like a pain, almost as much as currently. Any credential I can't change is a credential I won't consider.
- homakov 9y ago
  It's not a pain, can be 1 click if you're on the same device (with log of websites you used). https://github.com/sakurity/securelogin#7-how-do-i-change-master-password https://github.com/sakurity/securelogin#7-how-do-i-change-ma... Harder if on a fresh device, but totally doable for anyone
  - jimktrains2 9y ago
    So it needs to be done with each site. That isn't feasible. I either need to do each one individually all at once or risk forgetting the password for lesser used sites.
    - homakov 9y ago
      Let me think of a solution. Usage origins could be tracked and stored server side, trivially, but not sure if worth the hassle.
jtwaleson 9y ago
Cool. I created a similar protocol a couple of years ago but it never got beyond a weekend project, see here for a diagram: https://github.com/jtwaleson/vault https://github.com/jtwaleson/vault 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.

Curious to read more about the planned DoubleSign thing, not sure if it's spelled out anywhere.

homakov 9y ago
So DoubleSign is pretty cool for financial apps because it signs `scope` on two devices. First prototype had that feature. But it was very unclear to the users. So it was removed, but will be added back if this 1.0 version gets used by well... anyone at all :)

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.

level3 9y ago
It seems like your device is completely replaceable in this scheme. The keypair is derived solely from the email address and the master password, so you can just generate the same keypair on a new device.
- homakov 9y ago
  Exactly - everything can be derived from password. It's simplest backup strategy possible.
  - ben0x539 9y ago
    Ah, so it's like sharing one password for everything? Edit: Yeah, with the crucical difference that you don't need to worry about the server's user database getting leaked along with your password.
    - homakov 9y ago
      There are many differences, because your password used just once to create root hash. From root hash private key is generated, and no one is sharing password anymore

tchow 9y ago

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?

rocqua 9y ago
It's essentially the offline password manager idea with some kinks worked out. The offline password doesn't use an encrypted database, but instead used a key-derivation function based on a master password and e.g. the service name to get deterministic passwords. In the case of a password manager, there are issues with password requirements and service name reuse. Here, by switching to a signing protocol, those issues are mitigated. At the same time, because this isn't the password protocol, it forces users to use this app. Meanwhile, you can't force users to use a password manager, leading to horrible password reuse. The big downside I see is the immediate compromise upon revealing your master password. In the case of a PW manager, your opponent needs to get to your database first. This might give you time to roll-over your passwords. Another thing I don't see is key-revocation. What to do when you fear your master password is compromised? That might just be done by essentially the same as a password change though.
- level3 9y ago
  If this protocol got implemented widely, I think there would be some value in creating an alternative app that essentially combines this with a local password database. The app could automatically generate site-specific keypairs, and you would still only need to memorize your master password. This combination would solve the problem of your master password being disclosed (your opponent still needs to get your database), while retaining the benefit of giving sites only your public key instead of a usable password.
  - smichel17 9y ago
    The biggest problem here is multi-device support. Right now you can enter the same email + mpw on a different device and it just works. Adding a local secret means you must manually transfer that to any new device. Seems like a good feature for people with stronger security requirements (eg, journalists), but not the average user.

TrickyRick 9y ago

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: https://www.bankid.com/en/ https://www.bankid.com/en/ It's a great concept but currently somewhat limited to government and financial services, I would love to see something similar get good traction!

arnarbi 9y ago
BankId is not even close to this. It's a centrally managed PKI, which exists in many countries. This is another password=kdf(site data, master pwd) protocol.
- homakov 9y ago
  Not another... It's more flexible kdf(site data, consumer, scope, expiration, master pwd) protocol, allows to prevent many other attacks and replace OAuth all in one.
  - arnarbi 9y ago
    Why replace OAuth? That's an authorization protocol. Do you mean OpenId Connect? In any case, I strongly believe these things should be managed by user agents: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/ While I understand the single master key way makes it trivial to manage multiple clients, it is a non-starter as far as I'm concerned since you cannot rotate it once you've used it as a credential on multiple services. And what about revocation? If you support neither rotation nor revocation, each credential must be independent or you are painting yourself into a corner.
    - homakov 9y ago
      Check "change password" section for rotation of one profile to another. It's quite simple Why replace OAuth? because it sucks. It's stateful on the server, and it's security surface is bad. With SL you could sign a token for client=me provider=facebook scope=profile,photos,friends expire=3months. and all that would be stateless w/o any extra code on the server of identity provider. It is a huge step over OAuth code which is often full of holes (see Doorkeeper in Rails)

kennydude 9y ago

This, to me, sounds like Mozilla Persona

homakov 9y ago
The goal is similar, but not execution. I don't know all specs of Persona - learnt about it when it was being deprecated - but the key difference SecureLogin cannot be deprecated. "All user data stored on the persona.org services will be destroyed, including registered email addresses and password hashes" And hey, there's nothing on SL servers.
floatboth 9y ago
More like SQRL, but without the ability to authenticate from a different device (smartphone)
- homakov 9y ago
  Yes, you can only auth from current app installed on current device. No QR codes involved :)

tptacek 9y ago

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. There are lots and lots of serverless password managers, and their uptake is even lower than that of real password managers. 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?

homakov 9y ago
Thomas, many times I made a point that if auth solution is not enforceable it's not going to be popular. You like 1Password and it has reasons to be loved. But let's take it real and look at password reuse problem. Can you admit that password managers and/or 2fa are not what we need and where we should stop for securing users? We always needed an __enforceable__ protocol that has clear flow for the user. Button. Download, Generate profile, use to login anywhere. I thought it was made clear that it has nothing to do with password managers. It's an authentication protocol that's 1) decentralized 2) extremely usable 3) scalable. That's all it is.
- tptacek 9y ago
  I'm not saying people should use 1Password instead of this. I'm actually not recommending anything, just trying to get my head around the concept. Reading the Github page, the impression I was left with was that this was essentially the same thing as an auto-installed site-specific serverless password manager. Is that incorrect?
  - homakov 9y ago
    It's mostly correct, but it really is not a password manager. Manager is a helper for some people, protocol is a requirement for all. So I want to draw a line between protocol and a manager. It's like https://getclef.com/ https://getclef.com/ or SQRL or Mozilla Persona, but not exactly a manager. By being a protocol it can be _legitimately_ deterministic (you know why deterministic managers aren't great, Tony Arcieri wrote a good post) By being deterministic it can be absolutely free and scalable By being scalable and free I hope it has a chance for being popular (no vendor lock-in). No real innovation, definitely, but in little details it's a good balance of existing things.

therealmarv 9y ago

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

homakov 9y ago
Authy service (one where they send you SMS) is centralized. It's not that it's safe or unsafe, but generally decentralized is better option.
- zwily 9y ago
  Authy also can backup your TOTP tokens (encrypted with passphrase on device). This is super handy when switching devices, but weaker than Google Auth where the TOTP private bits never go back to Google in any form.
  - homakov 9y ago
    Yes, sorry, that TOTP backup thing is great. Always hated that GAuth cannot back up. But what was meant is the SMS service they make money on.
- rocqua 9y ago
  There have been quite a few cases where SMS authentication proved unsafe. It's gone so far as NIST recommending against SMS as a 2nd factor. In short, providers are rather too willing to transfer a mobile phone number.
avenoir 9y ago
Just a few days ago I received an email from Coinbase asking to switch from Authy to Google Authenticator. The reasoning was: > Authy and SMS are vulnerable to phone porting attacks. Device based Authenticator apps like Google Authenticator mitigate this by being linked to your device, not your phone number.

zwily 9y ago

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. 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 9y ago
It's more about password hygiene. Do you have any advice how to prevent disclosing not making UX harder? I would happily implement it.
- zwily 9y ago
  Agreed on the hygiene... However, we're humans, and even the best of us will make a mistake at some point. The impact of that mistake in that scheme seems potentially catastrophic in a way that's different from traditional password managers. I don't see an easy way to fix it given your design goals (which I really like!)
  - homakov 9y ago
    I never really tried to type my password and hit Send, so I never worried about this case. Hygiene has to be reshaped to understand how important master pw is compared to all pw we used to type, like 123456.
    - zwily 9y ago
      The times I've seen people type passwords into Slack has usually been because they had the wrong field focused, and autopilot typed the password and hit Enter. (To be clear, this complaint applies to all schemes that rely on passwords derived from a master password.)
      - GordonS 9y ago

purvis 9y ago

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? # user is given 20 seconds to approve the request 20.times{ sleep 1 sltoken = REDIS.get("sl:#{state}") break if sltoken } https://github.com/homakov/cobased/blob/master/app/controllers/application_controller.rb#L18 https://github.com/homakov/cobased/blob/master/app/controlle...

homakov 9y ago
It's not common, but the quickest way I could find to reduce # of roundtrip requests. Happy to hear why unacceptable.
- purvis 9y ago
  My initial concern was an aggressive server timeout on nginx/haproxy. I think the defaults should be long enough, but it's entirely possible to have something lower than 20 seconds. (and the app developer might not even be aware of this) I have no reason to think it's unacceptable, was just curious. Interesting project!
- zwily 9y ago
  It just means you're tying up a thread (or whole process, if your rails app isn't running with threads) waiting for the response.
  - homakov 9y ago
    It's not a requirement though: one may ping from the client side with setInterval.

leni536 9y ago

What about making client side public key auth not a UX disaster in all major browsers?

homakov 9y ago
In my opinion SL does exactly that: another take on client side public key auth. It's not built in the browser on purpose for flexibility.

buro9 9y ago

I run a fair number of sites, and I don't want to hold people's passwords. 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 https://www.lfgss.com/ https://www.lfgss.com/ I would consider another solution, but I'm not sure that this is it. The information is sparse, as a site-owner it hasn't really sold me on: 1. how this works 2. that the first login friction for the user is low/effortless As I understand it, this is not a "password manager", but more along the idea of a "login manager" that you install locally. 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. 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". 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. 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.

homakov 9y ago
>1. how this works So if you are a developer, your best bet is "How it works?" here: https://github.com/sakurity/securelogin https://github.com/sakurity/securelogin If you don't speak Ruby, hit me up I will dedicate all my time to help you.. and even get free audit as early adopter. FYI we conducted security audit for Auth0 (https://sakurity.com/ https://sakurity.com/) Actually by using auth0 you rely not on one central authority, but on two: auth0 and google/microsoft oauth. If _either_ of them is compromised, your users accounts are too. If that worries you, try SL: With SecureLogin you only rely on the local app user installs. First login friction? Not great, but is getting better, I'm giving it daily to normal users and it improves. > If this is just a communication of risks, then those are not being communicated Correct, that message is not very informative. I think it will be removed.

deleted 9y ago

[deleted]

bogomipz 9y ago

I had a question about the following passage: >"Currently the only way to have safe authentication is to either enable TOTP (like Google Authenticator) or using a USB stick like U2F. 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." 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. Also Github, DropBox, Fastmail, Gmail, Wordpress, Chrome, GitLab and BitBucket all have support for U2F: http://www.dongleauth.info/ http://www.dongleauth.info/

homakov 9y ago
Supporting != users are using it. Especially outside of tech bubble. I myself always cringe when forced to setup TOTP. Yes, I seriously would rather take the risk of my gmail reset compromise than dealing with TOTP again.
- bogomipz 9y ago
  They were two different sentiments: 1) "practically nobody is doing that" - TOTP. The "tech bubble" is not an insignificant number of people. 2) "barely supported by anyone" - U2F. If you look at the link I posted there are a number of services with extremely large user bases that are supporting it.
  - homakov 9y ago
    >The "tech bubble" is not an insignificant number of people. Count # downloads of G Authenticator on Play Store - ~10M. To 4B of internet users. By anyone I meant platform support. U2F on iOS? U2F outside Chrome? etc.
    - bogomipz 9y ago
      The count of Google Authenticator in the Play store is between 10,000,000 - 50,000,000 [1] The MS authenticator has between 1,000,000 and 5,000,000 [2] These stats are just for Android devices not iOS. 10's of millions of users is not insignificant. Why does the global number of internet users matter here? [1] https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en https://play.google.com/store/apps/details?id=com.google.and... [2] https://play.google.com/store/apps/details?id=com.azure.authenticator&hl=en https://play.google.com/store/apps/details?id=com.azure.auth...

danjoc 9y ago

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. "Classic passwords/2FA are poorly designed, hard to backup and inconvenient to use." 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. "SecureLogin's #1 goal is to fix password reuse" That by itself is easy to solve. Generate the password for the user. "Usability: existing onboarding process is a disaster for conversion" Requiring a native app is a disaster. "Central authority" You're confusing out of band authentication with centralization. "no iOS support" SecureLogin can't guarantee their native app won't be pulled from Apple's app store. "open source" LICENSE.txt not found.

derefr 9y ago
> Requiring a native app is a disaster. Not if this is a reference implementation of a protocol that ends up built into operating systems. If the point is to be a reference implementation, though, I'd rather it was a reference implementation of, say, better OS/browser handling, syncing, and UI for TLS client certificates.
- zyx321 9y ago
  It baffles me that no one else mentioned client certificates. That's like Crypto 101, but the author of this software seems unaware it even exists (it's not mentioned in the comparison on the GitHub page)
  - homakov 9y ago
    I'm aware. It's the thing nobody uses. There's no need to compare with it. I'd rather add https://www.youtube.com/watch?v=VgC4b9K-gYU https://www.youtube.com/watch?v=VgC4b9K-gYU
    - 9y ago

borplk 9y ago

How does this compare with SQRL?

homakov 9y ago
I couldn't find any working clients of SQRL/demo? Will happily add it to comparison table.
- botto 9y ago
  I use the android SQRL client https://play.google.com/store/apps/details?id=net.vrallev.android.sqrl https://play.google.com/store/apps/details?id=net.vrallev.an... Then you can see the headers that are exchanged. https://www.grc.com/sqrl/diag.htm https://www.grc.com/sqrl/diag.htm

mtarnovan 9y ago

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

voltagex_ 9y ago
I'm guessing that's only supported with Google services though.
- mtarnovan 9y ago
  Indeed, at least for now.

joshka 9y ago

My email address is not my identity. https://github.com/sakurity/securelogin/issues/3 https://github.com/sakurity/securelogin/issues/3

iafan 9y ago

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. While I see the potential, I understand that this is an initial implementation, so it has UX issues: 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. 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. 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 https://securelogin.pw/ https://securelogin.pw/ 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. 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). --- 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.

lobster_johnson 9y ago
The enterprise version of Duo apparently works by having the mobile app wake up to ask you for confirmation for the login -- similar to how Apple's Touch ID automatically opens to confirm things like Apple Pay if you initiate from the desktop -- rather than making the user open the app, select the account and generating a number. I don't know what protocol is used, and I've never tried it, because it's not part of the single-user Duo Mobile app. But this always struck me as a much more user-friendly way of doing 2FA than the Google Authenticator style that generates numbers that you then have to manually enter.

skion 9y ago

Yes! As a site admin in today's world, you should indeed not want to store passwords. Or even personal data for that matter. 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). 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. 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: https://www.authentiq.com/ https://www.authentiq.com/

homakov 9y ago
> I'm very keen to see if we can add support for the OP's authentication protocol soon It doesn't sound plausible, it only works without a middlemen.
- skion 9y ago
  There are probably several angles on this. One is to let our Authentiq ID mobile app support and sign in to SecureLogin sites. Another to let websites that use Authentiq automatically support sign-ins with SecureLogin. These look feasible at first sight. A third, replacing our current auth flow with SecureLogin indeed isn't likely to work for reasons you mention.

Gehinnn 9y ago

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.

florincm 9y ago

I think your idea is brilliant but needs a bit o polishing off. 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. 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. I would personally recommend using Trezor as guidance. This is my demo: https://cl.ly/1P0N0W1t1a3B https://cl.ly/1P0N0W1t1a3B I would be happy to implement it in my systems if it follows the principals above.

kusmi 9y ago
Why not just use the fingerprint scanner that's on every mobile phone these days to authenticate.
- florincm 9y ago
  Bacause you cant use that on your computer, i think the idea here is to be cross-platform.
homakov 9y ago
>to just use the public key as the identifier instead of the email. it's exactly how it is now. Email has no "weight", it's just a label. What are your systems? What about 24-word mnemonic as a second option? I personally hate those, and don't want to enforce it.
- florincm 9y ago
  I understand is a label, but some bad devs might use it as a way of matching the user, and end users might get confused especially when you can write any email as there is no verification for it in place. Let them choose it, or you make the first one to speed up the process and let them edit it if they don't like "Account 1". In terms of master password, what do you think is easier to write down as a backup? This: ?A[ZSOO{PBs&Y]5.6iwm=_t}]t<DOk Or this: remove maple runway unable empty little swing zebra lava interest secret admit To create this you can even use the bitcoin libraries, so you don't have to write your own, and you will only need to work on the clients. If you do it similar to what Trezor did but on a desktop app, you're protocol is built for the web pretty fast. If is good for money is definitely good for Facebook/Twitter/whatever. If you don't have a lot of experience with bitcoin, you can try to use https://copay.io/ https://copay.io/ is cross-platform, open source and very secure. Exactly what you're after from my understanding. You can even change this remove all the bitcoin wallet stuff and make it as an authentication app. It generates the words for you and forces you to back them up to avoid any pain later on. This follows all the principles mentioned. P.S. This version is visually better imo https://github.com/bitpay/copay/releases/tag/v2.7.0 https://github.com/bitpay/copay/releases/tag/v2.7.0

missingencoding 9y ago

Hey homakov, nice work. might want to remember to encodeURIComponent() around the keys as well: SecureLogin = function(scope){ function toQuery(obj){ return Object.keys(obj).reduce(function(a,k){a.push(k+'='+encodeURIComponent(obj[k]));return a},[]).join('&')

homakov 9y ago
Thanks! internal toQuery works with predefined a-z keys only so I think it is ok to be this way?
- missingencoding 9y ago
  better safe than sorry, as I'm sure you know ;)

Vendan 9y ago

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

homakov 9y ago
Thanks for a fresh look. Yes, first encounter can be putting off. Clicking "OK" makes it open local app which you don't have, but it would be silly to have "clear localStorage" button right? 3rd party software is getting better sandboxed every year, hopefully it soon will be in Mac App Store. Counter intuitive parts of enrollment will be fixed.
- Vendan 9y ago
  Also, do all of the companies linked to on https://sakurity.com/securelogin https://sakurity.com/securelogin actually support this protocol? If not, linking to that page as "Who supports SecureLogin now?" is a bit disingenuous.

JepZ 9y ago

TLDR: One password for all pages without telling any page the actual password.

Osiris 9y ago

> Cryptographic key never leaves your device 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? Also, have you reviewed Web Authentication specification? It sounds very similar.

Operyl 9y ago
So, that's kind of a weird half truth. The key is determined from your email + master key, and will always be the same as long as those two details are the same. The downside, and what I'm not a fan of, is neither can be changed without massive work. At least, that's what it seems like based on the README but it might be a little vague ...
- stephenr 9y ago
  > The downside What about offline generation of thousands/millions of combinations, for later attempts against SeucreLogin enabled sites. The password is something the user has to remember, so it's still not going to be particularly strong for the vast majority of people.
  - homakov 9y ago
    > What about offline generation of thousands/millions of combinations Definitely not millions. It takes 20 seconds on a modern chip, it's memory hard scrypt so yeah, even few thousands are too expensive to crack.

geezk7 9y ago

homakov, a lot of work need to be done: TLDR. Your technical writing is bad and it is putting lots of people off. 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. Examples: "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. "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). 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.

arekkas 9y ago
Other blog entries suffer the same thing, for example https://sakurity.com/blog/2017/04/24/owasp.html https://sakurity.com/blog/2017/04/24/owasp.html
- btasker 9y ago
  Oh god, there are so many things in that post which make me sad. > Unfortunately OWASP is out of touch with reality. First Top10 was released in 2003 and back then the web was a mess. CSRF? Everywhere. XSS? Give me a minute. SQL injection? Just try another parameter. This is idealistic to say the least. Those things are still very much issues, and sadly are likely to continue to be for some time.
homakov 9y ago
Regards 1) why do I need statistics for such self-evident things? How on Earth writing down secret codes can be called convenient? No one said yet "wait a second, I actually love all this hassle" > You are underestimating the time complexity of integrating your project with existing apps This is not a relevant blocker for being production-ready: websites _can_ read the docs and use it. The server could go down (valid blocker), but not that.

stephenr 9y ago

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 that part of the problem". Right. So of course, we get the ridiculous statements like: - 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. - 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. - 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 my favourite bits in this thread: - This absolute gem (emphasis mine), from the author who claims it's "production ready for four billion people": > I don't want to have any rights or responsibility, just Do Whatever You Want license. 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. For reference, the "current solution" that I believe still beats this system is: 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. But ultimately all of that is just gravy when you look at the most basic of irony in this whole thing: The author's stated goal 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 entire (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. I'll leave you with one final though: if 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 all SecureLogin-enabled sites that user has an account on. Edit: formatting.

aruggirello 9y ago

About time that this gets addressed where it should - in the browser: https://www.w3.org/TR/webauthn/ https://www.w3.org/TR/webauthn/

homakov 9y ago
I've looked closely after standards in auth area and left very disappointed. They are painfully slow. FIDO is founded on 2013, and they never tried to get rid of passwords, but only sell overpriced plastic sticks. I doubt webauthn will be less bureaucratic

JepZ 9y ago

How do I change my master password? I mean I don't want to change it ever month, but maybe every 3-5 years?

homakov 9y ago
https://github.com/sakurity/securelogin#7-how-do-i-change-master-password https://github.com/sakurity/securelogin#7-how-do-i-change-ma...

jimktrains2 9y ago

How does revocation work? It sounds like a pain, almost as much as currently. Any credential I can't change is a credential I won't consider.

homakov 9y ago
It's not a pain, can be 1 click if you're on the same device (with log of websites you used). https://github.com/sakurity/securelogin#7-how-do-i-change-master-password https://github.com/sakurity/securelogin#7-how-do-i-change-ma... Harder if on a fresh device, but totally doable for anyone
- jimktrains2 9y ago
  So it needs to be done with each site. That isn't feasible. I either need to do each one individually all at once or risk forgetting the password for lesser used sites.
  - homakov 9y ago
    Let me think of a solution. Usage origins could be tracked and stored server side, trivially, but not sure if worth the hassle.

jtwaleson 9y ago

Cool. I created a similar protocol a couple of years ago but it never got beyond a weekend project, see here for a diagram: https://github.com/jtwaleson/vault https://github.com/jtwaleson/vault 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.