Pages:
Author

Topic: Armory - Discussion Thread - page 92. (Read 521763 times)

legendary
Activity: 980
Merit: 1008
November 06, 2013, 01:02:34 PM
Did you guys look at the keepass plugin.  It works like this.  Instead of being assigned a key, you type in your own secret key that is used to hash the one time passwords.  I'm not sure how that number is stored or the OTP are calculated but I imagine someone in the crypto know could explain this.  My guess is that it's not needed again since the OTP are count based not time based so it is not stored.  Everyone on the keepass forums raves about this feature and it is just protecting a database stored locally.  So either they all don't understand cryptography the same as the BTC community (very possible), or there is an extra layer of security here. 

You then take that same key you created and put it in google authenticator on your phone.  Then you write this KEY down, just like any other 2FA key in case you lose your phone etc...

Now if your wallet file was every stolen the attacker would not only have to know your password or brute force it, but also would have to somehow find out what key is being used to calculate your OTP.
Here's an answer: https://bitbucket.org/devinmartin/keeotp/issue/15/totp-for-keepass-login

The OTP's I know from Google Authenticator are six-digit codes, so they certainly can't be used if an attacker has access to your wallet, as he would only need to try one million combinations.

The problem with OTPs are that they are only secure when an attacker can access neither of the two devices that know the secret code.

With bitcoin exchanges, Amazon AWS, etc. the secret keys are stored on their servers and on your phone. Thus, an attacker can't know the next code unless he either compromises your phone or the servers. But what about a local wallet? The secret key has to be stored there, so traditional OTP can't work.

The real solution for 2-FA is to have a wallet that requires two keys to spend from (ie. send your money to a 2-of-2 multisig Bitcoin address). One key is in your wallet itself, encrypted with your password, and the other key is on your phone. So you have to sign the transaction with each key to be able to spend from that wallet. I imagine this is somewhere on Alan's to-do list for Armory, but it's gonna take some time.
hero member
Activity: 763
Merit: 500
November 06, 2013, 12:33:16 PM
But there's no security gain in a local 2-factor, it's only useful to secure an online resource! You can't use it as a seed for crypting the wallet, if this is what you mean.

This is true -- to use google authentication you have to store the secret on the same computer as your wallet.  If someone can get your wallet, then they can get your secret.  But it can be used with PAM to secure login to your computer, so that someone could only get your files by physically getting to your drive.  I wonder if you can use google authenticator with an encrypted home directory.

Did you guys look at the keepass plugin.  It works like this.  Instead of being assigned a key, you type in your own secret key that is used to hash the one time passwords.  I'm not sure how that number is stored or the OTP are calculated but I imagine someone in the crypto know could explain this.  My guess is that it's not needed again since the OTP are count based not time based so it is not stored.  Everyone on the keepass forums raves about this feature and it is just protecting a database stored locally.  So either they all don't understand cryptography the same as the BTC community (very possible), or there is an extra layer of security here. 

You then take that same key you created and put it in google authenticator on your phone.  Then you write this KEY down, just like any other 2FA key in case you lose your phone etc...

Now if your wallet file was every stolen the attacker would not only have to know your password or brute force it, but also would have to somehow find out what key is being used to calculate your OTP.
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
November 06, 2013, 12:03:40 PM
But there's no security gain in a local 2-factor, it's only useful to secure an online resource! You can't use it as a seed for crypting the wallet, if this is what you mean.

This is true -- to use google authentication you have to store the secret on the same computer as your wallet.  If someone can get your wallet, then they can get your secret.  But it can be used with PAM to secure login to your computer, so that someone could only get your files by physically getting to your drive.  I wonder if you can use google authenticator with an encrypted home directory.
legendary
Activity: 1593
Merit: 1004
November 06, 2013, 11:48:50 AM
Total Noob question.  I love armory but I'm no IT pro.  It takes forever to start up Scanning Transactions.  Why does it go through so much work every time?  Even if I have it closed for an hour or so.  Do I have a setting wrong?
legendary
Activity: 2126
Merit: 1001
legendary
Activity: 924
Merit: 1000
November 06, 2013, 03:05:06 AM
I brought this up and I think someone suggested it wouldn't work, but why don't you add Google 2FA to the database that would be required to unlock it along with the pass phrase.  It seems as though everyone's greatest fear is someone getting a hold of the database and running a brute force attack on it.  Especially since inevitably there are definitely some dictionary passwords out there.

