4 ms·

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

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.
  - md_ 9y ago
    I like the little details. And unlike Steve Gibson's SQRL--which I was trashing recently for being overhyped--you don't come off as a dick. ;) Some questions/comments: 1. The github would be clearer (to me, anyway) if the protocol were written out in prose rather than in code. That may account for the following question: 2. It's not clear to me how the origin of the auth request is validated on the auth GET. I.e. how does the "relying party" (so to speak) validate that the SecureLogin client is following an auth link that wasn't MITM'ed by a phishing page? 3. I actually think the URI-scheme/browser-integration is a clever idea, and the UX flow seems fairly nice to me. 4. I think you're sort of kidding yourself if you say that lost-password recovery is not a big deal for big providers like Google and Facebook. For smaller providers, falling back to email verification is fine--or maybe doing nothing. Big providers offer all kinds of verification--email, SMS, domain-ownership, credit card--and a human customer support path. That doesn't change with TOTP or U2F, and wouldn't change here. Not a dealbreaker, really, but it's worth noting this weakness (lost-auth recovery) is probably here for the foreseeable future. 5. Having to enter your master password sometimes is a UX feature, not a bug--it teaches users to remember the master password. Just something to keep in mind on the client apps.
    - homakov 9y ago
      1. Will try. it would take 2x much text. 2. I'm not sure if that's what you meant but I just realized pretty bad bug in current callback=ping flow. When malicions page opens my.app for me and second later opens securelogin://#state=THEIRSTATE... so my sltoken will be matched with their state and they will log into my account. That requires good timing so not super severe but definitely will be fixed: if someone opens the app twice in a raw it will notify the user. Thanks 3. There's pretty much no alternatives working cross platform. 4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".
      - IanCal 9y ago
        > 4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here". Checking now, I cannot setup a gmail account without a phone number or backup email. I can also reset my password as long as I have access to my phone which is currently logged in. > In the end of any authentication scheme there will be a password that you just cannot forget. In SecureLogin we removed unnecessary levels of "backups" and "recovery codes", our scheme boils down to one master password, not to master password and backup file/paper/SIM card/email account etc. I don't think a backup is "unnecessary". It lowers the chance of being completely locked out. What happens if I forget my master password? Does it mean I can never log into the sights using the same account ever again?
        homakov 9y ago
        Backup with 3rd party == giving up access to 3rd party. #1 principle of this protocol is not giving up access, at least by default. You are free to email your password to yourself, write it on a note, but it will never offer to send your password on your phone number. We live in a hostile world. > Does it mean I can never log into the sights using the same account ever again? It's up to the websites, they could use your email for reset + lots of personal info you have about account activity.

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.
- md_ 9y ago
  I like the little details. And unlike Steve Gibson's SQRL--which I was trashing recently for being overhyped--you don't come off as a dick. ;) Some questions/comments: 1. The github would be clearer (to me, anyway) if the protocol were written out in prose rather than in code. That may account for the following question: 2. It's not clear to me how the origin of the auth request is validated on the auth GET. I.e. how does the "relying party" (so to speak) validate that the SecureLogin client is following an auth link that wasn't MITM'ed by a phishing page? 3. I actually think the URI-scheme/browser-integration is a clever idea, and the UX flow seems fairly nice to me. 4. I think you're sort of kidding yourself if you say that lost-password recovery is not a big deal for big providers like Google and Facebook. For smaller providers, falling back to email verification is fine--or maybe doing nothing. Big providers offer all kinds of verification--email, SMS, domain-ownership, credit card--and a human customer support path. That doesn't change with TOTP or U2F, and wouldn't change here. Not a dealbreaker, really, but it's worth noting this weakness (lost-auth recovery) is probably here for the foreseeable future. 5. Having to enter your master password sometimes is a UX feature, not a bug--it teaches users to remember the master password. Just something to keep in mind on the client apps.
  - homakov 9y ago
    1. Will try. it would take 2x much text. 2. I'm not sure if that's what you meant but I just realized pretty bad bug in current callback=ping flow. When malicions page opens my.app for me and second later opens securelogin://#state=THEIRSTATE... so my sltoken will be matched with their state and they will log into my account. That requires good timing so not super severe but definitely will be fixed: if someone opens the app twice in a raw it will notify the user. Thanks 3. There's pretty much no alternatives working cross platform. 4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here".
    - IanCal 9y ago
      > 4. Which paragraph are you refering too? When I try to reset my Gmail password it boils down to: "dude you forgot your password, no backup email... we cant help here". Checking now, I cannot setup a gmail account without a phone number or backup email. I can also reset my password as long as I have access to my phone which is currently logged in. > In the end of any authentication scheme there will be a password that you just cannot forget. In SecureLogin we removed unnecessary levels of "backups" and "recovery codes", our scheme boils down to one master password, not to master password and backup file/paper/SIM card/email account etc. I don't think a backup is "unnecessary". It lowers the chance of being completely locked out. What happens if I forget my master password? Does it mean I can never log into the sights using the same account ever again?
      - homakov 9y ago
        Backup with 3rd party == giving up access to 3rd party. #1 principle of this protocol is not giving up access, at least by default. You are free to email your password to yourself, write it on a note, but it will never offer to send your password on your phone number. We live in a hostile world. > Does it mean I can never log into the sights using the same account ever again? It's up to the websites, they could use your email for reset + lots of personal info you have about account activity.