Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Network clear password sending - solution for README.sha1.txt [CORE2546] #2956

Closed
firebird-automations opened this issue Jul 7, 2009 · 12 comments

Comments

@firebird-automations
Copy link
Collaborator

Submitted by: @livius2

Attachments:
Solved.JPG

i read in README.sha1.txt
that is impossible to crypt user and pasword when conecting to Firebird
i read this
"Unfortunately, it's impossible to solve this problem without breaking old
clients"

but is simple solution for this
If we connect with new client we can send some more data
and check existence of this data on server side.
If data not exists then client is "old client" without password encryption

e.g. new client should send at start of password char #⁠5 - this is not readable character
if this char exists then password is encrypted by new algorithm

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Sorry, but it does not solve a problem. If old client must be able to connect, that means we need to keep old not enough strong hashes in security DB and check for them if there is no char #⁠5 symbol in password. I.e. anyone who wants to attack a server can use this method and new high quality encryption does not help.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

I see this in this way

e.g AES method
on server side we store AES Key file (user genarete it for only self use)
in security database we then store old hashes encrypted with AES

and now

when new client connect to server then hash is ok at first check

if old client connet -
server decrypt (AES) data stored in security database
and then we recive old hash which can be compared with old hashed string sended by old client

summary:
in security database we store not password crypted by new algorithm
but old hash crypted by new algorithm

-------------------------------------------------
i suppose that this solve problem
and also do possibility to store longer passwords then 8 characters
of course old client can't use longer password but this is only simple limitation :)

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

My English is bad so i attache picture
with situation on left and algorithm on right

@firebird-automations
Copy link
Collaborator Author

Modified by: @livius2

Attachment: Solved.JPG [ 11470 ]

@firebird-automations
Copy link
Collaborator Author

Modified by: @livius2

summary: Network clear password sending - solution => Network clear password sending - solution for README.sha1.txt

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Short passwords on old clients is not 'simple limitation'. With such short passwords no hash can be efficient.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

>>With such short passwords no hash can be efficient.

old client can not send longer password
if someone need longer password then must upgrade old software
if i understand this readme file correctly - braking old client is the problem - i suppose - i solve this

>>If old client must be able to connect, that means we need to keep old not enough strong hashes in security DB

but in security database data will be stored secure
becaouse old hash will be encrypted by new algorithm
in security database old has not exist explicit
but will be inside some field e.g encrypted blob with structure like oldhash and NewHash and more data if needed

this solve problem - old clients still can work - then this solve problem braking old clients
and new clients can work very secure becaouse
not only data will be stored in security database in secure mode
but olso data sending by New client can be secure e.g. encrypted, compressed ..

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Karol, the probem is not in which form hashes are stored in security DB.

As long as we need to accept logins from old clients the server is not secure enough - we can't request min password length to be long enough to use newer hashes effectively.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

>>As long as we need to accept logins from old clients the server is not secure enough
may be stupid question but old client can not be replaced by new client (fbclient)?
Can this brake some applications? I suppose that not

and generally question - why this is not secure?
If "you" need to communicate with serwer in secure mode then upgrade client to solve security problem
now we can not do this even if we need this becaouse this functionallity not exists

>> we can't request min password length to be long enough to use newer hashes effectively.
No, No - newer hashes will be used always if new client connect even if password will be 1 character
only old clients send max 8 characters password hash as it has designed

@firebird-automations
Copy link
Collaborator Author

Commented by: @AlexPeshkoff

Ability to choose different password transfer methods is planned for FB3.
In that case you will be able to select what to use, and you will be able to reject attempts to login using old client.

@firebird-automations
Copy link
Collaborator Author

Commented by: @livius2

This ticket can be closed as fixed in FB3

@firebird-automations
Copy link
Collaborator Author

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 3.0.0 [ 10740 ]

assignee: Alexander Peshkov [ alexpeshkoff ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment