Security consensus question

[Inaba]

As many of you know, EMC was (is?) the first pool to offer both Yubikey and Google Authenticator as a 2FA authentication method.  As such, I've had a fair share of lost GA accounts (Yubikey not so much, guess it's harder to lose a physical object, as opposed to having to wipe your phone). 

Up until now, I have manually handled the cases individually.  However, with 2FA, the whole point is to prevent someone from being able to access your account even if they have one of the factors.  Allowing resets of the 2nd factor defeat or at least mitigate a large portion of this advantage.

So, my question is, what is the general consensus on how to handle failed/lost/broken 2FA as specifically related to the semi-anonymous nature of a Bitcoin pool?  I have neither the resources nor desire to call up people individually and figure out if they are who they say they are, nor do I want to require identifying information be sent to me, since it's suppose to be as anonymous as possible.  So what is a good compromise in a situation like this?

I'm open to all ideas, even if they are silly.

[rjk]

Require that payout lock be activated before 2FA is activated, and then you can send the remaining funds to that address and delete the account if there is a problem.

This might be annoying if someone wanted to keep their stats and workers, so maybe there could be a way to export the current config and/or stats and re-import to a new account maybe.

[Graet]

looking at 2factor too, will be watching this thread with interest

[markm]

I would go with GPG/PGP or, maybe more appropriately, a signed message signed using the private key of either their payout address or, if they prefer when setting up the account (not after their phone with the privkey on it was stolen) another bitcoin address they do not keep the key of on any of the machines involved in their two factors. Or, let them associate an Open Transactions nym simularly so as to be able to sign a message using the nym's key.

Basically all three of these suggestions amount to have them provide (in advance, at original account-creation time) a public key any messages sent by are to be taken as from them, and that thus they should not keep on any of their N-factor-authorisation devices and maybe should consider splitting up into many parts scattered across many devices or something depending on how paranoid they are.

Or, three-factor: have them provide three keys, one being a bitcoin address, one being an Open Transactions nym, the third being a GPG/PGP key, and require all three for any reset of their two-factor authorisation.

-MarkM-

[Graet]

<Ukto> theres a simple answer
<Ukto> you should post it back for me
<Ukto> create a custom Q&A db for people to set, and they can use that as a 3rd peice of info.  can also use gpg keys

[rjk]

<Ukto> theres a simple answer
<Ukto> you should post it back for me
<Ukto> create a custom Q&A db for people to set, and they can use that as a 3rd peice of info.  can also use gpg keys

http://thedailywtf.com/Articles/WishItWas-TwoFactor-.aspx

[Inaba]

Well, GPG keys are certainly one of the better methods to verify the identity, most people don't have/don't know how to use them... so they aren't really an option. 

Yubikey and GA are good options/popular because they are simple to use for the neophyte and require little to no understanding of secure authentication protocols by the end user.  If GPG keys were an option, just offering those as the second factor would be viable, but unfortunately it's not. 

I have considered the Q&A DB type thing, and while it's still an option, the link from RJK is pretty much why I haven't done it already.

[rjk]

Perhaps along with requiring a payout lock address be set prior to 2FA auth being enabled, you could code up some kind of validation utility that would validate a message signed by the payout lock address? In that case, the message could be something that is sent as part of an email reset.

[markm]

Which is one of the options I suggested, basically: use bitcoin app to sign something. For a pool, where what is to be secured is precisely their bitcoins and the address you are to send them to, it seems reasonable to assume they can lay their hands on some bitcoin client that can do such signatures, so it should not be as unfeasible as assuming they have acccess to GPG/PGP.

Just be sure to heavily stress that they should not use for that purpose any bitcoin address a thief stealing either of their two factor authentication devices would thereby get hold of the private key of.

-MarkM-

[Inaba]

Is there a guide somewhere already written on how to do that that I can direct people to?

[markm]

I just read a thread that showed how... it amounted to "bitcoind help", focussing on "bitcoind signmessage" and "bitcoind verifymessage" but also explicitly showed a message "I control this", signed, and the actual verifying of it.

Cant find the thread instantly for some reason.

-MarkM-

EDIT: Looks like it could do with a guide, or a way to tell it filename of message instead of trying to actually type the message:

Code:

[bitcoin@megabox bitcoin]$ ./realbitcoind.sh getnewaddress
123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ
[bitcoin@megabox bitcoin]$ ./realbitcoind.sh signmessage 123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ "I control this address: -MarkM-"
error: {"code":-1,"message":"signmessage <bitcoinaddress> <message>\nSign a message with the private key of an address"}
[bitcoin@megabox bitcoin]$ ./realbitcoind.sh signmessage 123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ \"I control this address: -MarkM-\"
error: {"code":-1,"message":"signmessage <bitcoinaddress> <message>\nSign a message with the private key of an address"}
[bitcoin@megabox bitcoin]$ ./realbitcoind.sh signmessage 123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ \\"I control this address: -MarkM-\\"
error: {"code":-1,"message":"signmessage <bitcoinaddress> <message>\nSign a message with the private key of an address"}
[bitcoin@megabox bitcoin]$ ./realbitcoind.sh signmessage 123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ I_control_ this_address:_-MarkM-
error: {"code":-1,"message":"signmessage <bitcoinaddress> <message>\nSign a message with the private key of an address"}

Aha, missed a blank:

Code:

[bitcoin@megabox bitcoin]$ ./realbitcoind.sh signmessage 123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ I_control_this_address:_-MarkM-
HA41vk/cdnZ8MsH6IcpUJIIkedmnCRniJCYYZmfomje99IzT958tVArC3gc0N1EiZbHmxs6qDue6cJHEvM1qOuc=

And verifying it:

Code:

[bitcoin@megabox bitcoin]$ ./realbitcoind.sh verifymessage 123Lo8CbsyYBonBbT8tXnbd5V7iSdFRhKZ HA41vk/cdnZ8MsH6IcpUJIIkedmnCRniJCYYZmfomje99IzT958tVArC3gc0N1EiZbHmxs6qDue6cJHEvM1qOuc=  I_control_this_address:_-MarkM-
true

-MarkM-

[FreeMoney]

Require that payout lock be activated before 2FA is activated, and then you can send the remaining funds to that address and delete the account if there is a problem.

This might be annoying if someone wanted to keep their stats and workers, so maybe there could be a way to export the current config and/or stats and re-import to a new account maybe.

You could even keep the same account with the rule: after funds are all sent to locked in address (plus waiting period?) you can turn off or reset the second factor.