Improve client password protection

Bug #1485315 reported by Sopor
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AirDC++
Confirmed
Medium
Unassigned

Bug Description

If i activate password protection it will not work. I can do what ever i did before. It will not ask for any password.

If i also enable 'Protect tray' i can do everything i did before. It will not ask for any password.
If you enable this the 'Minimize to tray' should also be enabled or at least it should inform the user about it.

If i enable 'Minimize to tray' it will now protect 'show AirDC', but i can still refresh file list, change the speed, show the about and open download directory.

Revision history for this message
maksis (maksis) wrote :

I'd rather vote for removing the feature. You should lock the computer if you don't want other people to access it.

Revision history for this message
Night (night.) wrote :

While I agree in some ways that the protection should start from the OS level, I would still like to improve the client password protection feature so it extends to encrypting files like favorites.xml( or possibly atleast hub passwords ). Plain text favorites.xml is kind of a security risk for hubs. Ofc you can use other software to encrypt files in computer, but you can also use other software for limiting connection speeds.
Openssl could be used to encrypt/decrypt the file or passwords using a pass phrase to unlock during startup.

summary: - password protection won't work as it should
+ Improve client password protection
Changed in airdcpp:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
maksis (maksis) wrote :

I don't see how that helps. If you have access to the config file, can't you just kill the app and edit the config file.

Revision history for this message
Night (night.) wrote :

The password would not be saved anywhere ofcourse, it should be used to decrypt the favorites.xml using keyfile and passphrase of openssl encryption. (the password cannot be recovered)

The favorites.xml itself would not be unencrypted in the disk. Ofc this isnt completely secure for a running client, but it hides the data and cannot be accessed in <any> way when the client is closed. However, it doesnt bring major improvments for hub security on a running client because most hubs allow users to display their hub password with a user command.

To fix that, the client should be locked and the display from tray for example, should be protected by verifying the keyfile and passphrase entered. But for starters i believe that hiding the plain text information from favorite hubs would be still an improvment to security.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.