• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Feature - 2 Factor Authentication

eduffield

Core Developer
Something that's always plagued crypto currencies is the fact that storing money on your computer can be very unsafe unless you have extensive experience with computer security. This has caused countless users to loose their money and people to call these currencies unsafe. Another consequence is average everyday users are scared away from keeping crypto currencies on their computers or venturing into the new field altogether because they're scared of having their money stolen.

These issues compound further, as you must store your Darkcoin in a paper wallet in order to keep them safe. However, this allow can be dangerous. How much experience is required to create the paper wallet in such a way where you can be sure it's safe and wasn't compromised while it was being created?

As a result, inexperienced users commonly rely on 3rd parties to store their coins, which are also insecure.

The solution: Protocol level 2-Factor Authentication.

I propose a protocol extension whereby you can sign a specific Darkcoin address, requiring the second level of validation. This will propagate across the network and all clients will require the code to process any future transactions from this address. Money can go into these protected addresses freely, however, to move out they will require this code.

This will be built directly into the core client as an optional feature, to be implemented after InstantX has been released.

This means if someone gains access to your machine and your private keys, any transactions they make using those keys will be outright rejected by the network. You'll know your keys have been stolen and be able to safely move your funds and secure your computer.

No more will we hear "I turned by computer on and now all of my Darkcoins are gone" and everyday users will be able to use Darkcoin for their online purchases without having to risk losing their money to thieves.

How will it work?

Upon sending a transaction, the client will look at the current 2FA requirements for the addresses involved. Then it will ask you to validate the transaction by entering the code. The code will be passed to the network via the data field of the transaction. The rest of the network will take the code in the data field and use an API to make sure the code is approved and include the message in the memory pool. New blocks will also be validated by using the API to make sure all transactions are OK.

More research must be done to find a compatible 2FA API. There are many services to choose from and we'll evaluate each to find the best match.
 
Agree. Would be awesome, and yet another addition to our vast amount of unique features.
 
I know this is still preliminary, but could someone setup a rogue client effectively unmasking these pins for the 2fa or is this not possible because the network just sees the encrypted end-result?
 
My mind just blew up a bit. I wouldn't put it in front of auto updating wallets. Or would I?! Love it!
 
I think this can be done with multisigs. With a 2 of 2 multisig and the second signature in the phone, you'll always need to validate the transaction from the phone's wallet. The 'only' thing needed would be a way to link phone and computer wallets and let them communicate. Maybe a unique random identifier of the wallet that you introduce in the other wallet could tie them together? If that were feasible, one could send the other the public key of an address to generate the multisig. Then the send tab would need to be able to create a multisig transaction, sign it and send the data about the transaction (just a long text string) to the other wallet for signature.

Am I missing something?
 
Just when you thought this coin was innovative enough - they pull this out....
I was thinking today what another idea Evan will bring on the table. Man, I didn't think you could read my mind too I`m impressed with this new feature which will be implemented. No more worries about lost coins etc! I think i`ll can`t sleep tonight, really! Evan and all dev team, you guys rocks!!!

EDIT: some english corrections.
 
Last edited by a moderator:
Another brilliant stroke of insight Evan, congratulations and thank you.

This addresses what has been my primary concern with DRK up to this point, and sounds like it might be functionally equivalent to a solution I had hoped for; a DRK wallet along the lines of Bitcoin Armory. Armory's solution involves keeping funds in off-line cold-storage wallets, while maintaining "watching only" wallets online. The online wallets can receive funds and monitor receipts, and initiate payments, but the payment must be signed by the off-line wallet prior to being broadcast by the online wallet. The deterministic addressing system allows for paper backups to be made which can recover all funds in the wallet, even addresses created after the creation of the paper wallet. In addition the paper backups can require a handwritten code to prevent recovery of the paper wallet from the memory of a junked printer. It also allows wallet recovery based on m of n sigs, and multi-sig transactions are native to the wallet. All this sounds complicated, but even I can do it with my wimpy funds. (Unfortunately, I don't use it anymore since I spent my limited stash of BTC buying DRK.) :grin:

The developer, Alan Reiner has a humility and level of creativity that reminds me of someone we all admire. He has open-sourced BTCArmory, and even given some helps for adapting it to other coins. Given his own project, I doubt he could be convinced to jump on DRK, but I think he would make a great addition to the DRK dream team. None-the-less, I continue to think that some of his Armory ideas would be worth incorporating into the DRK system.

Two links for those with deeper understanding than mine:
https://bitcoinarmory.com/wallet-format/
https://bitcoinarmory.com/using-armory-python/
 
So how would the two factor codes be held? Would it be a single server or somehow distributed from the MN network?
 
This means I can keep my beloved hot masternodes and I don't need to become a linux security expert!

Totes Amazeballs lol :grin:
 
Another brilliant stroke of insight Evan, congratulations and thank you.

This addresses what has been my primary concern with DRK up to this point, and sounds like it might be functionally equivalent to a solution I had hoped for; a DRK wallet along the lines of Bitcoin Armory. Armory's solution involves keeping funds in off-line cold-storage wallets, while maintaining "watching only" wallets online. The online wallets can receive funds and monitor receipts, and initiate payments, but the payment must be signed by the off-line wallet prior to being broadcast by the online wallet. The deterministic addressing system allows for paper backups to be made which can recover all funds in the wallet, even addresses created after the creation of the paper wallet. In addition the paper backups can require a handwritten code to prevent recovery of the paper wallet from the memory of a junked printer. It also allows wallet recovery based on m of n sigs, and multi-sig transactions are native to the wallet. All this sounds complicated, but even I can do it with my wimpy funds. (Unfortunately, I don't use it anymore since I spent my limited stash of BTC buying DRK.) :grin:

The developer, Alan Reiner has a humility and level of creativity that reminds me of someone we all admire. He has open-sourced BTCArmory, and even given some helps for adapting it to other coins. Given his own project, I doubt he could be convinced to jump on DRK, but I think he would make a great addition to the DRK dream team. None-the-less, I continue to think that some of his Armory ideas would be worth incorporating into the DRK system.

Two links for those with deeper understanding than mine:
https://bitcoinarmory.com/wallet-format/
https://bitcoinarmory.com/using-armory-python/
Armory is amazing, I installed it recently to learn how it did multisig and I'm completely blown away.
 
Double Safety !
Love it ... great ideas , great team ...>>
 
Hmm... if I understand this link correctly (https://www.authy.com/what-is-authy) it requires your giving up your cell number. Not exactly a system I would want to use to access my DRK!

Authy knows nothing about what you have configured as 2fa tokens, is all encrypted client side like zerobin.
The phone number is for recovery when you need to migrate the encrypted database to a new device.
Authy supports TOTP (RFC 6238) tokens with the added convenience of recovering your keys if your phone or device is lost or damaged.
 
Last edited by a moderator:
In reference to my last post above; I have been impressed with my Yubikey, but still must trust yubico servers. On the other hand, FIDO may have some promise if the devices can be obtained anonymously.

The following quotes are from: https://www.yubico.com/applications/fido/

"Universal 2nd Factor (U2F) is an emerging open authentication standard focused on scaling high security public key and “smart card” technology to every Internet user."

"Own or outsourced identity provider - Allows every service provider to be their own identity provider, or optionally provide authentication support through a federated service provider using SAML, oAuth, etc"

"Highest level of privacy - Introduces a truly user centric identity, where a user may own and control their own secure online identity. And each user can chose to have multiple identities, including anonymous (no personal information associated with the identity)"

Most of the 2factor systems I see being implemented require use of sms or other phone tech that while securing identity, eliminate anonymity.
 
Back
Top