Account and sign-in security

Under Administration → Account (app.xicbot.de/konto) you protect your own access: change the password, set up a second step with a code or a security key, end sign-ins on other devices and review recent sign-in attempts. The page is open to every role and only concerns the person who is signed in, not the rest of the team. How sign-in itself works is described in Sign-in and access.

Page layout

The page is headed Account, followed by the line “Two-step verification, signed-in devices and the most recent sign-ins to this account.” These cards follow in this order:

Messages from the Two-factor authentication, Security keys and Signed-in devices cards appear as a banner above the first card; Change password shows its messages inside its own card. While Security keys, Signed-in devices and Recent sign-ins load, they show “Loading …”, and an empty list shows “No entries yet.” Each of the three lists loads on its own. If one fails, its card shows “The list could not be loaded.” with the reason, for example “The service is not responding right now.”, and the Load again button; the other cards still show their lists. A new security key can only be added once the list of keys has loaded.

Account name

The Account name card shows the company or project name from sign-up. It appears in the account switcher and in invitation emails. The owner changes it in the Company or project field with Save name; afterwards “The account name has been saved.” appears, and the header and the account switcher show the new name. The name is required and has at most 160 characters. All other roles see the name with the sentence “The account name is changed by the owner.”; during a support session it reads “The account name cannot be changed during a support session.” The change is recorded in the Audit log with the old and the new name.

Notifications

• Weekly report by email: the owner turns it on or off with Receive the weekly report, as on the Analytics page; the report goes to the owner's confirmed address. Other roles see whether it is ordered. If the state cannot be loaded, “The list could not be loaded.” appears with the Load again button.
• Handovers to a person: the address for these is set per assistant in the Handover address field; without an address no email is sent. The card links to Assistants.
• Security emails: always on. When the password, the second step, a security key, the recovery codes or the sign-in address changes, an email goes to your address; they cannot be unsubscribed.

Change password

The card explains: “Your current password confirms that it is you. Saving ends all other sessions of this account; this one stays signed in.”

1. 1

   Step 1

   Fill in the fields

   Enter your current password and the new one twice.

2. 2

   Step 2

   Save

   Choose Save password. While sending, the button shows “Sending …”. If a field is empty or the two new passwords differ, the page sends nothing and marks the fields.

3. 3

   Step 3

   Confirmation

   The card reports “Your password has been changed. All other sessions have been ended.” and clears the three fields. The ended sign-ins disappear from Signed-in devices without reloading.

What happens when you save

• The new password applies at once. All your other sign-ins end; this device and an ongoing takeover by the operator stay signed in.
• The account’s API keys are not sign-ins and remain valid. They are managed under API keys and webhooks.
• An email “Your password was changed” goes to your email address in the language set for your user, or in German if none is set. A sign-in through the sign-in page sets this language to the one chosen on that device; if none has been chosen there, it stays. The EN/DE language button of the application changes it as well, except during a takeover by the operator. Under Account it names your address, under Time the date and time in German time, and it says whether other sessions were ended. If a takeover by the operator is running, the email names it as ongoing support access and says how it ends: when it expires, or earlier under Signed-in devices or by resetting your password.
• The email warns: “Was this not you? Reset your password right away. This ends all sessions of the account, including the one the change was made from.” The Reset password button leads to the page where you request a link for a new password. If it was you, there is nothing else to do.
• If the email cannot be sent, the change is still saved.
• The audit log usually records “Password changed”. If this entry cannot be written, the new password still applies.

Password change messages

With every message at a field, the card also shows “Please check the marked fields.”

Two-factor authentication

The card explains: “After the password, sign-in also asks for a code from an authenticator app or for a security key. A stolen password alone is then not enough.” You set up the code in this card and keys in the Security keys card. Both methods can be used side by side.

Set up a code

1. 1

   Step 1

   Set up

   Choose Set up. The card shows the secret, a string of 32 characters from A to Z and 2 to 7, together with the hint “Enter this value in your authenticator app and confirm with the code it shows.”

2. 2

   Step 2

   Transfer the secret

   Copy to clipboard copies the value, and the button then shows Copied. If that is not possible, the card shows “The clipboard is not available here. Select the value and copy it manually.”; one click into the value selects all of it. The page shows no QR code, so enter the value in the app yourself. If the app asks for settings: time-based, 6 digits, 30 seconds, SHA1.

3. 3

   Step 3

   Confirm

   Enter the current code from the app in Six-digit code and choose Confirm. The page reports “Two-factor authentication is active.” and hides the secret.

• The server accepts the code for the current 30-second step and one step before and after it; spaces in the code are removed. A phone clock that is slightly off therefore does no harm.
• Before confirmation the code has no effect, and sign-in does not ask for it yet.
• The secret is shown only until you confirm. After a reload the card shows Set up again; setting up again creates a new secret, and the previous one no longer applies.
• Existing sign-ins stay open when you set up the code. You can end them under Signed-in devices.
• A wrong or outdated code results in “That code is not correct. Please try again.”
• If two-factor authentication is already active when you click Set up, for example after setting it up in a second window, the page reports “Two-factor authentication is already active.” and shows the current state. If there is no setup in progress any more when you confirm, it reports “There is no setup in progress. Please start again with “Set up”.” and the card shows Set up again.
• The audit log records “Two-factor enabled”.

Turn off the code

If the code is active, enter your password under Password in the card and choose Turn off. The second step cannot be removed without the password, so an unattended computer is not enough to do it. The secret is deleted; setting up again later starts with a new one. A wrong password results in “That password is not correct.” The audit log records “Two-factor disabled”.

Security keys

A security key complements the password; it does not replace it. Sign-in checks the password first and then asks for confirmation on the key. If the browser cannot use security keys, the card shows “This browser cannot use security keys.” instead of the form.

