Opened 8 years ago

Closed 8 years ago

#10944 closed Feature request (duplicate)

Enhance Password Security

Reported by: Make-It-Better Owned by:
Priority: high Component: FileZilla Client
Keywords: password security Cc:
Component version: Operating system type:
Operating system version:

Description

FileZilla is a great tool and I have seen the former arguments to refuse the improvement of Password Security and I understood them fully.

Yes, it is not possible to have a tool that is 100% secure. But the point is to have a tool that is as secure as possible with respect to functions and usability.

The argument against a master password was, that an intruder or malicious code could capture the master password entry "as easy as reading out the config with the stored passwords".

Is it really exactly the same?
No, it isn´t.

The probability for an intruder or malicious code to successfully read out the config is much higher then the probability to stay undiscovered in the system (for hours, days or weeks) an then be able to successfully capture the entering of a master password and then read out the passwords.

So FileZilla would with a small improvement be much more secure than today!

So please think over the old convictions and PLEASE add a Master Password to FileZilla to protect the FTP-account passwords in a better way than today.

Change History (3)

comment:1 by Make-It-Better, 8 years ago

Type: Bug reportFeature request

comment:2 by webdev, 8 years ago

Check out FileZilla Secure it's FileZilla with the Master Password protection.

Version 0, edited 8 years ago by webdev (next)

comment:3 by Tim Kosse, 8 years ago

Resolution: duplicate
Status: newclosed

There are a bunch of security issues with that version:

  • Custom AES and SHA implementation instead of using libnettle
  • It corrupts large queues due to only using a 32bit integer for file sizes
  • Header (de)serialization is not endianess-aware
  • It does not handle the case in which the different files use different passwords, silently discarding the user's data
  • The iv isn't chosen randomly, encrypting the same data twice yields the same ciphertext
  • The ciphertext isn't authenticated, it is possible for an attacker to change parts of the plaintext to his liking, e.g. the stored host where the password is ultimately sent to
  • You cannot rely on the code that checks only one instance of FileZilla is running, the settings may be stored on a filesystem that does not support this functionality. It can fail for any number of additional reasons as well
  • I haven't looked a the queue storage code yet, probably more issues there as it's a lot of new code

Also this is a duplicate of #5530

Note: See TracTickets for help on using tickets.