On 12/20/11 14:38, Adriano dos Santos Fernandes wrote:
> On 20/12/2011 08:19, Alex Peshkoff wrote:
>> On 12/20/11 13:54, Adriano dos Santos Fernandes wrote:
>>> On 20/12/2011 06:57, Alex Peshkoff wrote:
connect: client's public key, login and database name => server
accept: server's
20.12.2011 11:25, Alex Peshkoff wrote:
> please agree that if one knows
> first 8 chars it's much simpler to guess/bruteforce/etc. the rest.
As a man who don't use meaningless passwords, I have to agree.
--
SY, SD.
--
On 20/12/2011 08:19, Alex Peshkoff wrote:
> On 12/20/11 13:54, Adriano dos Santos Fernandes wrote:
>> On 20/12/2011 06:57, Alex Peshkoff wrote:
>>> connect: client's public key, login and database name => server
>>> accept: server's public key and salt => client
>>> attach: client's proof =>
On 12/20/11 14:19, Dimitry Sibiryakov wrote:
> 20.12.2011 11:16, Dmitry Yemanov wrote:
>> The new auth protocol will not truncate the longer password
>> but the legacy one will, AFAIU.
>In this case there is no security breath: if a malefactor has got
> truncated password by
> bruteforcing l
On 12/20/11 14:06, Dimitry Sibiryakov wrote:
> 20.12.2011 7:30, Alex Peshkoff wrote:
>> Returning to that useful idea - the problem is that when the warning can
>> be returned password was already passed to the net in legacy unsafe
>> form.
>But here you are saying that legacy form is unsafe.
20.12.2011 11:16, Dmitry Yemanov wrote:
> The new auth protocol will not truncate the longer password
> but the legacy one will, AFAIU.
In this case there is no security breath: if a malefactor has got truncated
password by
bruteforcing legacy hash, it is useless.
--
SY, SD.
---
On 12/20/11 13:54, Adriano dos Santos Fernandes wrote:
> On 20/12/2011 06:57, Alex Peshkoff wrote:
>> connect: client's public key, login and database name => server
>> accept: server's public key and salt => client
>> attach: client's proof => server
>> response: success if client's proof == s
20.12.2011 14:06, Dimitry Sibiryakov wrote:
> AFAIR it is considered quite safe
> since version 2.0 because of using SHA1.
8 chars of max password length can be brute-forced, I suppose that was
the point. The new auth protocol will not truncate the longer password
but the legacy one will, AFAIU
On 12/20/11 13:46, Dmitry Yemanov wrote:
> 20.12.2011 12:57, Alex Peshkoff wrote:
>
>> Certainly, and it's already done. With one exception - FB3 protocol
>> begins authentication inside op_connect. That's absolutely backward
>> compatible - I've added new tags to CNCT_ID block, and they are
>> ce
20.12.2011 7:30, Alex Peshkoff wrote:
> Returning to that useful idea - the problem is that when the warning can
> be returned password was already passed to the net in legacy unsafe
> form.
But here you are saying that legacy form is unsafe. AFAIR it is considered
quite safe
since version 2.
On 20/12/2011 06:57, Alex Peshkoff wrote:
> connect: client's public key, login and database name => server
> accept: server's public key and salt => client
> attach: client's proof => server
> response: success if client's proof == server's proof
>
>
What I would like to know is that if there i
20.12.2011 12:57, Alex Peshkoff wrote:
> Certainly, and it's already done. With one exception - FB3 protocol
> begins authentication inside op_connect. That's absolutely backward
> compatible - I've added new tags to CNCT_ID block, and they are
> certainly just ignored by older servers. For FB3 cl
On 12/20/11 11:47, Dmitry Yemanov wrote:
> 20.12.2011 10:30, Alex Peshkoff wrote:
>
>> Returning to that useful idea - the problem is that when the warning can
>> be returned password was already passed to the net in legacy unsafe
>> form. That's not too big problem if this is password for FB<3. T
On 12/20/11 11:43, Dmitry Yemanov wrote:
> 19.12.2011 20:58, Alex Peshkoff wrote:
>> From security POV it's absolutely clear that we should use SRP as
>> default authentication plugin and should not mention legacy
>> authentication in default list of plugins on server. (This means that
>> people m
20.12.2011 10:30, Alex Peshkoff wrote:
> Returning to that useful idea - the problem is that when the warning can
> be returned password was already passed to the net in legacy unsafe
> form. That's not too big problem if this is password for FB<3. The worst
> case is when user mixed two servers a
19.12.2011 20:58, Alex Peshkoff wrote:
>
> From security POV it's absolutely clear that we should use SRP as
> default authentication plugin and should not mention legacy
> authentication in default list of plugins on server. (This means that
> people must upgrade clients, but this does not look li
On 12/19/11 21:43, Dimitry Sibiryakov wrote:
> 19.12.2011 17:58, Alex Peshkoff wrote:
>> but here security problem
>> comes. User will not know, does he work with new server (using secure
>> channel) or with old one (insecure channel).
>Make isc_attach_database() to return warning if insecure
On 12/19/11 21:43, Dimitry Sibiryakov wrote:
> 19.12.2011 17:58, Alex Peshkoff wrote:
>> but here security problem
>> comes. User will not know, does he work with new server (using secure
>> channel) or with old one (insecure channel).
>Make isc_attach_database() to return warning if insecure
19.12.2011 17:58, Alex Peshkoff wrote:
> but here security problem
> comes. User will not know, does he work with new server (using secure
> channel) or with old one (insecure channel).
Make isc_attach_database() to return warning if insecure channel is used.
--
SY, SD.
--
Hi, all!
I'm ready to commit secure remote passwords and related changes to svn.
But before I'd like to know your mind regarding default settings for
secure plugins. SRP provides a very reliable way to authenticate user by
password, being resistant to a lot of attacks, including man in the
middle
20 matches
Mail list logo