I know this is possible with a keepass database using this plugin:

http://keepass.info/plugins.html#otpkeyprov

It just seems like it would be a great option to be able to enable.

Armory runs on your own computer, there is no server on which to do 2 factor authentication.

You don't need a server for 2 factor auth, it can be done inside an application.

http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm

But there's no security gain in a local 2-factor, it's only useful to secure an online resource! You can't use it as a seed for crypting the wallet, if this is what you mean.
legendary
Activity: 1498
Merit: 1000
November 06, 2013, 02:33:40 AM
I brought this up and I think someone suggested it wouldn't work, but why don't you add Google 2FA to the database that would be required to unlock it along with the pass phrase.  It seems as though everyone's greatest fear is someone getting a hold of the database and running a brute force attack on it.  Especially since inevitably there are definitely some dictionary passwords out there.

I know this is possible with a keepass database using this plugin:

http://keepass.info/plugins.html#otpkeyprov

It just seems like it would be a great option to be able to enable.

Armory runs on your own computer, there is no server on which to do 2 factor authentication.

You don't need a server for 2 factor auth, it can be done inside an application.

http://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm
hero member
Activity: 763
Merit: 500
November 06, 2013, 02:24:26 AM
I brought this up and I think someone suggested it wouldn't work, but why don't you add Google 2FA to the database that would be required to unlock it along with the pass phrase.  It seems as though everyone's greatest fear is someone getting a hold of the database and running a brute force attack on it.  Especially since inevitably there are definitely some dictionary passwords out there.

I know this is possible with a keepass database using this plugin:

http://keepass.info/plugins.html#otpkeyprov

It just seems like it would be a great option to be able to enable.

Armory runs on your own computer, there is no server on which to do 2 factor authentication.

Check out the link that I sent above.  It is the exact same premise but instead of time stamped OTP it is counter based.
hero member
Activity: 496
Merit: 500
November 06, 2013, 02:08:21 AM
I brought this up and I think someone suggested it wouldn't work, but why don't you add Google 2FA to the database that would be required to unlock it along with the pass phrase.  It seems as though everyone's greatest fear is someone getting a hold of the database and running a brute force attack on it.  Especially since inevitably there are definitely some dictionary passwords out there.

I know this is possible with a keepass database using this plugin:

http://keepass.info/plugins.html#otpkeyprov

It just seems like it would be a great option to be able to enable.

Armory runs on your own computer, there is no server on which to do 2 factor authentication.
hero member
Activity: 763
Merit: 500
November 05, 2013, 08:40:55 PM
I brought this up and I think someone suggested it wouldn't work, but why don't you add Google 2FA to the database that would be required to unlock it along with the pass phrase.  It seems as though everyone's greatest fear is someone getting a hold of the database and running a brute force attack on it.  Especially since inevitably there are definitely some dictionary passwords out there.

I know this is possible with a keepass database using this plugin:

http://keepass.info/plugins.html#otpkeyprov

It just seems like it would be a great option to be able to enable.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 05, 2013, 02:28:17 PM
Completely random side-note: I think this is one of my new favorite python patterns (I just learned about decorators recently).  There's a few places to use it in Armory, but mostly excited about for other applications.


