public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Aaron Voisine <voisine@gmail•com>
Cc: "bitcoin-development@lists•sourceforge.net"
	<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Time
Date: Fri, 25 Jul 2014 18:03:26 +0200	[thread overview]
Message-ID: <CANEZrP1wd7VirEisbgU7SJakSfnxmqbydfjab6Abz2-WKS90Ag@mail.gmail.com> (raw)
In-Reply-To: <CACq0ZD7G1mKGW6ktraOhS7PuaJe_BRZzHpk0RsRmvwiPrpp_nA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3716 bytes --]

Sorry, you're right. I'd have hoped a delay that doubles on failure each
time up to some max would be good enough, relying on the p2p network to
unlock a PIN feels weird, but I can't really quantify why or what's wrong
with it so I guess it's just me :-)


On Fri, Jul 25, 2014 at 4:45 PM, Aaron Voisine <voisine@gmail•com> wrote:

> The problem is if someone moves system time forward between app launches.
> The lockout period doesn't have to be all that precise, it just makes you
> wait for the next block, then 5, then 25, and so on. Using a well
> known time server over https would also be a good option, but the wallet
> app already has the chain height anyway.
>
>
> On Friday, July 25, 2014, Mike Hearn <mike@plan99•net> wrote:
>
>> Given that the speed at which the block chain advances is kind of
>> unpredictable, I'd think it might be better to just record the time to disk
>> when a PIN attempt is made and if you observe time going backwards, refuse
>> to allow more attempts until it's advanced past the previous attempt.
>>
>>
>> On Fri, Jul 25, 2014 at 7:56 AM, Aaron Voisine <voisine@gmail•com> wrote:
>>
>>> It's based on the block height, not the block's timestamp. If you have
>>> access to the device and the phone itself is not pin locked, then you
>>> can jailbreak it and get access to the wallet seed that way. A pin
>>> locked device however is reasonably secure as the filesystem is
>>> hardware aes encrypted to a combination of pin+uuid. This was just an
>>> easy way to prevent multiple pin guesses by changing system time in
>>> settings, so that isn't the weakest part of the security model.
>>>
>>> Aaron Voisine
>>> breadwallet.com
>>>
>>>
>>> On Thu, Jul 24, 2014 at 8:21 PM, William Yager <will.yager@gmail•com>
>>> wrote:
>>> > On Thu, Jul 24, 2014 at 10:39 PM, Gregory Maxwell <gmaxwell@gmail•com>
>>> > wrote:
>>> >>
>>> >>
>>> >> Is breadwallet tamper resistant & zero on tamper hardware? otherwise
>>> >> this sounds like security theater.... I attach a debugger to the
>>> >> process (or modify the program) and ignore the block sourced time.
>>> >>
>>> >
>>> > It's an iOS application. I would imagine it is substantially more
>>> difficult
>>> > to attach to a process (which, at the very least, requires root, and
>>> perhaps
>>> > other things on iOS) than to convince the device to change its system
>>> time.
>>> >
>>> > That said, the security benefits might not be too substantial.
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Want fast and easy access to all the code in your enterprise? Index and
>>> > search up to 200,000 lines of code with a free copy of Black Duck
>>> > Code Sight - the same software that powers the world's largest code
>>> > search on Ohloh, the Black Duck Open Hub! Try it now.
>>> > http://p.sf.net/sfu/bds
>>> > _______________________________________________
>>> > Bitcoin-development mailing list
>>> > Bitcoin-development@lists•sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>> >
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck
>>> Code Sight - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>
> --
>
> Aaron Voisine
> breadwallet.com
>

[-- Attachment #2: Type: text/html, Size: 5263 bytes --]

  reply	other threads:[~2014-07-25 16:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25  1:14 Ron OHara
2014-07-25  1:41 ` Jeff Garzik
2014-07-25  2:35 ` Aaron Voisine
2014-07-25  2:39   ` Gregory Maxwell
2014-07-25  3:21     ` William Yager
2014-07-25  5:56       ` Aaron Voisine
2014-07-25 10:26         ` Mike Hearn
2014-07-25 14:45           ` Aaron Voisine
2014-07-25 16:03             ` Mike Hearn [this message]
2014-07-25 16:22               ` Natanael
2014-07-25 18:14                 ` Aaron Voisine
2014-07-25 10:30 ` Mike Hearn
2014-07-27 22:22   ` Peter Todd
2014-07-28 17:33   ` Troy Benjegerdes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CANEZrP1wd7VirEisbgU7SJakSfnxmqbydfjab6Abz2-WKS90Ag@mail.gmail.com \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=voisine@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox