[HN Gopher] Why Login Security Sucks
       ___________________________________________________________________
        
       Why Login Security Sucks
        
       Author : todsacerdoti
       Score  : 25 points
       Date   : 2024-09-06 18:16 UTC (4 hours ago)
        
 (HTM) web link (matduggan.com)
 (TXT) w3m dump (matduggan.com)
        
       | janalsncm wrote:
       | A website that allows login via forgot password -> send email ->
       | reset password should skip passwords entirely and use magic links
       | instead.
       | 
       | Also, at this point there's a huge number of previously leaked
       | passwords. So websites should simply not allow passwords that
       | have appeared in those leaks.
        
         | graemep wrote:
         | Magic links are annoying for users.
        
           | ibll wrote:
           | I always forget how stinking nice password manager autofill
           | is until I have to fight with magic links because some
           | service hates me. And most implementations I've seen only log
           | you in from the new link the email sent, not the original
           | page. So if you are trying to log in on a device your email
           | isn't signed in on, you get to type the entire thing in on
           | your second device.
        
             | 0cf8612b2e1e wrote:
             | More times than I would like, I have had to manually type
             | out some ludicrously long secret key/token/url. Could we
             | please standardize on only using long strings that do not
             | require il1o0 in them? I suppose it is a failure of Latin
             | or the default fonts with which I am frequently stuck, but
             | it would save me a minor bit of life aggravation.
        
             | weikju wrote:
             | > And most implementations I've seen only log you in from
             | the new link the email sent, not the original page.
             | 
             | Probably because:
             | 
             | - Bad actor A attempts to login - User B sees the email and
             | unthinkingly clicks the magic link - Bad Actor A now has
             | access.
             | 
             | There are probably ways around this (browser
             | session/cookies/IP/etc must match?) but that'd be a common
             | enough scenario...
             | 
             | Common enough that e.g. Microsoft Authenticator switched
             | from sending a notification that you can tap to
             | approve/reject (same as scenario above) to needing to enter
             | a 2-digit code that you also see on the webpage (so without
             | seeing Bad Actor A's page you cannot enter the code and
             | approve their login).
        
         | radicality wrote:
         | I absolutely hate the magic links :S A whole bunch of AI
         | companies are going that route where you can't have a password
         | and login via magic links - eg Perplexity
        
       | radicality wrote:
       | I know that crypto/blockchain is not super popular here, but the
       | experience of logging-in to various dapps is pretty nice.
       | 
       | The "login" is the dapp showing the user a message to sign to
       | prove they own the key, then you can sign the message, and that's
       | the whole login.
       | 
       | There's various ways to implement it, but here's a quick tutorial
       | for doing login with MetaMask.
       | https://docs.metamask.io/wallet/how-to/sign-data/siwe/
        
         | tptacek wrote:
         | There is no less attractive use of blockchain tech than login.
         | The biggest problem with login security isn't attesting to an
         | identity, it's account recovery; blockchains make that
         | incredibly difficult.
        
         | martinky24 wrote:
         | Ah, the crypto industry known for being exceptionally secure in
         | their practices, always vetting their security, and never
         | cutting corners. We should do what they do.
         | 
         | (Don't ask about what happened to the Ronin Network, Poly
         | Network, FTX, Coincheck, etc, etc)
        
       | tptacek wrote:
       | This person is wildly overthinking their problems.
       | 
       | Early in the piece, they marvel that it's somehow OK to email
       | magic login links to people, but not to SMS logins. Yes: among
       | other reasons, that's because there's nobody an attacker can
       | realistically call on the phone or bribe at a neighborhood cell
       | phone store to rehome an email account. Nobody wants to do away
       | with SMTP more than I do, but everybody has it, and most people
       | (by an overwhelming majority) host it with their absolute most
       | secure provider.
       | 
       | Get past the SMS/SMTP thing. You're doing a low-sensitivity CMS
       | application. It would be _bizarre_ for you to have a Passkeys
       | implementation. It 's even weird for you to do login-with-Google
       | or SIWA. Just mail magic links! Be done with it!
       | 
       | TOTP is dead tech. Implement the full gamut of OIDC provider
       | logins --- most of which have better TOTP implementations than
       | you'll come up with (but also tend to steer their users away from
       | TOTP) and forget that it exists.
       | 
       | I'd like to have a coda here about how things get much harder if
       | you're a high-sensitivity application. But they don't. Mostly
       | what happens is that OIDC signon gets much more important.
       | 
       |  _The bit about TOTP secrets being worse, harder-to-rotate
       | passwords also misses the point of why passwords are bad and why
       | unmasked TOTP seed storage is not in fact that big of a deal, but
       | who cares? Just don 't do TOTP._
        
       | Dwedit wrote:
       | If I'm going to be forced into two-factor authentication, I would
       | much rather use TOTP than be forced to use a phone number. Phones
       | can break.
        
       ___________________________________________________________________
       (page generated 2024-09-06 23:00 UTC)