Canary Login

[theZerg]

Here's an idea I had which is simple by interesting:

N bitcoins are kept at an address associated with a bitcoin key.

Login is allowed via using a bitcoin public key through 2 mechanisms:
1. a challenge
encrypt this unique 2 part string (domain of login,random bits) and send it back to me.
Sending the domain avoids pass-thru attacks.
Sending random bits avoids replay attacks

2. and a bitcoin balance check at the address represented by that key.


If the key is compromised the hacker will likely take the bitcoins, invalidating any further login using that public key.

 

[dill]

The same concept would work for digital identities. Have bitcoin at the address you use to sign text and having your private key compromised would result in a invalidated identity once the address is empty.

 

[cypherdoc]

in your example, i don't see any relationship of the challenge to the pubkey. how does the domain know it's you?

also, do you expect the domain to remember the balance at the pubkey and how would it do this?

most ppl wouldn't leave a significant amount of coin at this pubkey. thus, if the domain is a bank, it may be more profitable for the stealer of the pubkey to forgo the coin versus attack your bank acct.

 

[Georg Engelmann]

If I move those coins to another address can I restore the login by adding coins?

Do I need to have the exact same balance or can I add more?

If you require setting up this authentication method it should prevent most spam sign-ups.

 

[theZerg]

@cypherdoc The server sends a "challenge" consisting of something like "reddit.com:0x584FE4443984854898328348348834834893493943". The client signs this using their private key, the server then verifies the signature.

The server remembers the balance by remembering the txout and pubkey making sure it is never spent. It could be a lightweight client...

If this system allowed physical access to bank or corporate buildings (for example), the company might insist or a non-trivial balance and probably give it to you (the first time anyway).

@chmod755 I think it would be more secure to invalidate this login permanently if the coins ever move (but YMMV). You would then recover the account using some out-of-band technique which could be as simple as the terribly insecure recover-password email or as complex as physically visiting your bank or building security with identification documents. At that point a new bitcoin address would be generated and associated with the login.

 

[theZerg]

Also note that since your wallet is secured & encrypted with a password or PIN, this idea is a form of 2FA -- you need both the wallet hardware (phone or laptop) and the password you've memorized.

And last idea around this so far is that it be added to a normal bitcoin wallet, but the wallet internally "knows" to spend these addresses last. So there is no overt indication in the GUI that these addresses are special. However, the wallet knows what to do when placed against a NFC reader, when it receives a request from your browser, or even a photo of a QR code.

 

[cypherdoc]

This is close to SQRL.

how does the client initiate the challenge?

Upon initiating the account, does the user simply turn over his pubkey, which the domain holds indefinitely?

You need a means of revocation. How's that done while retaining anonymity?

 

[theZerg]

I was unaware of SQRL but from wikipedia yes it looks like they solve the same problem.

You would browse to a web site or put your phone up to a NFC tag.

On the web site, there would be a QR code that you scan. Or (if you are browsing on the device that contains your wallet), you click a link to an application-specific URL, like the bitcoin pay URL. That URL or QR code contains the challenge string and an URL where the response should be submitted. The bitcoin wallet gets the QR code or app-specific URL, asks for your PIN, signs the challenge, and returns it to server (via the embedded URL). Now the server lets the login proceed.

From a UI perspective, you could give a bitcoin address... but under the covers yes you are giving the server your pubkey.

Revocation: You mean the server kicking out users? Just delete the bitcoin address/pubkey associated with the login. Or the user revoking this method of access to the server? Just move the coins at the bitcoin address.

 

[cypherdoc]

>From a UI perspective, you could give a bitcoin address... but under the covers yes you are giving the server your pubkey.

you can't just give the server the address. it needs the revealed pubkey to verify the signature.

>revocation

i mean if the user loses his privkey he can't get back into his acct. there needs to be some failsafe mechanism for him to re-engage his acct.

>verify bitcoin balance

i wouldn't simply make that privkey be the last one in sequence to spend from. how many times have you drained your wallet on the go? there would need to be a lock on the privkey to ensure it doesn't get spent from. i'm not even sure why you need this balance check in the first place.

 

[theZerg]

.> address

Right. Basically you give the server the bitcoin address during setup. Then during the challenge/response the client provides the pubkey AND the signed challenge. The server verifies that the pubkey hashes to the address and that the pubkey matches the signature.

> revocation

hmm... I consider that an out-of-band operation that would vary based on the security of the web site or physical location being accessed. In other words, Somebody-Else's-Problem

> verify bitcoin balance

You could do that. But the point is if your wallet is compromised the first thing that will happen is a hacker will steal your money (the canary dies). If there is a lock on the address that won't work. If there's a notification like "hey, you're about to spend the coins that provide access to mybank.com" then a hacker with half a brain will not spend those coins. But a wallet provider could be subtle about it. Maybe an "are you sure?" message, or have 2 "wallets" inside the one app.

 

[cypherdoc]

> But the point is if your wallet is compromised the first thing that will happen is a hacker will steal your money (the canary dies).

good pt.

but you still would need some sort of revocation to get back into the site/acct at that pt.

sounds like a nifty system. didn't Bitcoin Authenticator do something like this already? also Trezor has a variant on this theme.