Passwords for everyday use

The biggest challenge with passwords that you use regularly is keeping them safe. There are basically two ways to do this:

1) You memorise the password

There are various techniques for memorising passwords. For example, you can think of a simple sentence and use the initial letters, final letters, punctuation marks or similar."How do I think of 1 secure password?" becomes, for example, "Wdim1sPa?". The password should have at least 8 characters. Another option is a comparatively long password made up of whole words. If possible, these words should not be directly related or form a sentence. Example: "dog, cat, mouse, lizard, spock" - this way you have a lot to type, but you can remember the password relatively easily. It is nevertheless secure, as 5 (random) words are about as difficult to guess as 10 random letters when trying out all possible combinations.

2) Using a secure password store

The BSI website provides good advice on using a password manager. For example, the KeePassXC tool is recommended (available on UOL computers via the Baramundi software kiosk). Another option is a password hint as a reminder, which is stored in a safe place (e.g. in your wallet).

Other solutions such as writing down the entire password on a piece of paper (whether under the keyboard or locked away on the desk) or unsecured file storage on smartphones or cloud storage are too insecure.

Admin passwords / passphrases for encryption

Passwords that do not need to be memorised because they are rarely used and are stored in encrypted password archives, for example, and not typed in, should be generated randomly.

We recommend the ZENDAS tool or the KeePassXC password generator - with 32 characters, you are on the safe side as things stand today.

Changing passwords

Fortunately, the common practice of recommending or enforcing regular password changes has now been abandoned. As long as your password remains secret, there is no reason to change it. If you suspect that a password has been hacked or spied on, you should of course change it immediately.

Further information on the subject of passwords can be found, for example, on the BSI website.

You can find good introductory articles on the basics of research data management linked in our RDM information collection.

The open access article Good enough practices in scientific computing lists many practical tips. Most of them do not relate to computing in the narrow sense, but are universally applicable in data-driven research. The tips offer a pragmatic introduction to reproducible and reproducible research.

The article contains recommendations and tips on the following topics:

1. Data management
   1. Save the raw data.
   2. Ensure that raw data are backed up in more than one location.
   3. Create the data you wish to see in the world.
   4. Create analysis-friendly data.
   5. Record all the steps used to process data.
   6. Anticipate the need to use multiple tables, and use a unique identifier for every record.
   7. Submit data to a reputable DOI-issuing repository so that others can access and cite it.
2. Software
   1. Place a brief explanatory comment at the start of every program.
   2. Decompose programs into functions.
   3. Be ruthless about eliminating duplication.
   4. Always search for well-maintained software libraries that do what you need.
   5. Test libraries before relying on them.
   6. Give functions and variables meaningful names.
   7. Make dependencies and requirements explicit.
   8. Do not comment and uncomment sections of code to control a program's behaviour.
   9. Provide a simple example or test data set.
   10. Submit code to a reputable DOI-issuing repository.
3. Collaboration
   1. Create an overview of your project.
   2. Create a shared "to-do" list for the project.
   3. Decide on communication strategies.
   4. Make the licence explicit.
   5. Make the project citable.
4. Project organisation
   1. Put each project in its own directory, which is named after the project.
   2. Put text documents associated with the project in the doc directory.
   3. Put raw data and metadata in a data directory and files generated during cleanup and analysis in a results directory.
   4. Put project source code in the src directory.
   5. Put external scripts or compiled programs in the bin directory.
   6. Name all files to reflect their content or function.
5. Keeping track of changes
   1. Back up (almost) everything created by a human being as soon as it is created.
   2. Keep changes small.
   3. Share changes frequently.
   4. Create, maintain, and use a checklist for saving and sharing changes to the project.
   5. Store each project in a folder that is mirrored off the researcher's working machine.
   6. Add a file called CHANGELOG.txt to the project's docs subfolder.
   7. Copy the entire project whenever a significant change has been made.
   8. Use a version control system.
6. Manuscripts
   1. Write manuscripts using online tools with rich formatting, change tracking, and reference management.
   2. Write the manuscript in a plain text format that permits version control.

Wilson G, Bryan J, Cranston K, Kitzes J, Nederbragt L, Teal TK (2017) Good enough practices in scientific computing. PLoS Comput Biol 13(6): e1005510. doi.org/10.1371/journal.pcbi.1005510

In the context of research data management, there are various legal regulations that must be observed. This can give rise to complex issues in individual cases. The relevant topics and areas of law include

• Copyright, ancillary copyright and patent rights
• Assignment and ownership issues
• Non-disclosure agreements
• Service contract regulations
• Licence models for publication
• Liability issues
• Personal rights and data protection

Due to the wide range of data and possible legal regulations, it is difficult to make general recommendations. However, there are already extensive and well-prepared publications by legal experts. We are happy to refer you to a brief summary of the legal framework (under CC-BY-SA 4.0 licence) and a detailed guide to legal issues in Open Science (under CC-BY 4.0 licence).

The Research Data Management Service Centre is not permitted to provide legal advice. If you have specific legal questions or problems, please contact PGR - General Legal Affairs or the Data Protection and Information Security Unit for information on data protection. The Research Data Management Service Centre will be happy to provide you with general recommendations and, in particular, support with technical implementation.

How can I transfer data in encrypted form?

In research, confidential data (including personal data) often needs to be exchanged. It is assumed and sometimes explicitly demanded by ethics committees or data protection organisations that the data is transmitted securely so that it cannot be viewed by third parties.

Established communication media (e.g. email) or cloud storage/messenger solutions that may be used in the private sphere (e.g. Dropbox, WhatsApp or similar providers) have their limits. When using external services, the regular problem is that there is no suitable contractual agreement with the provider and therefore the confidentiality of the data cannot be guaranteed. For this reason, the business use of such services for confidential data is generally not permitted. Another common problem is the insecure (unencrypted) transmission of data, which is used, for example, when sending normal emails.