Add a key

1. 1

   Step 1

   Name the key

   Under Name of the key, enter a label you will recognise later. The field is required and takes up to 80 characters.

2. 2

   Step 2

   Add

   Choose Add key. The browser asks for the key; by default you have 120 seconds. The key stores the sign-in under XICBOT and your email address.

3. 3

   Step 3

   Confirmation

   Once you confirm on the key, the page reports “The security key is set up.” and the key appears in the list.

• Enter the name before clicking. If the field is empty, the page shows “Name of the key is required.” at the field, and the browser does not ask for the key at all.
• By default, you can store up to 10 keys.
• The browser does not offer keys you have already stored; each key appears in the list only once.
• The audit log records “Security key added”.

Remove stored keys

Without keys, the card shows “No security key is set up for this account.”, but only once the list has loaded. Otherwise the list shows each key with its name, “Added: …” and “Last used: …”, oldest first. “Last used” shows “-” until the key has been used to sign in.

1. 1

   Step 1

   Enter your password

   Enter your password under Password above the list. Below it the card says “To remove a key, first enter your password.”

2. 2

   Step 2

   Remove

   Choose Remove in the key’s row. There is no confirmation prompt. The page reports “The security key has been removed.” and the audit log records “Security key removed”.

Security key messages

Two-factor authentication at sign-in

If a code is active or a key is stored, sign-in continues after the password: with the Six-digit code field, with the Sign in with a security key button, or with both, depending on what is set up. This step allows 10 minutes and 5 attempts, and it only succeeds from the same network address the password came from. More on the process is in Sign-in and access.

Signed-in devices

The card explains: “Each row is a signed-in browser. End any session you do not recognise.” It shows up to 50 open sign-ins, the most recently used first. A sign-in is valid for 30 days, and expired ones no longer appear.

• End in a row ends exactly that sign-in, including a takeover by the operator. The page confirms this with “The session has been ended.”, and an earlier error message disappears. The audit log usually records “Session ended”, or “Takeover by the operator ended” for a takeover. If the sign-in no longer exists because it has already been ended, has expired or was signed out in another window, the page reloads its lists and reports “This entry no longer exists. The list has been reloaded.” If the reload fails as well, “This entry no longer exists. Reload the page to see the current state.” appears instead; the list itself names the reason the loading failed with “The list could not be loaded.” and the Load again button.
• End all others appears as soon as more than one other sign-in is open; takeovers do not count. The prompt reads “End all other sessions? This device stays signed in.” with the note “An ongoing takeover by the operator and your account API keys are exempt.” Cancel closes it without effect. After you confirm, the page reports “All other sessions have been ended.”, and here too an earlier error message disappears. The audit log usually records “All other sessions ended”.
• From within a takeover, that is in the operator’s view, the card shows neither End nor End all others. In place of the explanation, it states that the sessions of this account cannot be ended during a takeover and that the takeover itself is ended with End takeover. The API still rejects both calls from within a takeover with 403 and in_impersonation; if such a call is made anyway, the page reports “This area is locked during an impersonation session.”
• The device of an ended sign-in has to sign in again on its next request.
• Sign-ins also end after 30 days, with Sign out, when the password is changed and when it is reset; more under Sign-in and access.

Takeover by the operator

• For a takeover, the operator creates a separate sign-in with a time limit for one user of your account. Your password is neither read nor set in the process.
• The user with the highest role is taken over, in the order Owner, Administration, Edit, Read; among users with the same role, the one created first.
• From within a takeover, changing the password, setting up and turning off the code, adding and removing security keys and ending your sign-ins, one at a time or with End all others, are blocked. The API answers these requests with 403 and in_impersonation.
• The start and end of a takeover are recorded in two places. The operator records them in a separate log of its own, the start with the time, the user taken over, the expiry time and, if one was given, the reason. This log is separate from your account's Audit log; how long it is kept is described under Retention and deletion. Your account's Audit log additionally shows “Takeover by the operator started” and “Takeover by the operator ended”. Both usually record the end when the operator ends the takeover or signs out of it, when you end it under Signed-in devices, and when it ends together with all sign-ins of the user taken over, that is when the password is reset via the link, when the operator resets the second step and when the user is removed from the team. Both also usually record the end when the user taken over switches to another account themselves; it then appears in the log of the account where the takeover began. The end is recorded only once per takeover, even if you and the operator end it at the same time. If a takeover expires on its own after 4 hours, no end entry is created.
• Changes made during a takeover appear in your account's Audit log like any other change, under the email address of the user taken over. Whether a takeover is running is shown in the list above as “Takeover by the operator”.

Recent sign-ins

The table shows the 50 most recent sign-in attempts to your account, successful and failed, newest first. The columns are Time, Result and Who. Who names browser and system by the same rules as Signed-in devices, and hovering shows the full identifier. The table does not show location or IP address.

Audit log entries

Signing in, signing out and every change on this page leave an entry in the account’s Audit log. Only the Administration and Owner roles can see the Audit log; for other roles the item is missing from the sidebar and the API does not return it to them. If you have another role and spot an unfamiliar entry under Recent sign-ins, contact someone with one of these roles. Turning the code on or off and adding or removing a security key only take effect together with their entry: if the entry cannot be written, nothing changes, and the page reports “Not saved: the entry in the audit log could not be written. Please try again.” Signing in, signing out, setting a password and ending sign-ins, on the other hand, still take effect if their entry fails. See Team and roles for more.

Via the API

The same actions are available under /api/v1/. They require the token of a sign-in in the header Authorization: Bearer …; an API key of the account is not sufficient. Details are in API authentication, API: account and API limits.

Frequent questions