5 ms·

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

by 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.
- AbacusAvenger 9y ago
  It bothers me a bit that the project has weak commit messages like this: https://github.com/sakurity/securelogin/commit/975332ae0b0e290d27fdefb66d66f5bc7c784712 https://github.com/sakurity/securelogin/commit/975332ae0b0e2... Literally just "1". Tells me nothing about what's happening in this change, and from the diff, it looks like quite a lot ("118 changed files with 283 additions and 179 deletions").
  - amingilani 9y ago
    From what I can tell, it fixed issue #1 Besides, everyone writes shitty messages every now and then. Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
    - cyphar 9y ago
      Except that the commit history is actually important when auditing a security-sensitive project. After reading the guidelines for the Linux kernel I've always given full and proper commit descriptions for effectively all of my commits (with exceptions for projects which don't matter, and such messages aren't going to be read by anyone -- including me). I really wish more people did this, because it makes bisecting, backporting and otherwise spelunking projects much easier. To put it in your analogy, it wouldn't be fair to judge a programmer by their handwriting. But it might be fair to judge a secretary by their handwriting (you'd be annoyed if your secretary didn't write down important details, or wrote them in a way that nobody could read them).
      - sillysaurus3 9y ago
        It's not really true to say that the commit history of a project is an important aspect in regards to security. Whether it's security-sensitive or not, a project has either been audited or it hasn't. And an audit doesn't rely on commit messages.
        9y ago
bmh_ca 9y ago
> Today I use auth0 configured as a passwordless solution, i.e. email code + login, or use Google OAuth, etc. This. Not necessarily auth0, but passwordless auth. Humans forget passwords routinely. It's at odds with realistic expectations of the human brain. If email is compromised, so is the password reset mechanism. Tacking on FIDO U2F and one can have reasonable expectations of identity. No password DB exposure, no password guessing exposure, no remembering passwords so better experience and less support costs.
- homakov 9y ago
  If not this protocol, I would be happy if any passwordless auth wins. Really about time to make a switch!
- dingaling 9y ago
  > If email is compromised, so is the password reset mechanism. If we didn't have online password resets then we wouldn't have to worry about the e-mail account being the weak-point. I would argue that no service that offers an online password reset mechanism deserves it. If I mess-up my bank login, I have to go to a branch to initiate the re-authentication process. Password in the post in secure-mail envelopes, things like that. If I screw-up my Amazon login - well, that should really be too bad, end of story. Just create a new account. There's too much risk in having an online reset mechanism that could enable someone else to use my cards for purchases.

by buro9 9y ago

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.

AbacusAvenger 9y ago
It bothers me a bit that the project has weak commit messages like this: https://github.com/sakurity/securelogin/commit/975332ae0b0e290d27fdefb66d66f5bc7c784712 https://github.com/sakurity/securelogin/commit/975332ae0b0e2... Literally just "1". Tells me nothing about what's happening in this change, and from the diff, it looks like quite a lot ("118 changed files with 283 additions and 179 deletions").
- amingilani 9y ago
  From what I can tell, it fixed issue #1 Besides, everyone writes shitty messages every now and then. Don't judge their code by their use of a VCS. It's like judging a person's articles by their notes. I've got terrible handwriting.
  - cyphar 9y ago
    Except that the commit history is actually important when auditing a security-sensitive project. After reading the guidelines for the Linux kernel I've always given full and proper commit descriptions for effectively all of my commits (with exceptions for projects which don't matter, and such messages aren't going to be read by anyone -- including me). I really wish more people did this, because it makes bisecting, backporting and otherwise spelunking projects much easier. To put it in your analogy, it wouldn't be fair to judge a programmer by their handwriting. But it might be fair to judge a secretary by their handwriting (you'd be annoyed if your secretary didn't write down important details, or wrote them in a way that nobody could read them).
    - sillysaurus3 9y ago
      It's not really true to say that the commit history of a project is an important aspect in regards to security. Whether it's security-sensitive or not, a project has either been audited or it hasn't. And an audit doesn't rely on commit messages.
      - 9y ago

bmh_ca 9y ago

> Today I use auth0 configured as a passwordless solution, i.e. email code + login, or use Google OAuth, etc. This. Not necessarily auth0, but passwordless auth. Humans forget passwords routinely. It's at odds with realistic expectations of the human brain. If email is compromised, so is the password reset mechanism. Tacking on FIDO U2F and one can have reasonable expectations of identity. No password DB exposure, no password guessing exposure, no remembering passwords so better experience and less support costs.

homakov 9y ago
If not this protocol, I would be happy if any passwordless auth wins. Really about time to make a switch!
dingaling 9y ago
> If email is compromised, so is the password reset mechanism. If we didn't have online password resets then we wouldn't have to worry about the e-mail account being the weak-point. I would argue that no service that offers an online password reset mechanism deserves it. If I mess-up my bank login, I have to go to a branch to initiate the re-authentication process. Password in the post in secure-mail envelopes, things like that. If I screw-up my Amazon login - well, that should really be too bad, end of story. Just create a new account. There's too much risk in having an online reset mechanism that could enable someone else to use my cards for purchases.