forked from mdn/content
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'upstream/main' into add-credential-types
* upstream/main: (55 commits) Replace `.` with `#` in example given selectors are `#ids` (mdn#33791) update info in cross browser testing strategies (mdn#33730) Clarify that `navigator.storage.persist()` depends on heuristics (mdn#33780) fix typo (mdn#33785) feat: improvements on Glossary/Hoisting (mdn#33787) CSS update: overview of shapes guide (mdn#33771) CSS update: Shapes from box values (mdn#33770) Fix issue 033506: correct droppedEntriesCount (mdn#33538) Revert "=== Symbol("foo")" (mdn#33782) docs(css): FF126 - Support for `shape()` function (mdn#33446) Bump lint-staged from 15.2.4 to 15.2.5 (mdn#33777) Bump ajv from 8.13.0 to 8.14.0 (mdn#33776) Add missing spaces for `subtlecrypto` (mdn#33774) fix: typo in `color_and_luminca` (mdn#33775) feat: improvments on gutters (mdn#33751) FF127Relnote- data: and javascript: URLS forbidden in base HREF (mdn#33738) update the content of SVG `<view>` element (mdn#33710) Clipboard.write() - log and fixes (mdn#33769) updated ClipboardItem and Clipboard documentation and examples using … (mdn#33262) Fix error in the code snippet for Symbol (mdn#33765) ...
- Loading branch information
Showing
141 changed files
with
1,939 additions
and
476 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,29 @@ | ||
| --- | ||
| title: Digital signature | ||
| slug: Glossary/Digital_signature | ||
| page-type: glossary-definition | ||
| --- | ||
|
|
||
| {{GlossarySidebar}} | ||
|
|
||
| A **digital signature** is an object that can be used to {{glossary("authentication", "authenticate")}} the author of a document or message. | ||
|
|
||
| Digital signatures are usually based on {{glossary("public-key cryptography")}}, in which a key is created as a pair of keys, with the property that, if some input is encrypted with one key, it can only be decrypted with the other key, and vice versa. | ||
|
|
||
| The creator of the key pair makes one of the keys public and keeps the other one private. To sign a document, the key pair's owner creates a {{glossary("hash")}} of the document and encrypts it with the private key. | ||
|
|
||
| The document and signature are sent to the verifier, who hashes the document, retrieves the public key, and decrypts the signature: if this matches the hash, then the signature has been verified, and the verifier can be confident that it was created by an entity with access to the private key. | ||
|
|
||
| The security of a digital signature system depends (among other things) on: | ||
|
|
||
| - The private key's owner keeping it safe: if other entities can access the private key, they can impersonate the owner. | ||
|
|
||
| - The public key used by the verifier being the genuine counterpart of the owner's private key: if an attacker could trick the verifier into trusting the wrong public key, they could impersonate the owner. | ||
|
|
||
| Verifiers often use {{glossary("digital certificate", "digital certificates")}} to check that public keys are genuine. | ||
|
|
||
| ## See also | ||
|
|
||
| - {{glossary("Digital certificate")}} | ||
| - {{glossary("Hash")}} | ||
| - {{glossary("Public-key cryptography")}} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| --- | ||
| title: Federated identity | ||
| slug: Glossary/Federated_identity | ||
| page-type: glossary-definition | ||
| --- | ||
|
|
||
| {{GlossarySidebar}} | ||
|
|
||
| A **federated identity** system is one in which an {{glossary("identity provider", "identity provider (IdP)")}} acts as an intermediary between users and {{glossary("relying party", "relying parties")}}, enabling a user to use a single set of {{glossary("credential", "credentials")}} to authenticate with a number of different relying parties. | ||
|
|
||
| Traditionally, on the web, a user will sign into a website with a username and a password, and the password is verified by the website against a (properly {{glossary("hash", "hashed")}} and {{glossary("salt", "salted")}}) copy stored on the website's backend. | ||
|
|
||
| In this model, if users have multiple accounts with different websites, they have to remember many passwords, and this encourages bad password practices such as using the same password for multiple accounts. | ||
|
|
||
| In a federated identity system, an identity provider: | ||
|
|
||
| - manages a user's credentials and can authenticate users | ||
| - is trusted by multiple websites to make assertions about a user's identity. | ||
|
|
||
| A user can then authenticate with the identity provider, which will return a token to the user's browser if authentication is successful. The user's browser will send the token to the website, which can verify that it was issued by the IdP. If the verification succeeds, the website can sign the user in. | ||
|
|
||
| Federated identity is often provided as a service by corporations: for example, users who have Google, Microsoft, or Facebook accounts can use them to sign in to many websites. Websites typically have to implement a process for verifying tokens that is specific to an identity provider. However, open standards such as [OpenID](https://en.wikipedia.org/wiki/OpenID), [OAuth](https://en.wikipedia.org/wiki/OAuth), and [SAML](https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language) are widely used in the implementation of federated identity systems. | ||
|
|
||
| Although federated identity makes logging into multiple different accounts much easier for users and can greatly improve security, it can have serious implications for a user's privacy. If not carefully designed, a federated identity system can allow identity providers to track users across the web as they sign into multiple different sites. Early federated identity systems on the web were built on technologies such as third-party cookies, which are intrinsically privacy-invasive. As these technologies are being deprecated by browsers, new approaches are needed. The [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API) provides a standardized privacy-preserving mechanism for federated identity on the web. | ||
|
|
||
| ## See also | ||
|
|
||
| - {{glossary("Relying party")}} | ||
| - {{glossary("Identity provider")}} | ||
| - [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,19 @@ | ||
| --- | ||
| title: Identity provider (IdP) | ||
| slug: Glossary/Identity_provider | ||
| page-type: glossary-definition | ||
| --- | ||
|
|
||
| {{GlossarySidebar}} | ||
|
|
||
| An **identity provider** (IdP) is an entity in a {{glossary("federated identity")}} system that manages a user's {{glossary("credential", "credentials")}} and can {{glossary("authentication", "authenticate")}} users. | ||
|
|
||
| In federated identity systems, {{glossary("relying party", "relying parties")}}, that need to control access to a resource (for example, a website deciding whether to sign a user in) outsource the act of authenticating users to a third party, which they trust to make authentication decisions. These third parties are called identity providers. | ||
|
|
||
| Examples of identity providers on the web include Google, Microsoft, and Facebook. This enables websites to allow users to sign in using the user's Google, Microsoft, or Facebook account. | ||
|
|
||
| ## See also | ||
|
|
||
| - {{glossary("Federated identity")}} | ||
| - {{glossary("Relying party")}} | ||
| - [Federated Credential Management (FedCM) API](/en-US/docs/Web/API/FedCM_API) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| --- | ||
| title: Relying party | ||
| slug: Glossary/Relying_party | ||
| page-type: glossary-definition | ||
| --- | ||
|
|
||
| {{GlossarySidebar}} | ||
|
|
||
| A **relying party** is an entity that needs to control access to a resource and, to do so, needs to {{glossary("authentication", "authenticate")}} other entities that are trying to access that resource. On the web, a relying party is usually a website that allows users to sign in and needs to authenticate users (for example by checking a password) before deciding whether to grant them access. | ||
|
|
||
| The website _relies on_ the validity of the credentials the browser presents when it grants access to its resources. | ||
|
|
||
| ## See also | ||
|
|
||
| - {{glossary("Federated identity")}} | ||
| - {{glossary("Identity provider")}} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,25 @@ | ||
| --- | ||
| title: Salt | ||
| slug: Glossary/Salt | ||
| page-type: glossary-definition | ||
| --- | ||
|
|
||
| {{GlossarySidebar}} | ||
|
|
||
| In cryptography, **salt** is random data added to a password before it is {{glossary("hash", "hashed")}}. This makes it impossible for an attacker to derive passwords from their hashes using precomputed tables of passwords and the corresponding hashes. | ||
|
|
||
| Passwords should never be stored in their plaintext form, because of the risk that an attacker might break into the database where they are stored. Typically, the password is hashed, and the resulting hash is stored. If the hash function is cryptographically secure, then even if an attacker can get access to the stored hashes, it is impractical for them to reverse the function. | ||
|
|
||
| To derive a password from a hash, attackers can look up the password corresponding to a hash in a precomputed table (also known as a [rainbow table](https://en.wikipedia.org/wiki/Rainbow_table)) mapping possible passwords to their hashes: | ||
|
|
||
| | Password | Hash | | ||
| | -------- | ----------- | | ||
| | pa55w0rd | 56965E2A... | | ||
| | abcdef | BEF57EC7... | | ||
| | letmein | 1C8BFE8F... | | ||
|
|
||
| Although these tables may be very large, such attacks can be effective because table lookup is a fast operation. | ||
|
|
||
| Adding random salt to passwords before hashing them stops this attack from working because the hash is not calculated based on the password alone but on the password combined with the salt. | ||
|
|
||
| Unlike the password, the salt does not need to be kept secret: it can be stored alongside the salted and hashed password in the server's database. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.