Merge pull request #174 from mdn/lex111/ru-typos

Fix typos in Russian translation

1 files changed, 2 insertions, 2 deletions

diff --git a/files/ru/web/api/web_authentication_api/index.html b/files/ru/web/api/web_authentication_api/index.html
index 19162bf4f9..d7951c18d6 100644
--- a/files/ru/web/api/web_authentication_api/index.html
+++ b/files/ru/web/api/web_authentication_api/index.html
@@ -9,7 +9,7 @@ translation_of: Web/API/Web_Authentication_API
 
 <h2 id="Принципы_и_использование_веб-аутентификации">Принципы и использование веб-аутентификации</h2>
 
-<p>API Web Authentication (также называемое WebAuthn) использует {{interwiki("wikipedia", "Public-key_cryptography", "ассметричную криптографию (систему с открытым ключом)")}} вместо паролей или SMS-сообщений для регистрации, входа и {{interwiki("wikipedia", "Multi-factor_authentication", "двухфакторной аутентификации")}} на веб-сайтах. Это устраняет многие значительные проблемы безопасности, такие как {{interwiki("wikipedia", "Phishing", "фишинг")}}, {{interwiki("wikipedia", "Data_breach", "утечки данных")}} и атаки на SMS или иные методы двухфакторной аутентификации, при этом сильно упрощая использование, т.к. пользователям не нужно запоминать десятки сложных паролей.</p>
+<p>API Web Authentication (также называемое WebAuthn) использует {{interwiki("wikipedia", "Public-key_cryptography", "ассиметричную криптографию (систему с открытым ключом)")}} вместо паролей или SMS-сообщений для регистрации, входа и {{interwiki("wikipedia", "Multi-factor_authentication", "двухфакторной аутентификации")}} на веб-сайтах. Это устраняет многие значительные проблемы безопасности, такие как {{interwiki("wikipedia", "Phishing", "фишинг")}}, {{interwiki("wikipedia", "Data_breach", "утечки данных")}} и атаки на SMS или иные методы двухфакторной аутентификации, при этом сильно упрощая использование, т.к. пользователям не нужно запоминать десятки сложных паролей.</p>
 
 <p>На многих сайтах уже есть страницы для регистрации и входа в существующие учетные записи, и Web Authentication API может быть как заменой, так и дополнением для них. Как и остальные виды <a href="/en-US/docs/Web/API/Credential_Management_API">Credential Management API</a>, Web Authentication API содержит два базовых метода: для регистрации и для входа:</p>
 
@@ -42,7 +42,7 @@ translation_of: Web/API/Web_Authentication_API
 <ol start="0">
  <li><strong>Приложение запрашивает регистрацию</strong> - The application makes the initial registration request. The protocol and format of this request is outside of the scope of the Web Authentication API.</li>
  <li><strong>Server Sends Challenge, User Info, and Relying Party Info</strong> - The server sends a challenge, user information, and relying party information to the JavaScript program. The protocol for communicating with the server is not specified and is outside of the scope of the Web Authentication API. Typically, server communications would be <a href="/en-US/docs/Glossary/REST">REST</a> over https (probably using <a href="/en-US/docs/User:maybe/webidl_mdn/XMLHttpRequest_API">XMLHttpRequest</a> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a>), but they could also be <a href="/en-US/docs/Glossary/SOAP">SOAP</a>, <a href="https://tools.ietf.org/html/rfc2549">RFC 2549</a> or nearly any other protocol provided that the protocol is secure. The parameters received from the server will be passed to the <a href="/en-US/docs/Web/API/CredentialsContainer/create">create()</a> call, typically with little or no modification and returns a <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promise</a> that will resolve to a {{domxref("PublicKeyCredential")}} containing an {{domxref("AuthenticatorAttestationResponse")}}. <strong>Note that it is absolutely critical that the challenge be a buffer of random information (at least 16 bytes) and it MUST be generated on the server in order to ensure the security of the registration process.</strong></li>
- <li><strong>Браузер вызвает authenticatorMakeCredential() для аутентификатора</strong> - Internally, the browser will validate the parameters and fill in any defaults, which become the {{domxref("AuthenticatorResponse.clientDataJSON")}}. One of the most important parameters is the origin, which is recorded as part of the clientData so that the origin can be verified by the server later. The parameters to the create() call are passed to the authenticator, along with a SHA-256 hash of the clientDataJSON (only a hash is sent because the link to the authenticator may be a low-bandwidth NFC or Bluetooth link and the authenticator is just going to sign over the hash to ensure that it isn't tampered with).</li>
+ <li><strong>Браузер вызывает authenticatorMakeCredential() для аутентификатора</strong> - Internally, the browser will validate the parameters and fill in any defaults, which become the {{domxref("AuthenticatorResponse.clientDataJSON")}}. One of the most important parameters is the origin, which is recorded as part of the clientData so that the origin can be verified by the server later. The parameters to the create() call are passed to the authenticator, along with a SHA-256 hash of the clientDataJSON (only a hash is sent because the link to the authenticator may be a low-bandwidth NFC or Bluetooth link and the authenticator is just going to sign over the hash to ensure that it isn't tampered with).</li>
  <li><strong>Аутентификатор создает новую пару ключей и Attestation</strong> - Before doing anything, the authenticator will typically ask for some form of user verification. This could be entering a PIN, using a fingerprint, doing an iris scan, etc. to prove that the user is present and consenting to the registration. After the user verification, the authenticator will create a new asymmetric key pair and safely store the private key for future reference. The public key will become part of the attestation, which the authenticator will sign over with a private key that was burned into the authenticator during its manufacturing process and that has a certificate chain that can be validated back to a root of trust.</li>
  <li><strong>Аутентификатор передает информацию в браузер</strong> - The new public key, a globally unique credential id, and other attestation data are returned to the browser where they become the attestationObject.</li>
  <li><strong>Браузер создаёт итоговый набор данных, приложение отвечает серверу</strong> - The create() Promise resolves to an {{domxref("PublicKeyCredential")}}, which has a {{domxref("PublicKeyCredential.rawId")}} that is the globally unique credential id along with a response that is the {{domxref("AuthenticatorAttestationResponse")}} containing the {{domxref("AuthenticatorResponse.clientDataJSON")}} and {{domxref("AuthenticatorAttestationResponse.attestationObject")}}. The {{domxref("PublicKeyCredential")}} is sent back to the server using any desired formatting and protocol (note that the ArrayBuffer properties need to be be base64 encoded or similar).</li>