Branch: v2-1-blob-ciphers-key-ids

cached-config-operations

main

revert-7033-patch-1

test_dylint

v2-1-blob-ciphers-key-ids

v2-2-registration

v2-3-key-rotation

v2-4-sdk-live-tests

v2-registration

0.10.0

0.11.0

0.12.0

0.13.0

0.9.0

1.0.0

1.1.0

1.10.0

1.11.0

1.12.0

1.13.0

1.13.1

1.14

1.14.1

1.14.2

1.15.0

1.15.1

1.16.0

1.16.1

1.16.2

1.16.3

1.17.0

1.18.0

1.19.0

1.2.0

1.20.0

1.21.0

1.22.0

1.22.1

1.22.2

1.23.0

1.23.1

1.24.0

1.25.0

1.25.1

1.25.2

1.26.0

1.27.0

1.28.0

1.28.1

1.29.0

1.29.1

1.29.2

1.3.0

1.30.0

1.30.1

1.30.2

1.30.3

1.30.4

1.30.5

1.31.0

1.32.0

1.32.1

1.32.2

1.32.3

1.32.4

1.32.5

1.32.6

1.32.7

1.33.0

1.33.1

1.33.2

1.34.0

1.34.1

1.34.2

1.34.3

1.35.0

1.35.1

1.35.2

1.35.3

1.35.4

1.35.5

1.35.6

1.35.7

1.35.8

1.36.0

1.37.0

1.37.1

1.37.2

1.37.3

1.4.0

1.5.0

1.6.0

1.6.1

1.7.0

1.8.0

1.9.0

1.9.1

Branches Tags

${ item.name }

Create tag ${ searchTerm }

Create branch ${ searchTerm }

from 'v2-1-blob-ciphers-key-ids'

${ noResults }

Commit Graph

1 Commits (v2-1-blob-ciphers-key-ids)

Author	SHA1	Message	Date
Mathijs van Veluw	d297e274a3	Several SSO Fixes (#7163) * Ensure SSO token is only usable on the same client This commit adds an extra check via cookies to ensure the same browser/client is used to request and provide the SSO token. Previously it would be able to provide a custom link which attackers could use to steal data. While an attacker would still need the Master Password to be able to decrypt or execute specific actions, they were able to fetch encrypted data. Solved with some help of Claude Code. Signed-off-by: BlackDex <black.dex@gmail.com> * Check email-verified on SSO login/create This commit prevents possible account takeover via SSO which doesn't check/validate or provide validated status of the email. It was checked at other locations, but was skipped here. Signed-off-by: BlackDex <black.dex@gmail.com> * Prevent data disclosure via SSO endpoints This commit prevents some data disclosure and user enumeration by only returning the fake SSO identifier. Since we do not check the identifier anywhere useful, returning the fake one is just fine. During an invite to an org, that link contains the correct UUID and will be used for the master password requirements. For anything else, server admins should set the `SSO_MASTER_PASSWORD_POLICY` env variable. Signed-off-by: BlackDex <black.dex@gmail.com> * Adjust admin layout to fix issues when SSO is enabled Signed-off-by: BlackDex <black.dex@gmail.com> --------- Signed-off-by: BlackDex <black.dex@gmail.com>	5 months ago