Dear habrozhitel! Dear experts! I present for your assessment a new concept of user identification on websites, which, I hope, with your help will become an open Internet standard, making this Internet world a little better. This is a draft version of the passwordless authentication protocol, designed as a free article. And if the idea underlying it receives a positive assessment from you, dear reader, I will continue to publish it on reddit.com and rfc-editor.org. And I hope that I will be able to interest developers of leading browsers in its implementation. Therefore, I expect constructive criticism from you.



Attention: a lot of text.





So the question is. Is it possible to unambiguously identify site visitors without disclosing their personal data and tracking between different sites? Is it possible, solving such a problem, to completely abandon the most primitive form of authorization by login / password and use cookie / localStorage?



On the one hand, sites need to recognize a client in order, for example, to “restore” their settings, product basket, ads, articles, etc. On the other hand, visitors want to remain as anonymous as possible, without revealing their personal data, and preventing third-party sites from tracking them. And the latter can do this by exchanging the collected data between themselves.



It sounds like a task to make sure that the wolves are full, and the sheep are safe. Is it real?



I, to a certain extent, I think - really.

Table of contents

1 Passwordless authentication concept

1.1 Keys and tokens instead of logins and passwords

1.2 Token Structure

1.3 HTTP protocol headers

1.4 How do customers identify sites?

1.4.2 How do I know if a site supports this protocol?

1.5 How do clients authorize sites?

1.6 And how to implement reliable customer identification?

1.7 Authorization on the site through the eyes of the user

1.8 How does a site key change?

1.9 How is cross-domain authorization implemented?

1.10 How to implement cross-domain authentication?

1.11 Account Mobility



2 Technical description of the protocol

2.0 Domain Key Generation Algorithm

2.1 the algorithm for calculating the source token

2.2 Token protection algorithm for transfer

2.3 Salt exchange procedure between browser and server

2.4 Rules for the formation of the Context field

2.5 Rules for defining Sender and Recipient fields

2.6 More on Context Definition Tables

2.7 Protocol Scenarios

2.8 Processing tokens on the server

2.9 Cross-domain authentication



3 Safety Recommendations

3.1 Protection of key information from unauthorized access

3.2 About passwords as domain keys

3.3 Risks of losing / compromising keys and minimizing them



4 Attacks on the authorization scheme

4.1 User Tracking

4.2 XSS attack

4.3 CSRF attack

4.4 Tracking using SSO

4.5 Key Compromise for SSO

4.6 Token compromise during transfer

4.7 Hacking a website and compromising tokens



Conclusion

1 Passwordless authentication concept

1.1 Keys and tokens instead of logins and passwords

For each domain, including child ones, the client browser randomly generates a unique 256-bit key $$ . This key is never transmitted. Remains constant within the user's session. Each new session creates a new key.

Key based $$ the browser generates a 256-bit ^* token using a special algorithm $$ to identify the user with a specific domain. Identification token $$ the user (hereinafter simply referred to as the token) serves as a replacement for session cookies like PHPSESSIONID and JSESSIONID.

Key $$ can be " fixed " by the user. Fixing the key will allow the user to remain authorized on the site for an unlimited period of time in different browser sessions and return the previous authorization. This is an analogue of the “remember me” function .

When the commit is canceled, the browser will “forget” this key and again begin to generate a random key for this domain for each new session (starting from the current one), which is the analogue of the user's “exit” from the site. The output is instant, not requiring a page reload.

The user can create a permanent key for the domain . The permanent key, as well as the fixed one, will allow the user to return previous authorization. In fact, this key becomes a replacement for the login-password connection.

The user gets the opportunity to control when the browser for the domain will use a constant key, and when - random. This is an analogue of the login / logout function . The concept is presented in the screenshots below .

Methods for generating persistent domain keys provide the mobility of user accounts between different devices. The protocol defines the following:

• generation of a domain key based on the user's master key
• individually forming a domain key based on a biological random number sensor
• importing existing keys from a key file from another device

1.2 Token Structure

The token is a 256-bit structure, represented as a hexadecimal string:



The identification part of the token (the highest 128 bits) is similar to the login. By this sequence of bits, the server can uniquely identify the user.

The authentication part of the token (the lower 128 bits) is similar to the password. This bit sequence helps the server validate the token.

Token validation rules are described below .

1.3 HTTP protocol headers

Headers used by the client:



CSI-Token : <Token> is used to send a token to the server

CSI-Token : <Token1>; Changed-To <Token2> is used to change the current token:

• when authorizing on a permanent key,
• when registering a permanent key,
• when changing the permanent key.

CSI-Token : <Token> Permanent is used when fixing the current random key by the user.

CSI-Token : <Token> Logout is used to prematurely end the current session.



Headers used by the server:

CSI-Support: yes tells the client that the server supports the CSI authorization protocol.

CSI-Token-Action: success is used to notify the browser about the acceptance of a new user token (Change-To key).

CSI-Token-Action: abort cancels the procedure for changing tokens (rollback to the previous token).

CSI-Token-Action: registration tells the browser that the new user token is still in the process of registration.

CSI-Token-Action: invalid error verifying the token on the server side.



Finally,

CSI-Salt is sent by both the browser and the server when exchanging the "salt" used to protect the token (authentication part). See below for more details.

1.4 How do customers identify sites?

A site can use a token to identify a site visitor. At the same time, the token generation scheme and their 256-bit capacity guarantee unique tokens for each pair: user-domain. Another domain will see another user token. Even if executed in the context of the target site (via IFRAME, IMG, LINK, SCRIPT). In addition, a special token generation algorithm protects users from XSS and SRF attacks and makes it impossible to track a user without his knowledge. But at the same time, SSO technology remains possible with its permission and cross-domain identification.

The token is transmitted in the CSI-Token HTTP header with every request to any domain resource (page, document, image, script, style, font, file, ajax request, ...):







The token is recalculated at each HTTP (S) request : page, picture, ajax request.

In order to optimize the calculations, caching of tokens by the browser is allowed, but only for the duration of the session and only if the conditions for fulfilling the request remain unchanged.

As noted above, the token can serve as a replacement for session cookies like PHPSESSIONID and JSESSIONID. The only difference is that if the site previously generated an identifier for the visitor to track a specific user between his different requests (after all, thousands of requests from different users come to the site at the same time), now the client performs this function.

Such identification is quite sufficient to allow you to make purchases in the online store, to advertise on appropriate sites, write on forums, on social networks, Wikipedia or Habré articles.

Yes, the user remains anonymous for the site. But it can be an anonymous “familiar” to the site. And the server can save the token of such a user on its side, along with its data (personal account with purchases, preferences, karma, buns, likes and other bonuses). But only to keep under condition of completion of any business process: purchase, submission of the announcement, etc. The conditions are determined by the site itself.

As you can see, the protocol is as simple as possible for sites that do not need to register you before giving you the opportunity to take any action. But those who need it will have a little more difficult. But more about that below.

1.4.2 How do I know if a site supports this protocol?

The site should pass the CSI-Support: yes http-header in the Response Headers section of its response:







Upon seeing such a title, the browser will unobtrusively inform the user that he can save himself on the site. For example, the key symbol in the address bar:







Clicking on a key, for example, allows you to create a key for the domain www.youtube.com :

The formation of a new key does not lead to its automatic use.

The permanent key begins to be used only when it is activated by the user.

1.5 How do clients authorize sites?

It is important to understand that the token does not yet make the user authorized on a particular site - only recognizable. But, as already mentioned, for now you are simply a recognizable “anonymous person”.

If the site needs to associate your token with you personally, registration on such a site, alas, cannot be avoided. But in the proposed protocol, this is made a little easier.

It is important for developers to understand: most sites do not need a questionnaire. Avoid forcing visitors to register. In most typical situations, you can carry out a business process without collecting PD visitors.

Filling out tedious registration forms “with or without” is unpleasant. But with the new protocol, coming up with another login and password is no longer required. Only the Confirm and Save Me button:







You, of course, will have to first create a permanent key for the site. But this is a matter of a couple of mouse clicks.

And, for sure, you will be asked to confirm your phone or mailing address. But it already depends on the site.

After successful authorization, the server, through a special HTTP header, CSI-Token-Action will inform the browser that it has accepted the new key. More details in chapter II .

1.6 And how to implement reliable customer identification?

In more serious situations (personal account of the provider, hosting, bank) two-factor authentication should and can be carried out, and proof of the possession of the token can be done through pre-registration and confirmation of identity in other ways: by email, SMS, or even by paper fixing the user's token. (Yes, yes. Certificates are recorded on paper, why not tokens).

1.7 Authorization on the site through the eyes of the user

The browser notifies the user that the site supports CSI authorization through the lock icon in the address bar. If you perform some actions on the site, you can ask the site to remember you. From this moment, the server will recognize the user even between different sessions:









Instead of fixing the key, the user can create a permanent key for the site and register there. Animated illustration:









And when the user has a permanent key for the site and this key is registered there, the login process is greatly simplified:









The greatest power of the protocol is manifested when the user creates a key for the site based on the master key. In this case, the problem of your identification on sites on other devices is easily solved . The following animation demonstrates this. It is assumed that you previously distributed your master key once between your devices / browsers:









For sites with two-factor authorization, “recognition” may look like this:









Exit is even easier. Click "Logout" in the browser and that's it:







The browser sends a request to the site (on any page) with the HEAD method, in which it sends the CSI-Token <> header; Logout.







The server, seeing such a header, makes a Logout. If it was a fixed key, then the site deletes all information about the user (more than such a key will never appear). If it was a permanent key, just breaks the session.

Any further activity of the site turns the user into an anonym unknown to the site: reloading the page, trying to make an ajax request, download a file, etc. - The browser will send a token generated already on the basis of a random key.

You can manage the keys in the key manager: change the permanent key, export the permanent key to a file, import from a file from another device. Set up “auto-exit” after closing a tab or browser. Set the duration of a fixed key.

1.8 How does a site key change?

Replacing the site’s permanent key is technically the same as changing from a random key to a permanent one. This is described in more detail in chapter II .

In case of changing the permanent key of the site, the browser notifies the site of the corresponding change in the token, sending a CSI-Token header with the Changed-To key in each subsequent request :







The site must correctly process such a request. And, if a given user token is stored in its database, it must make an appropriate replacement. At the same time, the site should respond to the browser about the successful change of the token on its side. He does this in the Response Headers header with the parameter: CSI-Token-Action: success , indicating the token applied.

The site has the right to reject an attempt to change the token (for example, if there was no such token in its database or it does not save them at all) with the CSI-Token-Action: aborted parameter.

Until the browser receives the CSI-Token-Action header, it will add the Changed-To key to every CSI-Token request to the site.

This is an analogue of the “password change” of the user.

1.9 How is cross-domain authorization implemented?

Classical cross-domain authorization using SSO technology has many advantages for the user. You do not need to remember a bunch of passwords from a bunch of sites. There is no need to register and fill out the dreary forms. Some authorization servers ask what rights to grant the site that requested the SSO.

But there are also disadvantages. You are depending on the SSO provider. If the SSO server does not work, you won’t get to the target site. If you lose your password or your account is stolen - you lose access from all sites at once.

For web developers, things are a little more complicated. From the beginning, you need to register your site on the authorization server, get the keys, learn how to work with the protocol ( SAML , OAuthetc.) and the appropriate libraries, make sure that the key does not expire, that the authorization server does not block your site for your reasons, etc. This is a fee for the fact that you do not need to keep user accounts, do registration forms, login, etc. The truth increases the cost of maintenance (in the form of repairing sudden failures). Again, if the server is suddenly unavailable to the site, then alas.

This authorization scheme makes SSO a little more secure, and authorization for all participants is easier. About security will be discussed below in the section "Key Compromise for SSO".



Have a look at site S, which supports Google’s SSO. Suppose you have a Google account. To log in, you click the "Sign in with Google" link, which will open the Google authorization tab. The browser will tell you that you have a key for Google. And Google will tell you what rights S. requests.

If you agree, click "Sign in" in the key manager. The page will reload. Google will already receive its valid token, recognize and authorize you. And with an inter-server request, it will inform Site S about your account information in accordance with the requested fields.

The reloaded page will contain a “Next” button that returns you to the target site.









Site S may decide to save data about you in its database or not. This issue is beyond the scope of the proposed authorization scheme. But further, where we will consider the risks of losing the key for SSO, the site is recommended to keep the user token and identifier from SSO on its side, and the user is recommended to create a permanent key for S.

Vulnerability: After such authorization, sites S1, S2, S3, ... (where you logged in via Google) will be able to recognize you (by the identifier assigned to you by Google), and, as a result, track your activity.

Protection option: do not work simultaneously on sites if you registered through the SSO of the same provider. If possible, log out from the authorization server immediately after authorization is completed (“auto-exit” for the domain).

1.10 How to implement cross-domain authentication?

All this, of course, is good. While the work is carried out on one browser - everything is fine. But what about modern realities when a person has two mobile phones, one working computer and several browsers on it, a home computer, and another laptop? Plus a common tablet for the wife / children.

We’ll have to somehow solve the issue of transferring domain keys between browsers, devices. And also to solve the problem of their correct synchronization.

One of the mechanisms for solving this problem is to calculate various domain keys based on a common master key without the possibility of reverse recovery of the master key from a known domain key.

By creating a personal key K for domain D using the master key M on one device, the user can create the same key K for domain D and on any other one using the same master key M and a single algorithm. More precisely, this will be done not by the user, but by his browser. With this approach, it is enough for the user to distribute his master key between all browsers used by him and he "transfers all his keys" of domains at once. At the same time makes backups in this way.

Maximum user convenience. But also the maximum risk in case of compromise of the master key. Therefore, the latter should be protected accordingly. The risks of loss or compromise of the master key, and ways to minimize such risks are described in the chapter “3 Safety Recommendations” .

Using only one master key to generate all keys for all domains is not always a convenient option. Firstly, what to do if suddenly the domain key is compromised and needs to be changed? Secondly, what if you need to share a domain key with another person? For example, between family members. Or is it a corporate public mail access account. How then to "pick up" your key (because in fact it has been compromised)?

Therefore, the generation of individual domain keys using a biological random number sensor must be supported by browsers. But then we again return to the question of our mobility and the issues of synchronization, export and import of keys in the browser, and creating backup copies.

Transfer through a physical alienable device

Smart cards and usb tokens can be quite suitable as a secure storage of key information (because they were created for this). Two-factor authentication protects keys from unauthorized access with direct access to the device.

True, smart cards require special readers (not to mention drivers), which limits their use only to workstations equipped with such readers.

With USB tokens a little easier. Only drivers are required. But you can’t stick such a token in the phone. And although for mobile phones there are tokens made in the form of SD-cards, not to say that this solution adds to mobility. Try to draw a card from a mobile phone, but insert it into another. And it's not that this is impossible. The thing is that it is not convenient.

And if the token breaks? Then all your keys will go to the Great Cthulhu.

So there will be a temptation with such a scheme to use several duplicate devices. But then you still need to solve the key synchronization issue if you have several smart cards.

And, frankly, such devices are not protected from keyloggers. Now, if the pin code would be entered from the card / token itself. Then another thing. But I have not seen such in nature.

Pros: random 256-bit keys can be used; high security through the use of two-factor authentication; the highest level of protection against direct tamper.

Cons: device dependency; requires financial costs; low mobility; the need to reserve cards and, as a result, synchronize data between them; vulnerability to keyloggers remains.

Sync via online service

"Cloud technology" is now shoved wherever possible. It seems they, together with the blockchain, have become a replacement for "banana technology." Naturally, there is a desire to use a certain Internet platform for the exchange of key information. A kind of smart card "online".

And what?You log in using our scheme anonymously on such a site; send your keys encrypted with a password there; you go from another device to the same site with the same key / password; you get the keys from there; You synchronize changes by the date of editing. Similar to password manager, only this is online.

That's just, no one guarantees that the online service will not be hacked or will not merge your, albeit encrypted, “where necessary” keys. Who will implement such a service for free. That's it.

Although, of course, the password protects the keys from direct use. But is your password resistant to brute force "offline"? That is another question.

Pros: high credential mobility; device and browser independence; you need only one single password (although they haven’t left the password, it’s already better).

Disadvantages: less secure than storing keys on an alienable medium. In fact, the security of keys is based on the strength of the password to selection.

You can, of course, use a master key to encrypt other keys. The one with which other domain keys are calculated. As an option.

2 Technical description of the protocol

2.0 Domain Key Generation Algorithm

This protocol defines only 2 methods for generating domain keys.

• based on a random number generator (preferably biological)
• based on a 256-bit master key

In the latter case, the domain key is calculated as:

$$

Where $$- 256-bit master key, Domain - domain name for which the key is made.

Hereinafter, HMAC is a hash cryptographic algorithm based on a 256-bit implementation of the SHA-2 hash function .

Compromise or voluntary disclosure of a domain key does not compromise the original master key.

The master key provides a mechanism for the mobility of user credentials.



If the key created on the basis of the “master” was compromised, or the token calculated from such a key (as a result of hacking the site) was compromised, then the key must be changed. You can change it to a random 256-bit key, or generate it from the same “wizard”, with the addition of a version:

$$

Hereinafter, the symbol $$ will be used for string concatenation operation (byte arrays).

2.1 the algorithm for calculating the source token

The user's authentication token is computed with every request of any domain resource. To calculate the request token, the following data is taken:

