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
Comments
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. |
Commented by: @livius2 I see this in this way e.g AES method and now when new client connect to server then hash is ok at first check if old client connet - summary: ------------------------------------------------- |
Commented by: @livius2 My English is bad so i attache picture |
Modified by: @livius2Attachment: Solved.JPG [ 11470 ] |
Modified by: @livius2summary: Network clear password sending - solution => Network clear password sending - solution for README.sha1.txt |
Commented by: @AlexPeshkoff Short passwords on old clients is not 'simple limitation'. With such short passwords no hash can be efficient. |
Commented by: @livius2 >>With such short passwords no hash can be efficient. old client can not send longer password >>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 this solve problem - old clients still can work - then this solve problem braking old clients |
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. |
Commented by: @livius2 >>As long as we need to accept logins from old clients the server is not secure enough and generally question - why this is not secure? >> we can't request min password length to be long enough to use newer hashes effectively. |
Commented by: @AlexPeshkoff Ability to choose different password transfer methods is planned for FB3. |
Commented by: @livius2 This ticket can be closed as fixed in FB3 |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 3.0.0 [ 10740 ] assignee: Alexander Peshkov [ alexpeshkoff ] |
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
The text was updated successfully, but these errors were encountered: