[HN Gopher] Thinking about Passwords
       ___________________________________________________________________
        
       Thinking about Passwords
        
       Author : HermanMartinus
       Score  : 30 points
       Date   : 2022-02-13 10:13 UTC (2 days ago)
        
 (HTM) web link (herman.bearblog.dev)
 (TXT) w3m dump (herman.bearblog.dev)
        
       | _wldu wrote:
       | I'm currently experimenting with Ed25519 signatures in place of
       | passwords for website authentication:
       | 
       | Git repo: https://github.com/62726164/ed25519-login
       | 
       | Test website: https://gen.go350.com/
       | 
       | I plan to write an Android and iOS app (someday) that has the
       | same functionality as ed25519-login. We need to go password less,
       | but the complexity of webauthn is too much IMO.
       | 
       | I'm looking for feedback and appreciate any suggestions.
        
         | Grimburger wrote:
         | TLS already has client side authentication baked in, it's just
         | that no one really uses it or even knows it exists. Most (all?)
         | browsers support it.
         | 
         | https://aboutssl.org/ssl-tls-client-authentication-how-does-...
        
           | _wldu wrote:
           | Yes. Mutual TLS. But that involves certificates, potentially
           | CAs, dealing with certificate expirations and other PKI
           | formalities. Any user can generate an Ed25519 key pair,
           | base64 encode the public part of the key and register that
           | with websites. It's more informal than TLS certificates and
           | totally user controlled.
           | 
           | I do use TLS client certificates (with several APIs) but I
           | don't consider them as password replacements (which is the
           | goal of ed25519-login).
        
       | ricopags wrote:
       | I appreciate the frustration, and share it. I wonder, though: Is
       | this significantly different from how onetimesecret[0] works?
       | 1password also has a secure sharing feature[1].
       | 
       | I used to use onetimesecret but find 1password to be sufficient
       | to my needs.
       | 
       | [0] https://onetimesecret.com/ [1]
       | https://blog.1password.com/psst-item-sharing/
        
       | notfed wrote:
       | > I run into the problem of securely granting access to services
       | to these contractors regularly.
       | 
       | Maybe you could elaborate on the problem statement? Passwords for
       | what? And it seems presumed that these are services can't support
       | token-based authorization; i.e. only support raw passwords?
        
       | davidkuennen wrote:
       | I've come really to appreciate passwordless authentication [1].
       | 
       | [1]:
       | https://auth0.com/docs/authenticate/passwordless/authenticat...
        
       | samwillis wrote:
       | Edit:
       | 
       | Ignore below as I skimmed the article too quickly. Shouldn't try
       | and read something like this with screaming children in the room.
       | 
       | -
       | 
       | I think this proposal is a little more complicated than it needs
       | to be, and it's adding a lot of friction to an already annoying
       | login process. I run a site that has a registration option,
       | people avoid it as much as possible.
       | 
       | Personally I'm a fan of the magic login email link, super simple
       | and reliable. Just fingerprint/cookie the device that initiated
       | the login to ensure that the email has been clicked on the same
       | device.
       | 
       | Most services would be compromised my a users email becoming
       | compromised due to "Forgotten Password" recovery systems. So a
       | magic email login link is no less secure in my eyes.
        
         | jsnell wrote:
         | I think this wasn't about writing a login system for a new
         | service though. It was about sharing the credentials to various
         | third party systems, whose login systems are not controlled by
         | the author.
        
           | samwillis wrote:
           | You are quite right, skimmed it too quickly.
        
         | mimsee wrote:
         | > Just fingerprint/cookie the device that initiated the login
         | to ensure that the email has been clicked on the same device.
         | 
         | I usually open these on my phone since it usually comes as a
         | push notification.
        
       | blakesterz wrote:
       | An interesting idea.
       | 
       | Reminds me of SQRL for some reason:
       | https://www.grc.com/sqrl/sqrl.htm
       | 
       | A somewhat similar solution to the same problems? Or at least
       | follows the same kind of thinking to a different solution
       | perhaps.
        
       | xondono wrote:
       | In terms of user experience IMO, what you'd want is something
       | similar to how Apples "share wifi password" work but with extra
       | features.
       | 
       | You want to log in to x, there's a place to put the owners email
       | or phone number, they get (if you are previously on some "accept
       | list") a notification that let's them grant or deny access. You
       | don't get to see any password, you just get logged in.
       | 
       | Ideally you'd also want them to be time limited and revocable.
        
       ___________________________________________________________________
       (page generated 2022-02-15 23:02 UTC)