5 ms·

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 ment

by 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
    - derefr 9y ago
      That's rather the point. If everyone is already using something, then the existing implementations are probably already near-optimal, so it's hard to do better and easy to do worse. You can expend a great deal of effort in such a space and—almost all of the time—all that effort will be for naught, because your solution will end up different but not necessarily strictly better for any particular use-case. On the other hand, if everyone agrees that a design is great in theory—but nobody is using it—then that suggests that all current implementations are crap—and so that's a great niche to innovate in. It's hard to do worse, and very easy to do better—and "doing better" is likely to turn "the thing nobody uses" into "the thing at least some people use", with your name stamped on the side in the process.
      - zyx321 9y ago
        >that suggests that all current implementations are crap Except the one time I've seen it in the wild, the implementation/UX was surprisingly good. Turns out Firefox can generate a cert entirely client-side and install it via Javascript. Chrome draws from whatever cert storage the underlying OS offers, so it should be as simple as saving the cert file to disk and opening it. Mobile might pose a problem. Would have to try it out.
      - homakov 9y ago
        > then that suggests that all current implementations Long story short entire concept of client certs is not as usable in terms of backups/enrollment as I want to, no matter how well dialogs are implemented.
        derefr 9y ago
        > not as usable in terms of backups/enrollment as I want That's what I was referring to when I said "all current implementations are crap." A better implementation would change that (by e.g. having client certs sync in browser-sync like cookies do; and sync in the OS between devices like macOS keychains do.)
        9y ago
homakov 9y ago
> Tried demo on chromebook Sorry never tested on that platform. But web app must be working, just press Cancel if app is not installed. Native app is not required but recommended. It's deterministic - enter same password, get same profile. No sync needed. > That's insulting. Stop that Wait, you seriously feel all these "your password must have x, y and z, confirm it, scan QR, enter digits" as convenient? Don't listen to me: watch any password manager promo video. Everyone in the world knows auth is broken. >That by itself is easy to solve. Generate the password for the user. Yes, but there is goal #2 and others. >Requiring a native app is a disaster. Necessary evil? All password managers are native apps too. >You're confusing out of band authentication with centralization. Verification through central authority API or gateway is also out-of-band, i.e. user<->authority<->server. These terms are not mutually exclusive. >"SecureLogin can't guarantee their native app won't be pulled from Apple's app store." There's no reason for this to happen, it's not an uber :) In App Store soon. >LICENSE.txt not found. Will be fixed. Which one is your favorite?
- dismantlethesun 9y ago
  MIT license please.
  - homakov 9y ago
    Yes, it's good one https://github.com/sakurity/securelogin/blob/master/LICENSE.txt https://github.com/sakurity/securelogin/blob/master/LICENSE....
- mankash666 9y ago
  Please use the Apache 2.0 license. It's the most practical, unencumbered one, if you truly want wide adoption
  - homakov 9y ago
    MIT vs Apache 2.0? I don't want to have any rights or responsibility, just Do Whatever You Want license.

by danjoc 9y ago

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
  - derefr 9y ago
    That's rather the point. If everyone is already using something, then the existing implementations are probably already near-optimal, so it's hard to do better and easy to do worse. You can expend a great deal of effort in such a space and—almost all of the time—all that effort will be for naught, because your solution will end up different but not necessarily strictly better for any particular use-case. On the other hand, if everyone agrees that a design is great in theory—but nobody is using it—then that suggests that all current implementations are crap—and so that's a great niche to innovate in. It's hard to do worse, and very easy to do better—and "doing better" is likely to turn "the thing nobody uses" into "the thing at least some people use", with your name stamped on the side in the process.
    - zyx321 9y ago
      >that suggests that all current implementations are crap Except the one time I've seen it in the wild, the implementation/UX was surprisingly good. Turns out Firefox can generate a cert entirely client-side and install it via Javascript. Chrome draws from whatever cert storage the underlying OS offers, so it should be as simple as saving the cert file to disk and opening it. Mobile might pose a problem. Would have to try it out.
    - homakov 9y ago
      > then that suggests that all current implementations Long story short entire concept of client certs is not as usable in terms of backups/enrollment as I want to, no matter how well dialogs are implemented.
      - derefr 9y ago
        > not as usable in terms of backups/enrollment as I want That's what I was referring to when I said "all current implementations are crap." A better implementation would change that (by e.g. having client certs sync in browser-sync like cookies do; and sync in the OS between devices like macOS keychains do.)
        9y ago

homakov 9y ago

> Tried demo on chromebook Sorry never tested on that platform. But web app must be working, just press Cancel if app is not installed. Native app is not required but recommended. It's deterministic - enter same password, get same profile. No sync needed. > That's insulting. Stop that Wait, you seriously feel all these "your password must have x, y and z, confirm it, scan QR, enter digits" as convenient? Don't listen to me: watch any password manager promo video. Everyone in the world knows auth is broken. >That by itself is easy to solve. Generate the password for the user. Yes, but there is goal #2 and others. >Requiring a native app is a disaster. Necessary evil? All password managers are native apps too. >You're confusing out of band authentication with centralization. Verification through central authority API or gateway is also out-of-band, i.e. user<->authority<->server. These terms are not mutually exclusive. >"SecureLogin can't guarantee their native app won't be pulled from Apple's app store." There's no reason for this to happen, it's not an uber :) In App Store soon. >LICENSE.txt not found. Will be fixed. Which one is your favorite?

dismantlethesun 9y ago
MIT license please.
- homakov 9y ago
  Yes, it's good one https://github.com/sakurity/securelogin/blob/master/LICENSE.txt https://github.com/sakurity/securelogin/blob/master/LICENSE....
mankash666 9y ago
Please use the Apache 2.0 license. It's the most practical, unencumbered one, if you truly want wide adoption
- homakov 9y ago
  MIT vs Apache 2.0? I don't want to have any rights or responsibility, just Do Whatever You Want license.