diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-07-20 18:40:28 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-07-20 18:40:28 +0300 |
commit | b595cb0c1dec83de5bdee18284abe86614bed33b (patch) | |
tree | 8c3d4540f193c5ff98019352f554e921b3a41a72 /doc/security | |
parent | 2f9104a328fc8a4bddeaa4627b595166d24671d0 (diff) |
Add latest changes from gitlab-org/gitlab@15-2-stable-eev15.2.0-rc42
Diffstat (limited to 'doc/security')
-rw-r--r-- | doc/security/password_storage.md | 22 | ||||
-rw-r--r-- | doc/security/rate_limits.md | 1 | ||||
-rw-r--r-- | doc/security/ssh_keys_restrictions.md | 10 | ||||
-rw-r--r-- | doc/security/two_factor_authentication.md | 54 |
4 files changed, 59 insertions, 28 deletions
diff --git a/doc/security/password_storage.md b/doc/security/password_storage.md index b4c2e27c952..d3db8cbe4f6 100644 --- a/doc/security/password_storage.md +++ b/doc/security/password_storage.md @@ -7,18 +7,32 @@ type: reference # Password storage **(FREE)** +> PBKDF2 and SHA512 [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360658) in GitLab 15.2 [with flags](../administration/feature_flags.md) named `pbkdf2_password_encryption` and `pbkdf2_password_encryption_write`. Disabled by default. + GitLab stores user passwords in a hashed format to prevent passwords from being stored as plain text. GitLab uses the [Devise](https://github.com/heartcombo/devise) authentication library to hash user passwords. Created password hashes have these attributes: -- **Hashing**: The [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing - function is used to generate the hash of the provided password. This is a - strong, industry-standard cryptographic hashing function. +- **Hashing**: + - **BCrypt**: By default, the [`bcrypt`](https://en.wikipedia.org/wiki/Bcrypt) hashing + function is used to generate the hash of the provided password. This is a + strong, industry-standard cryptographic hashing function. + - **PBKDF2 and SHA512**: Starting in GitLab 15.2, PBKDF2 and SHA512 are supported + behind the following feature flags (disabled by default): + - `pbkdf2_password_encryption` - Enables reading and comparison of PBKDF2 + SHA512 + hashed passwords and supports fallback for BCrypt hashed passwords. + - `pbkdf2_password_encryption_write` - Enables new passwords to be saved + using PBKDF2 and SHA512, and existing BCrypt passwords to be migrated when users sign in. + + FLAG: + On self-managed GitLab, by default this feature is not available. To make it available, + ask an administrator to [enable the feature flags](../administration/feature_flags.md) named `pbkdf2_password_encryption` and `pbkdf2_password_encryption_write`. + - **Stretching**: Password hashes are [stretched](https://en.wikipedia.org/wiki/Key_stretching) to harden against brute-force attacks. By default, GitLab uses a stretching - factor of 10. + factor of 10 for BCrypt and 20,000 for PBKDF2 + SHA512. - **Salting**: A [cryptographic salt](https://en.wikipedia.org/wiki/Salt_(cryptography)) is added to each password to harden against pre-computed hash and dictionary attacks. To increase security, each salt is randomly generated for each diff --git a/doc/security/rate_limits.md b/doc/security/rate_limits.md index 695a0d52af6..e48a9999a06 100644 --- a/doc/security/rate_limits.md +++ b/doc/security/rate_limits.md @@ -43,6 +43,7 @@ You can set these rate limits in the Admin Area of your instance: - [Deprecated API rate limits](../user/admin_area/settings/deprecated_api_rate_limits.md) - [GitLab Pages rate limits](../administration/pages/index.md#rate-limits) - [Pipeline rate limits](../user/admin_area/settings/rate_limit_on_pipelines_creation.md) +- [Incident management rate limits](../user/admin_area/settings/incident_management_rate_limits.md) You can set these rate limits using the Rails console: diff --git a/doc/security/ssh_keys_restrictions.md b/doc/security/ssh_keys_restrictions.md index eb92694d236..eca52c41e4f 100644 --- a/doc/security/ssh_keys_restrictions.md +++ b/doc/security/ssh_keys_restrictions.md @@ -48,14 +48,10 @@ By default, the GitLab.com and self-managed settings for the - ECDSA_SK SSH keys are allowed (GitLab 14.8 and later). - ED25519_SK SSH keys are allowed (GitLab 14.8 and later). -### Block banned or compromised keys **(FREE)** +## Block banned or compromised keys **(FREE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24614) in GitLab 15.1 [with a flag](../administration/feature_flags.md) named `ssh_banned_key`. Enabled by default. - -FLAG: -On self-managed GitLab, by default this feature is available. To hide the feature per user, -ask an administrator to [disable the feature flag](../administration/feature_flags.md) named `ssh_banned_key`. -On GitLab.com, this feature is available. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/24614) in GitLab 15.1 [with a flag](../administration/feature_flags.md) named `ssh_banned_key`. Enabled by default. +> - Generally available in GitLab 15.2. [Feature flag `ssh_banned_key`](https://gitlab.com/gitlab-org/gitlab/-/issues/363410) removed. When users attempt to [add a new SSH key](../user/ssh.md#add-an-ssh-key-to-your-gitlab-account) to GitLab accounts, the key is checked against a list of SSH keys which are known diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md index ae13881fe6f..5907860f5cc 100644 --- a/doc/security/two_factor_authentication.md +++ b/doc/security/two_factor_authentication.md @@ -5,7 +5,7 @@ group: Authentication and Authorization info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments --- -# Enforce two-factor authentication **(FREE SELF)** +# Enforce two-factor authentication **(FREE)** Two-factor authentication (2FA) provides an additional level of security to your users' GitLab account. When enabled, users are prompted for a code generated by an application in @@ -13,7 +13,7 @@ addition to supplying their username and password to sign in. Read more about [two-factor authentication (2FA)](../user/profile/account/two_factor_authentication.md) -## Enforce 2FA for all users +## Enforce 2FA for all users **(FREE SELF)** Users on GitLab can enable it without any administrator's intervention. If you want to enforce everyone to set up 2FA, you can choose from two different ways: @@ -33,7 +33,7 @@ To enable 2FA for all users: If you want 2FA enforcement to take effect during the next sign-in attempt, change the grace period to `0`. -## Disable 2FA enforcement through Rails console +### Disable 2FA enforcement through Rails console Using the [Rails console](../administration/operations/rails_console.md), enforcing 2FA for all user can be disabled. Connect to the Rails console and run: @@ -46,19 +46,22 @@ Gitlab::CurrentSettings.update!('require_two_factor_authentication': false) > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) in GitLab 12.0, 2FA settings for a group are also applied to subgroups. -To enforce 2FA only for certain groups: +Prerequisites: + +- You must have the Maintainer or Owner role for the group. -1. Go to the group's **Settings > General** page. -1. Expand the **Permissions and group features** section. -1. Select the **Require all users in this group to set up two-factor authentication** option. +To enforce 2FA only for certain groups: -You can also specify a grace period in the **Time before enforced** option. +1. On the top bar, select **Menu > Groups** and find your group. +1. On the left sidebar, select **Settings > General**. +1. Expand **Permissions and group features**. +1. Select **All users in this group must set up two-factor authentication**. +1. Select **Save changes**. -To change this setting, you must be an administrator or owner of the group. +You can also specify a grace period in the **Delay 2FA enforcement** option. If you want to enforce 2FA only for certain groups, you can enable it in the -group settings and specify a grace period as above. To change this setting you -must be administrator or owner of the group. +group settings and specify a grace period as above. The following are important notes about 2FA: @@ -80,15 +83,36 @@ The following are important notes about 2FA: 1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action causes all subgroups with 2FA requirements to stop requiring that from their members. +- Access tokens are not required to provide a second factor for authentication because they are API-based. + Tokens generated before 2FA is enforced remain valid. -## Disable 2FA for everyone +## Disable 2FA **(FREE SELF)** WARNING: -Disabling 2FA for everyone does not disable the [enforce 2FA for all users](#enforce-2fa-for-all-users) +Disabling 2FA for users does not disable the [enforce 2FA for all users](#enforce-2fa-for-all-users) or [enforce 2FA for all users in a group](#enforce-2fa-for-all-users-in-a-group) settings. You must also disable any enforced 2FA settings so users aren't asked to set up 2FA again when they next sign in to GitLab. +WARNING: +This is a permanent and irreversible action. Users must reactivate 2FA to use it again. + +### For a single user + +To disable 2FA for non-administrator users, we recommend using the [API endpoint](../api/users.md#disable-two-factor-authentication) +instead of the Rails console. +Using the [Rails console](../administration/operations/rails_console.md), 2FA for a single user can be disabled. +Connect to the Rails console and run: + +```ruby +admin = User.find_by_username('<USERNAME>') +user_to_disable = User.find_by_username('<USERNAME>') + +TwoFactor::DestroyService.new(admin, user: user_to_disable).execute +``` + +### For all users + There may be some special situations where you want to disable 2FA for everyone even when forced 2FA is disabled. There is a Rake task for that: @@ -100,10 +124,6 @@ sudo gitlab-rake gitlab:two_factor:disable_for_all_users sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production ``` -WARNING: -This is a permanent and irreversible action. Users have to -reactivate 2FA from scratch if they want to use it again. - ## 2FA for Git over SSH operations **(PREMIUM)** > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7. |