Do not save password in Preferences

[mlep]

Is your suggestion for improvement related to a problem? Please describe.
Currently, the proxy configuration in Options -> Preferences -> Network requires the password being saved if the proxy needs an authentication.
As indicated by the warning message, the password is not protected, which raise a security concern.

Describe the solution you'd like
Do not impose to enter the password in the Preferences' field.
If the password is not saved, JabRef should prompt for it when using the proxy connection for the first time, and keep it in memory only for the current session.
Not a perfect solution, but an improvement.

[tobiasdiez]

The same applies to other passwords, like the one for a shared database.

jabref/src/main/java/org/jabref/logic/shared/prefs/SharedDatabasePreferences.java

Lines 33 to 34 in 2153a05

	// This {@link Preferences} is used only for things which should not appear in real JabRefPreferences due to security reasons.
	private final Preferences internalPrefs;

User credentials shouldn't be stored in the preferences at all. I'm making this a high priority bug since it's a huge design flaw.

I'm not totally sure but I think the best way to store passwords is using the credentials manager of the system (e.g. Windows credential manager). It's surprisingly hard to find a library that provides a cross-platform api. It looks like com.microsoft.alm.auth-secure-storage fits the bill.
For a usage example see https://github.com/microsoft/Git-Credential-Manager-for-Mac-and-Linux/blob/master/src/main/java/com/microsoft/alm/gitcredentialmanager/Program.java

[koppor]

We discussed that in our dev call. We need to focus on other topics to get the release done. We leave that as high-priority.

[koppor]

In case the library does not work, we could store the password once session. Meaning: At the first use, ask the user to type it in. At following accesses, the in-memory stored password should be used.

[calixtus]

Could be the solution for our password problem, as soon as we have jlink fixed @koppor @tobiasdiez :
https://github.com/javakeyring/java-keyring

[JacobTrossing]

Hi, we are a group of 5 students from KTH, Sweden interested in taking on this issue as a part of our "Software Engineering Fundamentals" course.

Would it be possible for us to be assigned this issue and do you have any further pointers you would like to give before we start working?

[github-actions]

As a general advice for newcomers: check out Contributing for a start. Also, guidelines for setting up a local workspace is worth having a look at.

Feel free to ask here at GitHub, if you have any issue related questions. If you have questions about how to setup your workspace use JabRef's Gitter chat. Try to open a (draft) pull-request early on, so that people can see you are working on the issue and so that they can see the direction the pull request is heading towards. This way, you will likely receive valuable feedback.

[calixtus]

Thanks for your interest in Jabref! And welcome to our community.
We are very happy, that you decided on contributing to jabref.
However, be aware that it is currently impossible to include any new library because of an issue with JDK/Jlink. We are working on a patch we eventually want to propose to the jdk, but this could take some time to be included and released.
So in case you need to include a new library, it will also probably take some time for your pr to be included in Jabref. 😞

[koppor]

Could be the solution for our password problem, as soon as we have jlink fixed @koppor @tobiasdiez : javakeyring/java-keyring

I like that library. It is available at https://central.sonatype.com/artifact/com.github.javakeyring/java-keyring/1.0.1

There should be, however, activity in a new release of the library, e.g., integrating javakeyring/java-keyring#78 and pushing towards a release. -- Nevertheless, we should give it a try to see if it works in principle.