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

[pynixwang]

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

[hsjoberg]

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.

[pynixwang]

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.

[hsjoberg]

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`).

[pynixwang]

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

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

[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.

[fiatjaf]

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.

[hsjoberg]

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.

[hsjoberg]

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.

[pynixwang]

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