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 is a way
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 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. AFAIR
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 legacy
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 = server
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 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 public key and
Till today we always used to provide security database pre-configured
for use with single record for SYSDBA with masterke(y) password. In FB3
we have at least two reasons to stop use that schema:
- having masterkey as default preset-ted SYSDBA's password is security
vulnerability cause people are
On 20/12/2011 11:20, Alex Peshkoff wrote:
I wonder is it possible to change windows installer to initialize
security database. Next, for ZIP install people will have to run gsec
first time manually. Are this changes OK for us?
I don't think it is, specially for zip.
I think bind the server
On 12/20/11 17:26, Adriano dos Santos Fernandes wrote:
On 20/12/2011 11:20, Alex Peshkoff wrote:
I wonder is it possible to change windows installer to initialize
security database. Next, for ZIP install people will have to run gsec
first time manually. Are this changes OK for us?
I don't
On 20/12/2011 11:41, Alex Peshkoff wrote:
On 12/20/11 17:26, Adriano dos Santos Fernandes wrote:
On 20/12/2011 11:20, Alex Peshkoff wrote:
I wonder is it possible to change windows installer to initialize
security database. Next, for ZIP install people will have to run gsec
first time
On Tuesday 20 December 2011 at 14:20 Alex Peshkoff wrote:
I wonder is it possible to change windows installer to initialize
security database.
It is possible, but I'm not sure it is practical or desirable.
It would be interesting to know what percentage of deployments are for
development
12 matches
Mail list logo