There are three basic encryption methods that are often mentioned or used in this area:

1. file encryption

Encryption at file level generally offers the highest level of protection, but is also the least convenient form. In practice, the biggest disadvantage is the poor distribution of the corresponding tools (installation, user training, etc.), as all parties involved have to use them.

The use of 7-Zip software (with AES-256), VeraCrypt or similar tools may be recommended if files need to be stored in encrypted form or sent by email.

2. email encryption (content encryption)

Email encryption works via S/MIME certificates (which can be obtained from DFN IT services) or via comparable alternatives such as PGP. Once configured, this is a convenient way of communicating in encrypted form, but here the problem of the lack of distribution is even greater than with the tools for file encryption, so that this method can hardly be recommended in practice. Although well-configured email servers also use transport encryption, you cannot rely on this and should therefore consider email to be unencrypted without further measures.

Caution: In addition to content encryption, there are also digital signatures that are displayed in Outlook with a seal symbol. This does not mean that the email is automatically encrypted. It only means that the identity of the sender has been checked by the certificate authority.

3. transport encryption

Transport encryption is already common practice with many tools today and usually takes place without any action on the part of the user and without the need to install special software. With web-based systems, encryption can be recognised by the "https" or lock symbol in the browser.

Transport encryption should always be used. Generally speaking, however, it is only a sufficient measure if the tools or portals used are also secure (and may be organisationally/contractually bound to the UOL).

For a transport-encrypted transfer of files into or out of the university infrastructure, the cloud storage service operated by the IT services themselves is a good option. Instructions can be found on the IT services pages.

If everyone involved has a UOL account, direct sharing should be used by entering the authorised names or email addresses. The recipient is then automatically notified and only needs their UOL access data so that the sender does not have to send any sensitive data (especially passwords). Information and instructions on sharing files can also be found in the IT services documentation.

To share files with external parties, they must be shared via "Share link" with the "Password protection" option. Please ensure that the password is not too simple (preferably randomly generated) and that the password is also transmitted securely. Unfortunately, sending a password by email together with the link is not a particularly good solution. It would be best if the password were transmitted via a completely different channel (e.g. in person or by telephone).

Information on security requirements regarding Transport Layer Security (TLS) can be found at the BSI, for example. For example, TLS should only be used in the current versions 1.2 and 1.3 (minimum standard of the BSI, version 2.4 of 25/05/2023, last checked for up-to-dateness on 20/12/2024). For IT services of the University of Oldenburg, it can be assumed that corresponding standards are taken into account. In the case of in-house developments or external offers, this should be checked or appropriate agreements concluded.

How do I store my research data?

The Research Data Management Service Centre recommends using the infrastructure services offered by the University of Oldenburg to store research data . These are designed to be high-performance, fail-safe and disaster-proof and the data remains on the university's own servers. These services include

• Network drives
  The personal network drive (L-drive) is available to every member of the university and access is restricted to their own university account. If access to data is required by other people, a group drive can be ordered from IT services. group drive can be requested from IT Services. This can be activated for other members of the university.
  
• Cloud storage (Nextcloud)
  Cloud storage allows you to synchronise a local directory on your computer with the university's data storage system. The advantage over using the network drive is that individual files or entire folders in the cloud storage can be shared with external persons. This makes it possible to work together on the data even if project partners do not have member status at the University of Oldenburg. The service can be accessed at cloud.uol.de/. Further information can be found on the IT services page.
  
• MySQL databases
  Depending on the type, extent and use of the research data, it may be advantageous to store the data in a database. For this you can use a MySQL database from the IT services. We will be happy to advise you if you are unsure whether this is the right storage format for your data.
  
• GitLab
  It should not be neglected that programme code also falls under the term "research data". Version management is available at gitlab.uni-oldenburg.de/ the GitLab service of the university is available.

Note on data backup and restoration
A backup is created daily for the network drives and databases, which is kept for 30 days. The restoration can be carried out for the entire network drive as well as for individual files. The cloud storage has simple version control so that when files are changed, the old versions are automatically saved for a limited time and can be restored by you. Accidentally deleted files can also be restored. You can find an overview of how long the versions can be restored here.
As the backups are kept for a limited time or are created once a day, we recommend that you create a manual copy (e.g. with a time stamp in the file name) if you make major changes to the data. This is particularly useful if several such changes are made in one day, as the automatic backup cannot restore any intermediate statuses from that day.
If you use our REDCap or SoSci-Survey service, backups of your data and files contained there are automatically created once a day. However, the following also applies here: Intermediate statuses within a day can only be reset manually. A manual backup is therefore also recommended before making major changes. Both services provide suitable functions for this. Further information on backing up and restoring can be found in the respective operating concept.

If you do not use the university's recommended services and want to store your research data locally, you should ensure adequate protection against unauthorised access (e.g. through encryption or password protection). You should also create regular backups on a physically separate storage medium that is also protected against unauthorised access.

In general, the storage of your research data should also be accompanied by the description of the data using metadata and the storage of this metadata .

The recommendations described here do not relate to long-term storage, which, according to good academic practice, should be for a period of ten years. No special service is currently available for this area. Further information can be found in the glossary article.

We would like to draw your attention to the extensive collection of FAQs and useful information on the pages of the Data Protection and Information Security Unit.

The following factsheets published by the NFDI are also recommended as a general introduction to the topic of data protection vs. FAIR data use in research:

• Consent: FAIR and data protection compliant
• Methods for FAIR and data protection-compliant handling of personal data
• Data linkage: FAIR and data protection-compliant