Skip to content

How to protect user from fake site login with lnurl-auth #257

Description

@pynixwang

if user does not pay attention to login url show in login page and click login, fake site can get user credentials.

Activity

  1. hsjoberg commented on Apr 17, 2024

    @hsjoberg
    Collaborator

    The LNURL-auth specification has protection against this. A unique key is derived for each domain you authenticate with. So the key is not shared between domains, therefore phishing is not really possible.

  2. pynixwang commented on Apr 18, 2024

    @pynixwang
    Author

    1,fake site get k1 and lnurl from site on server and show lnurl to user.
    2,user login with lnurl.
    3,fake site refresh on server and get user credentials

    fake site domain is very similar to site.

  3. hsjoberg commented on Apr 23, 2024

    @hsjoberg
    Collaborator

    That would just authenticate with the fake website, not the real one. A unique key being used for authentication is derived from the domain you're talking with.

    See here:

    luds/05.md

    Lines 8 to 11 in 0318227

    ### `linkingKey` derivation for BIP-32 based wallets:
    1. There exists a private `hashingKey` which is derived by user `LN WALLET` using `m/138'/0` path.
    2. `LN SERVICE` full domain name is extracted from login `LNURL` and then hashed using `hmacSha256(hashingKey, full service domain name)`. Full domain name here means FQDN with last full-stop (aka "point") omitted (Example: for `https://x.y.z.com/...` it would be `x.y.z.com`).

  4. pynixwang commented on Apr 24, 2024

    @pynixwang
    Author

    no,
    my site is example.com, I can login with api.example.com.

    fake site also can login with api.example.com.

  5. BitcoinErrorLog commented on Apr 24, 2024

    @BitcoinErrorLog

    @hsjoberg I think @pynixwang is saying that the middleman would retrieve the challenge from the real site and provide that to the user out of band, and then receive the auth response from the user, allowing the middleman to apply it themselves to open a session with the real site.

  6. fiatjaf commented on Apr 24, 2024

    @fiatjaf
    Collaborator

    The wallet will generate a different keypair for each domain it connects to. The protection is not at the k1 level, it is at the domain name level.

    The attacker can only do two things:

    • Display a QR code containing the attacker domain: in this case the wallet will generate a special key for the attacker domain and that will not allow the attacker to log in at the original domain.
    • Display a QR code containing the original domain: in this case the wallet will send the signature to the original domain and the attacker will not receive anything.
  7. hsjoberg commented on Apr 24, 2024

    @hsjoberg
    Collaborator

    the middleman would retrieve the challenge from the real site and provide that to the user out of band, and then receive the auth response from the user, allowing the middleman to apply it themselves to open a session with the real site.

    @BitcoinErrorLog What do you mean by out-of-band specifically? If it's a fake website then the user would authenticate using a unique key for that domain and not the same key as they would use for the real website.
    The authentication is over URL after all, and so the domain will always matter.

    I suppose the man-in-the-middle attack does work if the user has only ever interacted with the fake website. But it would never work if the user already has an account on the real one.

  8. hsjoberg commented on Apr 24, 2024

    @hsjoberg
    Collaborator

    no,
    my site is example.com, I can login with api.example.com.

    fake site also can login with api.example.com.

    @pynixwang Yes the fake site can login to api.example.com, but it would not be the same key being used thus not the same account on the site.

  9. pynixwang commented on Jul 12, 2024

    @pynixwang
    Author

    @hsjoberg but key is generated for api.example.com, not fake site

  10. added
    help-wantedAccessible for new contributors
    specSpec clarification, wording fix, or normative correction
    on May 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    help-wantedAccessible for new contributorsspecSpec clarification, wording fix, or normative correction

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions