Zum Inhalt

Access Data Management

In LOGINventory it is possible to store access data in encrypted form and (optionally) assign them to assets.

Security and Encryption

The access data stored in LOGINventory are encrypted and decrypted by means of a Master Password. For this purpose the user has to define a master password whose password strength is at least "medium". This is the case if at least 2 of the following points are fulfilled:

  • The password is longer than 6 letters
  • The password contains upper and lower case letters
  • The password contains one digit
  • The password contains a special character ~,@,#,$,%,^,&,*,:,;


If the master password is lost or forgotten, there is no mechanism to recover the forgotten master password or passwords. Therefore it is very important that you remember the master password. It is not possible to recover the password!

The hash of the master password is generated with a cryptographically strong sequence of random values from RNGCryptoServiceProvider (Salt) via a derived key generation (10000 iterations) using (PBKDF2 -> Rfc2898DeriveBytes SHA-256) and persisted in the database.

When creating, viewing or editing the encrypted information, the master password must first be entered. This password is then valid for the entire session (= as long as the LOGINventory program is not closed), so that the password does not have to be entered again for each action. This also means that you should always close LOGINventory if you want to make sure that no other user with access to your computer can view or edit the data.

To change the master password, the user has to

  • have the LOGINventory role "Administrator" (if roles have been assigned)
  • enter the old master password
  • enter the new master password twice

If you have proven to be authorized (by entering the master password), you can store access data and link them to assets.

Deposited passwords are synchronously encrypted using the MD5 hash of the master password (salt) via a derived key generation (10000 iterations) (PBKDF2 -> Rfc2898DeriveBytes SHA-256) of this salt via RijndaelManaged algorithm and persisted in the database.


The security mechanisms used do not provide protection against keyloggers or memory dumps. If you fear to become a victim of such an attack, please take additional security measures.

Storing Access Data

To store access data you can either

  • navigate to the node Access Data and select New Access Data from the ribbon menu
  • or in a query for the entity Device (e.g. Assets node, Windows Clients query, etc.), select an asset and then choose Show Access Data from the ribbon menu. New credentials can then also be stored here.

In the window that opens, various details can then be stored, including name, user name, password, URL, category, comment and expiry date.

In the line with the password input you can select whether the password should be displayed in plain text or in asterisks, and it is also possible to generate a secure password here.

Besides entering the (optional) expiration date of a password, the date can also be quickly edited in the drop-down menu.

Of course, credentials can also be assigned to multiple assets. For these assets, the linked credentials can then be accessed via Show Access Data in the ribbon menu.

Both from this view and from the Access Data node, the password and user name can be copied to the clipboard.


Passwords & user accounts copied to the clipboard are automatically deleted from the clipboard after 20 seconds.


If you have created a lot of different credentials, it might be useful to sort them by category. This is possible, for example, by creating filtered queries for the category. If necessary, you could also assign your own icons for these queries.