• Sender - the domain name of the initiator of the request (it can be a page with an iframe or a script from someone else's domain that performs fetch),
• Recipient - domain name of the recipient (where the request is sent),
• Context - request execution context,
• Protection - a random sequence of 32 bytes (256-bit), if Context is empty; otherwise empty

This data is concatenated and hashed with 256-bit SHA-2 on the key K of the domain initiating the request :

$$

A valid token is obtained when Context is not empty. For proper identification on the target site, the condition Sender = Recipient = Context must be met.

The Context field, together with Protection, is used to protect against XSS and CSRF attacks, as well as from user tracking.

More detailed explanations on the rules for determining Sender / Recipient / Context will be given below.

2.2 Token protection algorithm during transfer

The original client token is transmitted extremely rarely. Only when transferring an unregistered token at the time of the creation of the session.

A token is considered unregistered if it: is created on the basis of a random (not fixed) key; was not accepted by the server after sending the Change-To or Permanent key. For details, see "Processing tokens on the server . "

The browser and server jointly generate a pair of random numbers, the so-called salt (Salt), with which the lower 128 bits of the token are hashed. Both exchange these numbers according to the protocol. For details, see “Salt Swap Procedure Browser-Server” .

Thus, the site server sees the following token:

$$

Where $$ - high 128 bits, $$ - the lower 128 bits of the original token, $$ - string concatenation. In this case, the initial token $$ should already be known to the server.



Ideally, CSI-Salt should change every time a browser requests a server. However, this can be a costly requirement in terms of computing resources. In addition, it can “kill” the ability to send parallel requests to the server.

Therefore, in order to optimize the calculations, it is allowed to keep the CSI-Salt values ​​unchanged in different requests, but not longer than one session . This can be a time limit (change of CSI-Salt every 5 minutes), or a reaction to the intensity of requests (change of CSI-Salt every 100 requests), or after each series of requests (at the time of pause, client-server), or a mixed version. Here the decision is left to the browser developers.

Keeping CSI-Salt unchanged for too long weakens the protection of the transmitted token, allowing the attacker, when intercepting the token, to use it until the legitimate user completes Logout and execute an unauthorized request on behalf of the victim.

2.3 Salt exchange procedure between browser and server

2.3.1 Token based on a random or unregistered ^[1] server key.



2.3.2 Token based on the key registered by the server ^[1] .

---

<sup>[1] A token is considered unregistered if it: is created on the basis of a random key; was not accepted by the server after sending the Change-To or Permanent key with the CSI-Token-Action: success response.

[2] The time through which the CSI-Salt change is made is determined by the browsers themselves. This can happen after a series of requests, after a timeout, after a certain number of requests. The only restriction is that using the same CSI-Salt in different sessions is prohibited .

[3] This refers to the concatenation of the hexadecimal representation of 128-bit numbers. The first is always the salt of the client, the second is the salt of the server: With _salt || S _salt . If the browser does not have server salt, it hashes the token with its salt, passing it in the header. If the server does not have client salt, then it should consider that the token is transmitted insecure.</sup>

2.4 Rules for the formation of the Context field

We will call ours the domain whose page we are loading (displayed in the address bar of the browser). The remaining domains will be called external . Even if these are child domains of a given.



We call the resource external if it was downloaded from an external domain. We’ll call the resource internal if it was downloaded from our domain. The resource can be a script, image, ajax request, and any other file.



A script is considered external if it was downloaded from an external domain. The script placed in the created <script> tag, created by an external script, will also be considered external. The script located in the modified <script> tag is declared external if it was modified by an external script, or an external script was present in the call chain when its contents changed. Even if at the same time the given <script> was originally on the page or was created by an internal script.



We will name the LINK, SCRIPT, IMG, IFAME tags and others that require the browser to load some resource as soon as it is met by the DOM parser - resource tags .



We will name the FORM, A, META tags and others that can initiate page loading under certain conditions (submit, click, timeout) - initiating tags .



We will call the tag static if it was originally present on the page when it was first issued by the server. We will call a tag dynamic if it was created in the process of running scripts.



The FORM tag is declared dynamic, even if not only the tag itself has changed, but also the values ​​of all INPUT fields associated with this form.



We call a dynamic tag our own if the script that created it belongs to our domain, and the call chain of the instruction that generated this tag did not have a function belonging to an external script. Otherwise, we consider such a dynamic tag improper .



Page loading is triggered by initiating tags. The initiating tag can be triggered directly by the user, or activated by the script, by executing the click command (for the link), and submit (for the form), or by the script generating the corresponding onclick / onsubmit events.



Also, the initiating tag can be activated by the browser. An example of such a tag is META with the parameters http-equiv = "refresh" content = "0".



^{Table P. Context values ​​under different page opening conditions}





If the resource tag was changed by a script (for example, the SRC attribute of IMG), and then the resource was automatically loaded by the browser, then we believe that the content / resource was triggered by the parser, the method of loading is the tag, but the status of this tag becomes “dynamic”.



^{Table R. Context values ​​under different conditions for loading content / resource}

---

<sup>[1] Trigger tag

[2] Resource tag

[3] Inherit for its own pages, Empty when opening pages of foreign domains

[4] Inherit when redirecting the server to its pages, Empty when redirecting to other people's domains or opening the page from external sources (see explanations )</sup>





Marks of the form P1..PF, R1..RC will be used to refer to the corresponding cell in the table when analyzing specific situations.

Notice the highlighted Referrer and Domain in the first table. You can only become authorized on a site when you yourself open the site at a direct address, or through a link from another site, with subsequent reloading of the page on your own initiative.

2.5 Rules for defining Sender and Recipient fields

Sender is the domain of the page / script / style from which the request comes. The page requests styles, pictures, scripts. Scripts request content via ajax. Styles can load other styles. These are the initiators of the request.



Recipient is the domain that the request really goes to.



So that there are no questions left, let us consider specific examples.



Let there be a site.net site. On the main page of the site is:

• style site.net/css/common.css
• common.css styles import fonts.google.com/fonts/Roboto.css styles
• Roboto.css style imports the font fonts.google.com/fonts/Roboto.ttf
• picture leading to img.site.net/picture1.jpg
• frame loaded from adriver.ru/frame
• script from adm.site.net/admin.js

Let in the frame (with adriver.ru) connect:

• style from adriver.ru/style.css
• picture from img.adriver.ru/img/01.png
• script from adriver.ru/libs.js
• script from api.adriver.ru/v1/ad.js

Sender / Recipient values ​​when loading resources with the DOM parser



Now let's look at the values ​​of Sender / Recipient when loading content with scripts during the execution of ajax requests.



Sender / Recipient values ​​when loading content with scripts

2.6 More on Context Definition Table Values

Let us consider in more detail what options for opening pages (tabs in the browser) we have, and what Context value will be obtained.



P1 - the user on the previous page clicked the link or click the submit button on the form. The standard event browser handler for the link / form redirected the user to this page. Normal situation. Safe transition between pages of a domain or different domains.



When switching to site.net from another google.com domain, Context will be equal to the previous domain (google.com). And the user on the new site.net domain will be unauthorized (even if the neighboring tab of this site where the user is authorized is open).



Repeated independent transition of the user (without the assistance of scripts) to the link to the same site will lead again to situation P1 , but Context will already be equal to the domain site.net, because by the rule Context = Referrer.



This is to protect against CSRF attacks.



P5 - the user on the previous page clicked on the link created / modified by a script downloaded from the domain of the previous page; or the user on the previous page clicked on the submit button of the form created / modified by the script (changing the FORM tag, including its INPUT fields). The standard event browser handler for the link / form redirected the user to this page.



P9 is the same as P5 , only the script was external, or there is a function from an external script in the call chain (protection from editing the script functions of the site script by a third-party script).



PD - the user opened the page at a direct address. Safe opening.

The user must open the page by entering the URL in the address bar. Or open a site from browser bookmarks.

Opening a link from a desktop shortcut from another program, any other situation where the OS sends a command to the browser to open the link should be considered as a PG case (opening the link is initiated by the browser). Even if the user presses F5 to reload the page, this should be considered a PG case. Only if the user gets into the address bar and presses Enter will be considered by the browser as a PD .



This is done to protect CSRF attacks from other programs.



Following the link from another program will lead the user to the attacked site with an invalid token and an empty Context, which will be saved even if the user presses F5 (refresh the page). You cannot log in until the user opens any link to the site’s pages (situation P1 ).



Thus, if an attacker from another program decides to slip an authorized user a link to the site.net site page that is executing a command, he will not be able to do so easily. It will be necessary to force the user to click another link on this page, then force the user to authenticate there, and only then ... Then, the user will most likely be on another page of site.net.



P2 - on the previous page for a link or form originally placed on the page, a native script of the previous page generated a click / submit event. There were no functions in the call chain that belonged to external scripts. The browser redirected the user to this page.



If the new page belongs to the same domain, Context is inherited from the previous page. If the new page belongs to a foreign domain, Context will be blank.



P6 is the same as P2 , only the link / form was created / modified by its own script.



PA is the same as P2 , only the link / form was created / modified by an external script.



PE - the script on the previous page provoked the opening of this page with the command window.location.href or window.open (...).



If the site.net page script redirects the user to a page of the same domain, the Context field will be inherited from the generating page. In this case, Context = site.net.



If the ya.ru page was opened, and the script transferred us to maps.ya.ru, then the Context of the new page will be empty. In the subsequent actions of the user, the Context will almost always remain empty, which will complicate the authorization of the user on the site.



The protocol implies that opening one site of another is an unsafe operation. This protects the user from unauthorized tracking by these sites and from CSRF attacks.



P3 - similar to P2 , only the click / submit event was triggered by an external script. Context becomes empty (a random sequence of bytes is sent instead), which protects third-party sites from tracking the site (banner networks).



P7 - similar to P6 , only the link / form was created / modified by an external script.



PB - similar to PA , only the link / form was created / modified by an external script.



PF - similar to PE , only the provocative script was external.



P4 - the browser reloaded the page as a result of processing the <META> tag. The tag was originally on the page. Legal redirect. Context will persist from the original page. As is the case with PE .



P8 - the browser reloaded the page as a result of processing the <META> tag. But the tag was created / modified by its own script. This is valid, but Context will persist from the original page. As is the case with PE . It will not be possible to lure the user's legal token in this way.



PC - similar to P8 , only external script. The opened site will receive a random number as Context.



PG - browser opens links on command from the OS. It may be, you click on a link from another program, open a shortcut on the desktop. This may be a command from another program, without your knowledge. In this case, the source is not trusted, and the Context field will remain empty during any user manipulation.



This is done to protect CSRF attacks from other programs.

If the browser itself opens the previously saved tabs, then the Context of the page is set equal to the value of this page at the time of closing the browser.

In addition, this category includes all situations where the browser is redirected by the server to another page (of its own domain or someone else's) as a result of processing the Header HTTP header. If the redirect goes to your own page, then the Context value is inherited. If the redirect goes to someone else’s - it is reset.



This is done to protect against tracking attacks of web servers.

By the way, such a rule can cause problems with the current implementation of cross-domain authorization. If, after authorization, the SSO server redirects the user back to the target site, the latter will be anonymous there.

To prevent the user from “losing” the original authorization on the target site, it is necessary to transmit authentication information between the server requests. The algorithm may be as follows:

1. the user creates and activates a permanent key for the target site;
2. Goes from the target site to the SSO server itself by clicking on the appropriate link;
3. activates the existing permanent key from the SSO server;
4. Having received the Changed-To key, the SSO server sends an inter-server request to the target site;
5. the user clicks the “Continue” button on the authorization page, which returns him back to the target site;
6. in order to fulfill rule P1 , the target site offers the user to click the link button again leading to him (for example, to the start page of an authorized participant).
7. the user clicks the link button, the page reloads, and the user is already authorized on the target site.

The description of the algorithm actually looks more complicated than its implementation. A UI implementation might look like this:

Re-entering the target site no longer requires SSO authorization from the user. It is enough to activate the permanent key.

Now let’s take a closer look at the options for loading content on pages, and what Context value will be obtained upon request.



R1 - the resource is loaded by the browser as a result of parsing the page (the browser met a resource tag). Context value when generating a request for a resource is taken from the Context page containing the resource tag.



For example, if site.net has an adriver.ru frame in which the image from img.disk.com is loaded, then when generating an HTTP request to img.disk.com, the browser takes the value calculated as the Context for the page site.net.



R4 is the same as R1 . Only the resource tag was created / modified by its own script, as a result of which the browser DOM Parser worked. For example, on the site.net/index.html page, our own site.net/require.js script inserted another custom script (<script src = ...> tag) site.net/min.js, which forced the browser to generate a file download request main.js. The Context field in this request will be set to the value that was calculated for the site.net page.



R7 is the same as R1 . But since the resource tag was created / modified by an external script, when the resource is requested, the browser will generate a token based on an empty Context and a random 256-bit sequence. As a result, the external attacker script evil.com/drop.js, embedded on the page of the attacked site.net domain, trying to fulfill a request to the target site.net on behalf of the victim will fail, because the server will receive a request with a random token and will not be able to identify the sender of the request.



RA - parser downloads content as a result of analyzing other content. For example, the site.net/css/common.css stylesheet, downloaded for the site.net/index.html page, imports the fonts.google.com/fonts/Roboto.css stylesheet, which forces the browser to request fonts.google .com on behalf of Referrer = site.net/css/common.css. The Context value in this case will be equal to Referrer. Next, the Roboto.css styles file imports the Roboto.ttf font, which forces the browser to request fonts.google.com/fonts/Roboto.ttf on behalf of Referrer = fonts.google.com/fonts/Roboto.css. The Context value will be equal to Referrer in this case, but it’s different.



Suppose, hypothetically, that the Roboto.css file (external resource) does not import a font / style, but tries to conduct a CSRF attack with this instruction:

@import "https://site.net/api/payment?victim_params"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

hoping to fulfill the request on site.net on behalf of an authorized user. But the problem for the attacker is that site.net expects to receive a token from the user:

$$

Then, as with such a CSRF request, the browser will create a token:

$$

And a request to the site will come on behalf of an anonymous site that does not have access rights to perform these operations.



RB - content is uploaded by the site’s own script. In this case, Context is used to calculate the request token, which is equal to the page containing the script. For the site.net/1.js script from the site.net Context page, it will be equal to the Context of the page itself.

Note that the Context of the page itself is not always equal to the domain name of the page and depends on how it was originally opened.

Suppose that the site of the attacker evil.com opens the page of the attacked site site.net, where the site.net/util.js script executes a request with the parameters passed through the URL of the page. The attacker hopes, by slipping “his parameters” through the URL, to force his own site.net/util.js script to execute an ajax request to perform important actions on behalf of the victim.



Suppose that the user himself went to evil.com via a direct link. Then Context for evil.com will be evil.com. Further evil.com opens site.net/api/payment?victim_params with a script , hoping to conduct an attack, but the Context field for site.net will already be empty (PE / PF case). The site.net/utils.js script, executing an ajax request, will force the browser to take Context from the site.net page. And it is empty with us. But then site.net will receive an ajax request with this token:

$$

whereas for an authorized user it is expected:

$$

site.net will see an unknown token and will not be able to identify the user. The protection worked.

By the way, speaking, because of such a scheme, conducting cross-domain authorization through pop-ups will be unrealistic.

To implement SSO under the protocol, you must open a new tab for the authorization server page. And at the same time, the user must open such a tab. The best option is for the user to open the appropriate link from the target site.



RC - content is loaded by an external site script. In this case, Context is used to calculate the request token, which is equal to the Request Referrer field.



Despite the fact that RA , RB and RC protect against CSRF attacks, they nevertheless lead to the generation of constant tokens. And this allows you to implement cross-domain authentication and cross-domain user authentication (when you need to determine that several requests to different servers have come from this user). What can be implemented to provide him with equal authority on a group of related domains.



If the site page was opened automatically from another site, you will not be able to log in there, even if you reload this site yourself. Because Source will inherit from an empty value. The browser should signal to the user about this fact (Source = Random):







This is done to protect against sites that force other pop-up windows to be opened (themselves or their external scripts), and on the sites that open, they will reboot or create fake “close” buttons on the entire screen leading to the same sites. Those. this prevents an attempt to track you, hoping to get a valid token.



Any attempt by the site to imitate your actions with an external script , or an attempt by an external script to directly or indirectly create an initiating tag and slip it to you, will lead to an empty Source and the addition of random bytes at the time of calculating the token hash.



The trick with creating or modifying the <script> tag in the attacked page in the DOM will not help. The Source field will remain blank.



But under the same conditions, internal scripts will lead to queries with Source equal to its previous value. And if the original page had Source = Domain, everything would be fine. The user will remain authorized for such requests.



But with scripts downloaded from third-party resources (CDN), problems may arise in some cases. And it’s right, because CDN code integrity is not guaranteed. If you want not to lose user authorization, keep the scripts on your site and download them from your domain. This is a bit of an analogy to prohibiting the use of http links on https pages.



We describe the situation that a developer might fall into. As a result of user actions, your script redirects an authorized user to one of the pages of the site (for example, this is done by a form), requiring that the user remains authorized. Your script calls, for example, $ (form) .submit () using a jQuery script loaded from the CDN. In this case, the browser sees that in the call stack that triggered the submit event of the form, there is a function from an external script. To prevent XSS / CSRF attacks, the browser makes the Source field empty, and adds random bytes to the generation of the token (case P9 ). As a result, the user on the new page suddenly becomes unauthorized and cannot complete the operation. This can be confusing for developers who are used to using CDNs.

2.7 Protocol Scenarios

Here are the main likely scenarios of the user working with the site, affecting all possible situations and the stages of their implementation (anonymous login, “remember me”, “forget me”, switch to using a permanent key, authorization and logout, registration and two-factor authentication, export / key import, key replacement, etc.)



An example of token access configuration based on the .htaccess file.

 <Directory "/var/www/html"> AuthType CSI AuthName "Restricted Content" AuthTokensFile /etc/apache2/.csi_keys Require valid-user </Directory>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 cat /etc/apache2/.csi_keys 

 # # Client Self Identification tokens file # # CSI-Domain-Key UserName Role 84bc3da1b3e33a18e8d5e1bdd7a18d7a166d77ac1b46a1ec38aa35ab7e628ab5 MelnikovIN admin 6d7fce9fee471194aa8b5b6e47267f0348a24b70a0b376535542b996af517398 BoshirovAM user
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2.7.1 Algorithm for calculating a site’s possible user tokens using a known key

If we know the domain key K, we can easily calculate the possible “valid” token T of the user who will come with his requests. For this, it is necessary that the condition is met: the initiator of the requests, the recipient of the requests, and the execution context must match and be equal to the domain. In other words, if we have the vsphere.local domain name, then:

 Sender = Recipient = Context = vsphere.local
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

From here, the original (raw) token is calculated as:

$$

Upon transfer, the original token will be further protected. The lower 128 bits of the token will be hashed with the salt passed in the CSI-Salt ^* request header . Thus, the site will see the following token:

$$

Where Hi is the high 128 bits, Lo is the low 128 bits of the original token.

Usually, for closed management consoles on the corporate network, web consoles do not load external scripts, frames, etc. Therefore, this condition will be satisfied in most cases.

---

^{* For the method of salt formation, see the section “Salt exchange procedure between the browser and the server”.}

2.8 Processing tokens on the server

Sending a token to the server (without keys)

Permanent

The browser captures the client key. The user wants the site to remember the customer for more than one session. Whether to store the user token in its database is the decision of the server. We return CSI-Token-Action: success or CSI-Token-Action: abort to the client.

Sending a token with a Logout key

Indicates that the current token will no longer be used by the browser. Sent when the user clicks "Exit" in the browser, or closes the tab and the option is configured (auto-exit when the tab is closed), or refuses to use a fixed key ("forget me on this site").

Autologin, by the way, should not be. For security reasons.

Sending a token with a Change-To key

Let's call the old token T, the new one - T '.



IMPORTANT: as the new token T ', the real value of the token is sent (for the first time, for unregistered ones), while the old token is sent hashed (the lower 128 bits).

---

^{* , .}

2.9 -

As mentioned earlier, sites can interact with other partner sites or their sub-domains to provide the user with some of the functionality. The most common example is when on the site.ru site some of the resources are loaded from the img.site.ru subdomains, part of download.site.ru, and another part from others.



In this case, site.ru needs to be able to tell its partner domains who exactly they are receiving requests from. Indeed, if you are authorized on site.ru, this does not automatically make you authorized on other sites, including sub-domains of the site. They will see other tokens from you.



Let's see how the token is calculated and how this can help us.

Let the user log in to site.ru with a permanent key and have a token there:

$$

All requests coming from the site.ru site page to the site.ru domain and caused by:

• page resource tags (static or native dynamic)
• own scripts

will have a token T ₁ (see rules R1 , R4 , RB ). These are legitimate requests to site.ru.



Now let the client download the restricted file from the site.ru page, but the link leads to download.site.ru. In this case, the subdomain will receive the following token (rules R1 , R4 ):

$$

Exactly the same download.site.ru token will receive if an ajax request is made on it from the site.ru site page ( RB , RC rules ).



Another domain domain will receive a token:

$$

But, pay attention that if the conditions for fulfilling requests do not change, then for a given bundle of domains A, B, C, the browser will always generate a constant token. So we can conduct cross-domain identification. For example, like that.



From site.ru, we make ajax requests for subdomains. We pass the identifier ID! = T _{1 of the} user, issued to him by site.ru. Subdomains will receive T _x tokens for the same user . Each of the subdomains will make a bunch of its token with the user ID. The subdomains will already share information about the user ID and his rights with server-to-server requests.



The bunch is done once. Subsequently, the subdomains will focus on their own tokens, as they will also be permanent for the site.ru permanent key.

3 Safety Recommendations

3.1 Protection of key information from unauthorized access

The proposed authorization protocol protects the user from keyloggers stealing your passwords, because the proposed scheme does not use passwords at all.



But ways to protect keys from compromise should be considered in more detail.



Keys can be compromised by:

• copying key information by malware (remote access)
• direct access to the file with the key information "offline" (direct access)
• at the time of distribution between devices

Assuming that key information is stored on a smart card (we considered this option in the “Account Mobility” section ), the task of protecting key information is transferred to the chip. True, there is a vulnerability to keyloggers that can intercept the entered PIN code; Well, inconvenience to use.



In addition to smart cards, symmetric encryption can be used to protect against direct access to key information. But the question is: what key to take for encryption?



If this key is generated on the basis of the user's password, then, firstly, we get a vulnerability to the selection of the password “offline”, and secondly, in fact, what we left from, came to that: “again, some passwords”.



A more correct option is to sew in a special way ^*such a key in the browser assembly (or one of its specialized libraries). Each update of the browser changes both the key and its location in the compiled file. This approach will not give a 100% guarantee of protection, but will seriously complicate the task of decryption. First, the attacker will need to find out the exact version of the assembly, then find it, disassemble, and find out how the key is assembled.



Also, the domain keys themselves should be directly stored in a separate file, and not together with the configuration for their use (i.e. only the keys and nothing more). Then their decryption by the key selection method (from known assemblies) will be impossible, because it is impossible to distinguish a correctly decrypted key from a random sequence of bytes. Then attempts to pick up a master key without knowing the exact version of the browser assembly and directly disassembling its code will become impossible at all.



You can use the combined option: encryption with the key from the browser + encryption with the user password from the OS account (if the OS API allows it). Moreover, the key is always generated on the fly. Then offline brute force will become even more expensive.



In addition, after changing the user password in the OS, the key will also change. And if you do not pre-decrypt on the old key, then this will protect against situations when the computer administrator changes your password to gain access to your account and perform actions on your behalf. Situations of the type: quit his job.



You will first make a backup copy of the keys (export the keys to a file). Unless, of course, you already did this before when distributing keys to other devices.

---

^{* For example, a 32-byte key is randomly distributed in the 64K section of an executable file. And only the source code knows how to collect the treasured key from these bytes.}

3.2 About passwords as domain keys

In one of the initial versions of the protocol, a domain key could be generated based on the user's password. The algorithm was tricky, excluding duplicate keys from different domains for the same password.



This was positioned as a convenient way to mobility accounts. Entered one password and do not worry about anything. But then it turned out the following:

1. , «» , , . , -, .
   
   
   
   (), 8- , , .: ~!@#$%^&. : 26 + 26 + 10 + 8 = 70 . 8- 70 ⁸ .
   
   
   
   , , 10 ¹² . 70 ⁸ / 10 ¹² = ~576 . Those. ~10 . 5 . 10- 15 . 10 , 1-2 .
   
   
   
   , .
2. , .
3. , . Those. ( SHA-2).
4. , , , . .

3.3 /

What if I lose the master key?



This can happen if you change your password or reinstall the OS. What are the risks?



Well, you will not get to the sites where you were before. Lose your shopping history on online stores, your ads on online sites, karma on the forums. No problem.



Although, who prevents to do the re-registration procedure with a new token and confirming it through the phone number indicated in the same announcement? It turns out that the site needs to do a form of re-registration of the token (an analogue of "password recovery")? Where is the promised absence of “all sorts of” forms?



In fact, a site that needs to not only identify the visitor, but also know who it really is, will have tomake a registration form. Actually, this form can be used for re-registration. You specify exactly the same data as before (email, mobile). Confirm that you have these data (letter, SMS). The system sees that such an account already exists, the data is 100% yours, but the token is different - it rewrites the token.



But still, it’s better not to lose the master key.

How to prevent loss? Create a backup copy, protect it with a password and store it on disposable media. Also, actually, as is done with the keys for bitcoin. In principle, you can translate the master keys into printed form and save them on a piece of paper. For that matter. And then restore by manual input. But this is for quite “paranoid” people like me.

But what if a master key is stolen from me?

This is already serious. Although the recommendations for storing the master key described here (not included in the protocol) protect them from direct tampering, keyloggers and trojans, nevertheless, the risk of compromising the master key remains. Unfortunately, perfect protection does not exist. The key can be hijacked directly from browser memory through a javascript engine vulnerability. As an example. Or do you lose your mobile phone ...



So what are the risks of stealing a master key?



Essential to receive information about you and even to take action on your behalf. Obtaining the ability for an attacker to log in under you and in read mode to gain access to sensitive information. Quiet and quiet.Or download all your private videos from classmates at once. It’s unpleasant for you. Fans of seals rejoice.



Here you need to quickly re-register with a new key on important sites. And, if something terrible happened, registering your new token in the database of the service provider in an official way is the only right option. You can think of a lot of registration methods: from paper fixation in an official letter, to an application through the site’s technical support service with confirmation of your identity in acceptable ways. But this is only for serious sites, such as online banking.

Ways to minimize risks. The use of individual keys for domains (but this reduces the mobility of accounts). Two-factor authentication via independent channels. The site shows the IP addresses and devices where the connection was from for the last time, so that you notice compromise at least in time.

4 Attacks on the authorization scheme

4.1 User Tracking

A site you trust can shamelessly merge information about you with other sites. On the Internet there are collector sites that aggregate such information and sell it to everyone. Yandex metrics, google analytics - a rare site does without them.



So that two different sites can determine that they are working with the same client, two techniques are used:

1. ( , ).
2. ( ) .

There is a slight drawback in Scheme 2: not the user is identified , but the browser. But often the browser == client.



It seems that the token is best suited for use in scheme No. 2. After all, if the user allowed to “remember” himself to two sites (acting as a pair), our permanent token can act as such a “fingerprint”, not just the browser, but the user himself. The problem for sites here is that they will receive different tokens .



But sites can try to apply also scheme No. 1. Then the following will turn out.



Site 1 will receive code H ₁ from the browser , and site 2, executed in the context of site 1, will receive code H ₂ . It seems now sites can form a pair (H ₁ , H₂ ) and even pass it on to some aggregator site.

Let there be another site 3, which is paired with site 2, trying to track you. Site 3 will receive the H ₃ token from the browser , and site 2, executed in the context of the site 3, will receive the H _{2 '} token ! = H ₂ (see how tokens are formed). As a result, combining the obtained data is impossible, because they have no overlapping parts.



But this does not mean that sites will not be able to use a fingerprint browser to monitor . It states only that the token generation scheme itself is quite reliable and protects against tracking.



Protection Option:Log out of sites you’ve finished working with. The browser can do this automatically when you close the tab.

4.2 XSS attack

XSS is a type of attack involving the introduction of malicious code into the victim.com website’s page. For example, through an affiliate script or a hacked CDN of a popular framework.



Malicious code can use user authorization on the site to gain authorized access to it or to steal user authentication data. Malicious code can be inserted into a page through a vulnerability in a web server (trivial hacking), through affiliate networks (unreliable sources), through a vulnerability on a user's computer (Trojan crawling).



The main protection against such attacks for our authorization scheme is special rules for generating the Source field when calculating tokens.



Vulnerability: for stored XSS (when a script is directly inserted into the attacked site and loaded from it as a result of hacking the server), protection will not work. Because the browser will not be able to identify such a script as “external”. The same problem will occur when an attacker proxies client-server traffic.

4.3 CSRF attack

The victim visits the site evil.com, created by an attacker. On her behalf, a request (GET / POST / HEAD / PUT / DELETE) is executed to a site where the user is already authorized (for example, to a payment system server). The request itself carries out some kind of malicious operation (for example, transferring money to the attacker's account). According to the oversight of the developers, the site does not check the Referer fields and does not request additional verification information from the user. As a result, the attack is successful.



The proposed site authorization scheme suppresses most CSRF attack scenarios, due to the token generation algorithm. Any cross-site request will result in the attacked site receiving an invalid token from the user. As a result, in this situation, the user for the attacked site will be anonymous anonymous. Even an attempt to execute a harmless GET request from an attacking site to an attacked one (loading a picture) will result in the latter receiving an invalid token.



This should greatly simplify the life of site developers.

4.4 Tracking using SSO

Two sites S ₁ and S ₂ , which the user trusts and has keys for them, decide to apply a technology similar to SSO for user tracking. But sinceyou cannot embed one site into another (one of them will receive an invalid token), you can’t open a partner’s site with a script (for the same reason), then site S ₁ decides to use a tricky technique.



On one of the pages, he places a translucent tag A that covers the entire window. The link leads to the site S ₂ , and the user identifier (from S ₁ ) and the token H _{1 are} transmitted in the address . The user does not see the link. By clicking on any area of ​​the site S ₁ , it initiates the opening of a new tab on the site S ₂ .



At the moment, S ₂ will not receive a valid token. Self-reloading with a tag will not help him either

 <meta http-equiv="refresh" content="0">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

or script.



But S ₂ can make the A tag on its entire page in the form of a fake Close button:







This link will first reload the site, then close it. At the time of the reboot, the browser will send the already valid H ₂ token to the S ₂ site (since rule 2.4 P1 has been fulfilled: the user has personally opened both links). As a result, S ₂ will receive information about the actions of its user on the site S ₁ , associate the H ₁ token with its H ₂ , and send H _{2 an} interserver request to S ₁ . In the future, sites S ₁ and S ₂ will be able to exchange any information about the user by server exchange, as now they can uniquely identify it mutually separately from each other



.

Mobile users are particularly vulnerable to this attack, as trying to close an unnecessary page may accidentally click on a fake link that occupies the entire mobile screen.

Protection method: automatically break the session when the tab is closed. Then the site S ₂ could not receive a valid token until the user himself logged in to it. True, this will not protect against situations when the user himself opened the tabs and logged in to S ₁ and S ₂ . And only then the sites carried out such an attack.

4.5 Key Compromise for SSO

Let a user account on an authentication server that supports SSO be compromised. We will evaluate the possible risks with our authentication scheme.



Tokens for each site are calculated individually based on domain keys.

Compromising one domain key does not automatically compromise all the others.

Most sites where you have previously logged in using SSO will probably save your token with your profile from the SSO server in their database. In our scheme, the site will simply pull up a token from the database and recognize you. Those.SSO server is no longer needed on such sites - it performed its function at the registration stage.



In other words, you do not automatically lose all your accesses at once. An attacker will be identified on the same sites as another person.



An attempt to re-conduct cross-domain authentication will not help the attacker either: the site should block attempts to create a new account with the old SSO Id-user and the new site token. Or, attempts to rewrite the user token for an existing Id in the SSO process should be blocked. The fact of this, should cause reasonable suspicion on the side of the site.

A user token can be legally changed in only one way (see "Scripting Scripts" ).



Risk.If the site does not save your token and profile in its database, but relies entirely on the SSO mechanism, then an attacker only needs to perform cross-domain authentication to log in using your name.



Minimization of risks in case of compromise. Oddly enough, but this is the preservation of tokens and user profiles by sites on their side. An attempt by an attacker to conduct cross-domain authentication can cause a conflict between the old Id-user and his new token. The situation itself, when the user has changed the token in any way other than that specified in the protocol, should be perceived suspiciously or rejected altogether.



Maximum risk:authorization on your behalf on other sites (where you have not been). Access to your profile data. Committing unlawful acts on your behalf. And so that the rightful owner could not return anything, the attacker can change his token on the authorization server in a legal way. This risk, however, coincides with the risks when using traditional authorization schemes.



Ways of protection. Refusal to use SSO (especially since the proposed scheme was conceived as a way to get away from centralized authentication schemes). Using multiple SSOs (do not store all eggs in one basket!).



If SSO supports two-factor authentication with authentication by other attributes (mail, phone), then there is the possibility of regaining control over the account of the authorization server.

4.6 Token compromise during transfer

It is clear that the proposed mechanism for hashing tokens during transfer does not give a 100% guarantee of their protection. An attacker can intercept the victim’s traffic at the time of the transfer of an insecure token (at the time of the primary registration of the permanent key), as an example. And then use it.



Therefore, the use of SSL is encouraged. But don't take HTTPS as a panacea. This protocol is also exposed, as well as HTTP. Only a little harder.



True, such a rare transfer of an open token, as well as the use of an individual token for each domain, reduces the risk of exploiting the vulnerability. Nevertheless.



Another danger is the interception and reuse of the token within the current user session. As I said earlier, ideally, the token should be hashed with a new salt at each client request. However, this will kill the possibility of parallel processing of requests on the server and make it impossible to send parallel requests from the client. Calculating and checking hashes is generally an expensive operation that reduces performance.

In addition, the token passed in the header should never be accessible from Javascript. Similar to Cookie with the HttpOnly flag. Even when receiving ajax requests by scripts.

Method of operation: intercepting a user’s request, retrieving the current token value, sending another operation with the same token (as on behalf of the same user). True, the classical system based on session cookies is also vulnerable to this type of attack.



Protection method: confirmation of significant operations through other communication channels, for example, via SMS or mail; pre-registration of the token through other communication channels (paper certificate, as an example).

4.7 Hacking a website and compromising tokens

Hacking sites occur constantly. Even large and well-protected sites break. There are many ways to break in: from a trivial injection to an insider "drain". Therefore, the compromise of your token on any site is a very likely event.



But the proposed protocol, just the same, makes the site hacking event the least painful for you.

The compromise of the token does not lead to the compromise of the domain key on the basis of which it was calculated. Also, this event does not lead to the compromise of your other tokens . And if so, then access to other sites remains inaccessible.

This is especially pleasant when keys to most sites are made using a master key: it is impossible to restore it by reverse engineering.



But at the same time, it is impossible to use the domain key whose token was compromised, for obvious reasons. Have to change the key.



The key for the domain where the official leak occurred can be made either on the basis of a random number or on the basis of a master key, with the addition of a version number:

$$

Conclusion

Several of my friends whom I showed the article asked me essentially the same question: "What is the main thing here?"





Oh, there is no main chip! Alas.But there are a number of details that make the protocol more profitable than the traditional login / password scheme.



1. You must have noticed this annoying popup on many sites.

“Our site saves cookies! Put on your helmet and be vigilant, because the big brother is watching you! Click "Yes", because you still have no choice. "

This is another popup to a bunch of other equally intrusive and very necessary. And all this is thanks to the European GDPR (an analogue of our PD law).



So here. In our scheme, cookies are no longer needed for identification purposes! From the word "completely."The user decides whether to allow the site to identify it, and when and for how long. Minus one annoying popup, +1 to the karma of the protocol.



2. The developer no longer needs to do authorization and password recovery forms. There is no need to implement complex SSO algorithms and master complex libraries: OAuth, SAML, Kerberos, etc., go through the procedure for registering your site, change authorization keys, monitor their security; and if something went wrong with SSO, urgently understand: "what went wrong, and why." Moreover, the authorization server may block your site for unknown reasons. Go figure it out. Yesterday everything worked, but today ... And here it’s enough to just read the token from the header and check if there is one in our database. Simple = reliable .







3. The user does not need to enter and remember a bunch of passwords. Use the services of third-party sites or it is not known by whom and how written programs. You can not be afraid of access to a computer by third parties, keyloggers and trojans. It is enough to make a backup copy of the master key, protect it with a password and store it somewhere on a USB flash drive. Like a bitcoin wallet. What is not a feature?



4. If the site is hacked, you do not risk anything. Well, regenerate the key again. While the password leaked to the site’s crackers can cause a lot of trouble.



5. The protocol was created taking into account the experience of known network attacks. Its architecture already includes basic protection against XSS, CSRF. Again, webmasters will be easier to develop sites. And their users - calmer.



6. Independence of the protocol from a specific service provider and its whims. The protocol makes you free.



7. Finally, the proposed protocol claims the future open standard . And the standard, if adopted by the participants, imposes obligations to implement the functionality according to the specification , and not to fence the collective farm out of its own authorization decisions, once again inventing the form of login, registration, password recovery, logout. And do not mess with password hashing or SQL injection.



And most importantly, like any open standard, it can and should be verifiedindependent experts. Even if the author of the original version of the protocol “messed up” in details, the online community can timely identify this fix. Well, or send my protocol to the scrap. Alas for me, and "pooh-carried" for everyone else.

- I think I should stop on this

E. Wiles

---

PS

You can familiarize yourself with the option of a full-length article in an offline format. When typesetting material on Habr, I could make typos. If you have serious comments, it is better to check the original and leave article comments (reviews) in this file . Send me your changes to the mail sergey201991 [] gmail. I am not an octopus, but I will try to answer. I will add multiple matching / interesting comments to this article. Together with the answers to them. A variant of a separate comment article is not ruled out.



Yes, I know that the protocol may have problems:

1. there is no way to log in under your account on someone else’s device if you do not have a key at hand, but you need it urgently; passwords are more convenient here
2. ; , SSO
3. «», - : - ( )
4. -

Regarding p. 1 - I was seriously thinking about returning to the idea of ​​generating a domain key based on a password, making protection against brute force by complicating the process of generating the key: say, increasing the number of hash rounds to 1000. But the problem with the possible collision of passwords for different users on one The site haunts me.



Regarding p. 2 - this is treated by time. You need to get used to the new interfaces. At first it will not be clear, then it will be simple. Give a man of the 80s a modern smartphone, he would also not have guessed how to manage it.



Thank you so much if you read it to the end!