Code:
class PyBackgroundThread(threading.Thread):
   """
   Wraps a function in a threading.Thread object which will run
   that function in a separate thread.  Calling self.start() will
   return immediately, but will start running that function in
   separate thread.  You can check its progress later by using
   self.isRunning() or self.isFinished().  If the function returns
   a value, use self.getOutput().  Use self.getElapsedSeconds()
   to find out how long it took.
   """
  
   def __init__(self, *args, **kwargs):
      threading.Thread.__init__(self)

      self.output     = None
      self.startedAt  = UNINITIALIZED
      self.finishedAt = UNINITIALIZED

      if len(args)==0:
         self.func  = lambda: ()
      else:
         if not hasattr(args[0], '__call__'):
            raise TypeError, ('PyBkgdThread constructor first arg '
                              '(if any) must be a function')
         else:
            self.setThreadFunction(args[0], *args[1:], **kwargs)

   def setThreadFunction(self, thefunc, *args, **kwargs):
      def funcPartial():
         return thefunc(*args, **kwargs)
      self.func = funcPartial

   def isFinished(self):
      return not (self.finishedAt==UNINITIALIZED)

   def isStarted(self):
      return not (self.startedAt==UNINITIALIZED)

   def isRunning(self):
      return (self.isStarted() and not self.isFinished())

   def getElapsedSeconds(self):
      if not self.isFinished():
         LOGERROR('Thread is not finished yet!')
         return None
      else:
         return self.finishedAt - self.startedAt

   def getOutput(self):
      if not self.isFinished():
         if self.isRunning():
            LOGERROR('Cannot get output while thread is running')
         else:
            LOGERROR('Thread was never .start()ed')
         return None

      return self.output


   def start(self):
      # The prefunc is blocking.  Probably preparing something
      # that needs to be in place before we start the thread
      self.startedAt = RightNow()
      super(PyBackgroundThread, self).start()

   def run(self):
      # This should not be called manually.  Only call start()
      self.output     = self.func()
      self.finishedAt = RightNow()


# Define a decorator that allows the function to be called asynchronously
def AllowAsync(func):
   def wrappedFunc(*args, **kwargs):

      if not 'async' in kwargs or not kwargs['async']==True:
         # Run the function normally
         if 'async' in kwargs:
            del kwargs['async']
         return func(*args, **kwargs)
      else:
         # Run the function as a background thread
         del kwargs['async']
         thr = PyBackgroundThread(func, *args, **kwargs)
         thr.start()
         return thr

   return wrappedFunc

Simply take any function that you would normally define,

Code:
def myFunc(...):
   doSomething()

And add:

Code:
@AllowAsync
def myFunc(...):
   doSomething()

You can now call myFunc(..., async=True) to have it run in the background instead of in the main thread (control will go to the next line of code immediately without wainting for myFunc to finish).  If you want to keep track of it, you can instead do:

Code:
thr = myFunc(..., async=True)

while not thr.isFinished():
   doOtherStuff()

# It must be finished to have gotten here
data = thr.getOutput()
print "myFunc took %f seconds" % thr.getElapsedSeconds()

If you have functions that do a lot of I/O, but aren't needed for the subsequent operations, you can simply do the following to parallelize:

Code:
thr = myFunc(..., async=True)

doOtherStuffInParallel()

thr.join()  # will wait for it to finish

Very cool!   Just keep in mind that you don't get a computational advantage using python threads, but if you are doing things that are I/O limited, networking, UI-related, etc... it works wonderfully.

Okay, now back to this orphan chain bug...
hero member
Activity: 763
Merit: 500
November 05, 2013, 01:48:12 PM
What if I change my encryption password on my armory wallet file.  If there is an old wallet file on a usb key somewhere I assume that version of the wallet file would unlock with the older encryption password and not the new one?

Paper backups don't have this problem.  You make a backup once, and it doesn't depend at all on your password (which is part of the point of them... to help people recover their wallet when they forget the password).

Digital backups (in 0.88.1 and earlier) will be encrypted with the same passphrase that is used at the time the backup was made.  In order to use that digital backup, you'll have to know that earlier password, regardless of what you do with the active wallet you use.

The next version has a "make unencrypted digital backup" button which is intended for USB keys, etc.  This will make a digital backup with the same properties as the paper backup, besides the risk of device failure.  Until then... use paper!



I was asking more for the sake if I should start a new wallet, just wondering if I have any old electronic copies of my wallet floating around with a encryption key no where near as strong as it is now.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 05, 2013, 01:36:42 PM
What if I change my encryption password on my armory wallet file.  If there is an old wallet file on a usb key somewhere I assume that version of the wallet file would unlock with the older encryption password and not the new one?

Paper backups don't have this problem.  You make a backup once, and it doesn't depend at all on your password (which is part of the point of them... to help people recover their wallet when they forget the password).

Digital backups (in 0.88.1 and earlier) will be encrypted with the same passphrase that is used at the time the backup was made.  In order to use that digital backup, you'll have to know that earlier password, regardless of what you do with the active wallet you use.

The next version has a "make unencrypted digital backup" button which is intended for USB keys, etc.  This will make a digital backup with the same properties as the paper backup, besides the risk of device failure.  Until then... use paper!

hero member
Activity: 763
Merit: 500
November 05, 2013, 12:40:24 AM
What if I change my encryption password on my armory wallet file.  If there is an old wallet file on a usb key somewhere I assume that version of the wallet file would unlock with the older encryption password and not the new one?
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 05, 2013, 12:06:07 AM
For offline transactions, is there any problem with creating and signing a transaction but delaying the broadcast for a while (e.g. months)?

How about creating but not signing?

There's no problem as long as you don't execute any more transactions between the time that the transaction was created and when it is broadcast.  Technically, it might work, but I wouldn't count on it.  For simplicity reasons, Armory doesn't "lock" any of your inputs to prevent them from being spent in further transactions, unless a signed transaction spending those inputs hits the network.  Therefore, if you create, sign and broadcast another transaction before broadcasting the first one, you are likely to spend some of its outputs which will make the first tx invalid.
legendary
Activity: 1834
Merit: 1020
November 04, 2013, 11:14:48 PM
For offline transactions, is there any problem with creating and signing a transaction but delaying the broadcast for a while (e.g. months)?

How about creating but not signing?
legendary
Activity: 1904
Merit: 1007
November 04, 2013, 07:32:30 PM
And neither random or urandom will spit out 0000, that's crazy.

0000 is just as likely as any other 4 digit number Smiley



Maybe we should use something like this:
Quote
"It fires photons at a small mirror, and the direction of those photons reflecting off the mirror is actually what decides what cards the player gets.

From http://www.pokerstarsblog.com/ukipt/2013/in-the-belly-of-the-beast-the-pokerstars-143107.html
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
November 04, 2013, 02:58:38 PM
Is there an interface in Armory that I can enter the hash256() result into (or the result of the dice throws), so I can generate a deterministic Armory wallet from a series of dice throws? Or is there some hackish way of doing it (I'm fine without a GUI).

If you have all the dependencies installed and can "from armoryengine import *" in a python shell without errors, then yes.  You can take your entropy source, run it through the hash256() function, and then run the result through the "makeSixteenBytesEasy()" method, which will add a checksum and convert it to "easyType16" format for a paper backup. (do 16 bytes at a time).

And if there isn't an interface in Armory, would you accept patches that implements one?

Kind of... it's a long story.  But those motivated enough will be able to figure it out from the instructions above...
legendary
Activity: 980
Merit: 1008
November 04, 2013, 02:52:32 PM
Personally, if you want to do this right without worrying too much, I would simply get a bunch of dice and collect 100-150 D6 rolls (that's 256-384 bits of entropy, if it was all perfect).  Make the process of ordering the dice rolls as deterministic as possible, to limit the amount of "human influence" on the results.  Just type them into a a python shell string hash256() the result.  Use that as your private key/seed. 

[...]
Is there an interface in Armory that I can enter the hash256() result into (or the result of the dice throws), so I can generate a deterministic Armory wallet from a series of dice throws? Or is there some hackish way of doing it (I'm fine without a GUI).

And if there isn't an interface in Armory, would you accept patches that implements one?
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
November 04, 2013, 02:40:26 PM
And neither random or urandom will spit out 0000, that's crazy.

0000 is just as likely as any other 4 digit number Smiley
Pages:
Jump to: