On Fri, Sep 30, 2011 at 2:27 PM, Dmitry Chestnykh
dmi...@codingrobots.com 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
On Oct 1, 2011, at 9:24 , Ron Wilson wrote:
On Fri, Sep 30, 2011 at 2:27 PM, Dmitry Chestnykh
dmi...@codingrobots.com 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.
-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
2011/9/29 Lluís Batlle i Rossell virik...@gmail.com
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,
On Fri, Sep 30, 2011 at 12:43 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
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
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 sgb...@googlemail.com 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
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
On Fri, Sep 30, 2011 at 6:43 AM, Dmitry Chestnykh
dmi...@codingrobots.com 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
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 long
Dear archeologists,
Please review changes in the following branch:
http://www.fossil-scm.org/index.html/timeline?r=dmitry-security
The more eyes the better, as it touches login code.
I try to protect against timing attacks on login, cookies, and sync by using
the constant-time comparison
On Thu, Sep 29, 2011 at 8:00 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
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
On Thu, Sep 29, 2011 at 08:15:55PM +0200, Stephan Beal wrote:
On Thu, Sep 29, 2011 at 8:00 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
The more eyes the better, as it touches login code.
...COMPARE(A, PASSWORD) returns FALSE in 0.1 msec, but
COMPARE(P, PASSWORD)
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 involved
On Thu, Sep 29, 2011 at 09:07:37PM +0200, Stephan Beal wrote:
On Thu, Sep 29, 2011 at 8:57 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
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
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 your
On Thu, Sep 29, 2011 at 8:57 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
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
2011/9/29 Lluís Batlle i Rossell virik...@gmail.com
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
17 matches
Mail list logo
