On Oct 1, 2011, at 9:24 , Ron Wilson wrote:
> On Fri, Sep 30, 2011 at 2:27 PM, Dmitry Chestnykh
> wrote:
>> The attacker cannot supply hash, he supplies password. To do timing attack,
>> the
>> attacker have to find a such string, for which the hash has a few bytes
>> changed.
>
> You and I se
On Fri, Sep 30, 2011 at 2:27 PM, Dmitry Chestnykh
wrote:
> The attacker cannot supply hash, he supplies password. To do timing attack,
> the
> attacker have to find a such string, for which the hash has a few bytes
> changed.
You and I seem to be talking about different use cases, There are
sce
> Actually, you can do this with a hash. When it comes to comapring 2
> hashes, they are still strings of charcters. If anything, the timing
> attack would save even more time since, for purposes of camparing 2
> strings, the hash is just a much longer password. The question then
> is, is the hash
On Fri, Sep 30, 2011 at 6:43 AM, Dmitry Chestnykh
wrote:
> I'm mostly concerted about cookies, as it's impossible to time non-plain-text
> passwords -- the
> attacker simply cannot supply passwords which, when hashed, have a few bytes
> of hash
> modified (that is, when you supply "password", th
> I think this is a good patch and that it should be merged into trunk.
Is it too early to get rid of plain-text password support? I think hashed
passwords appeared about 1.5 years ago. If we remove it, we can leave "pw=%Q",
I think. The only code left susceptible to timing attacks will be for c
I think this is a good patch and that it should be merged into trunk.
On Fri, Sep 30, 2011 at 7:07 AM, Stephan Beal wrote:
> On Fri, Sep 30, 2011 at 12:43 PM, Dmitry Chestnykh <
> dmi...@codingrobots.com> wrote:
>
>> However, due to the use of plain-text passwords in the old versions and
>> comp
On Fri, Sep 30, 2011 at 12:43 PM, Dmitry Chestnykh
wrote:
> However, due to the use of plain-text passwords in the old versions and
> compatibility with them, it is currently possible to supply password hash
> (if you know project-id) instead of the password:
>
if i'm not mistaken you need both t
> 2011/9/29 Lluís Batlle i Rossell
> Well, if someone has studied those attacks, and the code by dmitry looks fine
> and works based on some heavier studies than our first thoughts on that, let's
> use it. No?
>
> i can't object, i just think it's paranoid :).
Well, it is paranoid, yes :-) I'm o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/29/2011 07:57 PM, Dmitry Chestnykh wrote:
> I posted a link about this concern:
> http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
This is also why introducing a random delay to mask the timing doesn't
really solve the probl
2011/9/29 Lluís Batlle i Rossell
> Well, if someone has studied those attacks, and the code by dmitry looks
> fine
> and works based on some heavier studies than our first thoughts on that,
> let's
> use it. No?
>
i can't object, i just think it's paranoid :).
--
- stephan beal
http://wand
On Thu, Sep 29, 2011 at 8:57 PM, Dmitry Chestnykh
wrote:
> I posted a link about this concern:
> http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
So why not simply add the following logic to server mode:
A) fetch config option "add-random-sleep" (integer, default=0)
B) if (
> So why not simply add the following logic to server mode:
>
> A) fetch config option "add-random-sleep" (integer, default=0)
> B) if ((A)>0) AND user is nobody, sleep for random 1..(A) ms. (This attack
> would seem to be useless for anyone but the nobody user. If you're logged in,
> you've got
On Thu, Sep 29, 2011 at 09:07:37PM +0200, Stephan Beal wrote:
> On Thu, Sep 29, 2011 at 8:57 PM, Dmitry Chestnykh
> wrote:
>
> > I posted a link about this concern:
> > http://rdist.root.org/2010/01/07/timing-independent-array-comparison/
>
>
> So why not simply add the following logic to server
On Sep 29, 2011, at 20:15 , Stephan Beal wrote:
> Given the relatively high overhead fossil has when it opens a db or runs a
> query, and network latency, i cannot imagine that someone could accurately
> time the difference of a memcmp() operation on 8 or 10 bytes. The number of
> factors invol
On Thu, Sep 29, 2011 at 08:15:55PM +0200, Stephan Beal wrote:
> On Thu, Sep 29, 2011 at 8:00 PM, Dmitry Chestnykh
> wrote:
>
> > The more eyes the better, as it touches login code.
> > ...COMPARE("A", "PASSWORD") returns FALSE in 0.1 msec, but
> > COMPARE("P", "PASSWORD") returns F
On Thu, Sep 29, 2011 at 8:00 PM, Dmitry Chestnykh
wrote:
> The more eyes the better, as it touches login code.
> ...COMPARE("A", "PASSWORD") returns FALSE in 0.1 msec, but
> COMPARE("P", "PASSWORD") returns FALSE in 0.3 msec, because it did
> two comparisons:
>
Given the relativel
16 matches
Mail list logo
