Security when authorizing on sites using OpenID
OpenID is an open, decentralized system that allows a user to use a single account for authentication on a variety of unrelated sites, portals, blogs and forums. If the WEB site assumes the use of user authentication or authorization, then possible options for implementing this are listed below:
1) Use standard registration by entering email and filling in the required data.
2) Use authentication by specifying the personal identifier of the OpenID provider.
3) Use authorization through the open protocol OAuth
Support for the second and third methods is one of the advantages, which should increase the number of registered users.
')
1) Purpose of using OpenID authorization
The main purpose of using OpenID is to simplify user registration. Simplification is achieved in a decentralized single sign-on system, which allows you to use one login and password on a large number of sites. On sites that support OpenID, users do not have to register and remember the data for each site every time. Instead, it is enough for them to be registered on the site of the OpenID identification provider (providing the identifier). Since OpenID technology is decentralized, any site can use OpenID software as a means of entry. Convenience of OpenID also lies in the fact that when logging in via OpenID, the user's personal data (email, name, gender, date of birth, etc.) can be immediately transferred to the visited site and he will not have to enter this information every time - it’s enough to do it once on the site OpenID provider.
2) OpenID authorization principle
The principle of OpenID authorization, we consider an example.
The user through the WEB browser comes to some of his site of interest (according to official terminology in OpenID - Relying Party, RP). Suppose that the user further wants to leave a comment on one of the site’s blogs. Without the support of the OpenID technology site, the user will be asked to register, which means creating or receiving the next login and password. If the site supports the OpenID technology, then next to the registration field will be indicated by the entrance to OpenID (most often indicated by the OpenID logo). Next, the user can enter the OpenID address — the address of the user's personal page on the OpenID provider server (OP). For example, if a user received his OpenID on the Yandex website, then this OpenID has the form username.ya.ru (“username” is the username of yandex.ru). The further authorization process is shown in the diagram below.
The following screenshots are shown when authorizing on the site www.livejournal.com using the OpenID identifier issued by the OpenID provider myopenid.com
a. The user wants to write a comment on the site www.livejournal.com . However, it has not yet been registered on the site, but it has the OpenID identifier with the provider myopenid.com
b. User opens the site www.livejournal.com
c. Next, the user selects the authorization method through OpenID and logs in to the site of the OpenID provider.
d) The OpenID provider prompts you to enter a password that was entered earlier by the user during the creation of an OpenID account. Next, we consider below what features should be addressed to the user at this step.
e) the user enters his login and password for the OpenID provider, after which the user is authenticated on the site www.livejournal.com .
f) after a moment, www.livejournal.com appears in the browser, where the user is already authenticated and can write comments.
3) OpenID Analogs
In addition to OpenID, there are other ways to use the resources of the site without registering.
a) First of all, we will consider single sign-on technology through “Single sign on”. The technologies are very similar in the way they work, but there are some differences:
- If there are several extensive independent sections on the web portal (forum, chat, blog, etc.), after having passed the authentication procedure using Single sign on technology in one of the services, a person automatically gets access to all the rest, which saves him from multiple data entry of your account. Here, the OpenID and Single sign on functions are similar.
- “Single sign on”, in contrast to OpenID, is centralized, which implies the ability to use the account only within a certain system, for example, within the corporate network. For example, the user leads the username and password and authentication takes place in a certain trusted corporate resource (for example, Active Directory). Further, automatic authorization is possible in many applications and programs of this corporate network (including IE). If a user leaves the corporate network, he will not be able to use the Single sign on account.
b) Open OAuth authentication protocol. It allows you to provide a third party with limited access to the user's protected resources without the need to give her (a third party) a login and password. Examples of OAuth providers can be found at ru.wikipedia.org/wiki/OAuth . There is a misconception that OAuth is an extension of the OpenID protocol; in fact, it is not. Although OpenID and OAuth have a lot in common, the latter is an independent protocol that is not related to OpenID.
OAuth is an authorization protocol that allows you to grant rights to use a resource (for example, the API of a service). For example, I log in via OpenID on livejournal.com through OAuth provider vkontakte.ru, the latter can provide constant access to some user information.
OpenID is a means of authentication: with the help of this system, you can make sure that the user is exactly who he claims to be. What actions a user who is authenticated through OpenID can perform is determined by the party performing the authentication.
4) Large OpenID providers and writing their own OpenID server
Some list of OpenID providers is available at openid.net/get-an-openid . When choosing an OpenID provider, the user needs to be careful, since it’s not a fact that the small provider will not distribute user data to the outside and that this provider will not close in a year, which will lead to the need to create a new OpenID identifier from another provider.
For advanced users, it is possible to authorize via OpenID with the URL of your site (for example, www.ivan-petrov.ru ), which, in turn, will forward the authorization request to the OP (OpenID provider) specified in the HTML header. In this case, when changing the OpenID provider, it is enough to change the code of your main HTML page, and the URL for authorization by OpenID remains the same - in our example, www.ivan-petrov.ru . Using your site as an OpenID identifier is possible on those sites that offer to log in by entering the OpenID URL. On LiveJournal.com this is possible.
If a user doesn’t trust third-party OpenID providers at all, then with little programming skills he can write his own OpenID server and use it both for his authorization and for distributing OpenID identifiers to other users (see an example on www.opennet.ru/base/dev/ openid_server.txt.html ).
5) OpenID security analysis
Unfortunately, the OpenID technology specification (currently OpenID Authentication 2.0) does not describe how security is guaranteed when using OpenID.
In this regard, on the Internet, long discussions are held on how to get confidential user data (for example, a password to your OpenID account) by hackers. Ben Laurie described a simple scenario in which your login / password to an OpenID provider (OP), for example, LiveJournal, can be easy prey to phishers if you are not careful. In general terms, the script is as follows:
a) A user visits a certain site, for example, to view photos. If the user wants to leave a comment under the photo, then the only thing that asks the site is to register or authenticate using OpenID. The user selects OpenID, writes there, for example, user_xxx.livejournal.com, and submits the form.
b) According to the general operation of OpenID, users should now be sent to www.livejournal.com/openid/server.bml . If the user is already authenticated with livejournal.com, then a photo with a photo will be returned with a sign of successful authentication and additional parameters will be sent. If not, LiveJournal will ask for a login / password first. This is in theory. In practice, a website with photos may belong to attackers, and instead of OP, the endpoint can send the user to your proxy by disguising the url accordingly, for example www.livejournal.com/openid/server.bml?lot_of_junk@evilcats.example.com . The user will see in front of him the same page from livejournal.com, on which you need to enter your data, only it will be shown through a proxy evilcats.example.com and the login / password to livejournal.com will remain in the logs of the proxy server. Thus, if the user does not closely monitor the URL on which the page he enters his username and password, then there is a chance that the attackers will get this data. This fact is a deterrent to the rapid spread of OpenID technology.
Some users blogging on OpenID are actively discussing how to avoid the above scenario. For example, the following methods of protection are proposed:
a) One-time password generation option:
- organization of the SSL channel between the user from the OpenID provider
- the presence on the user's PC of a special cookie, which is recorded when you first access the site of the OpenID provider
- The cookie is sent to the user when confirming the password sent to his OpenID email provider. Also, cookies are stored on the side of the OpenID provider, and which must match.
- Cookies are sent over SSL to the user's PC only after correct password entry
- With subsequent OpenID authentication on various sites, the OpenID provider checks the cookie with the one received from the PC and then displays a special picture that only the user knows and which is uploaded on the OpenID server of the provider. If the user does not see this picture, it means that there is no real communication with the OpenID server.
This method allows you to improve OpenID authentication, but requires enabled cookies in the browser, and an additional link appears in the form of an email password.
b) Another, more universal way to increase security when using OpenID is the emergence of special plug-ins in the user's browser. Without this plugin, it is not recommended to enter the OpenID password to the user. However, it is not a fact that these plugins will be done by all the major browser developers.
c) And the third way is to use SSL certificates when authenticating with an OpenID provider. This method, on the one hand, improves security and facilitates authentication, since the user does not need to enter a password. On the other hand, a certificate can be obtained by an attacker through Trojans. In addition, support for SSL certificates is only for large OpenID providers, such as myopenid.com.
It should also be noted that some OPs do not accept OpenID registered with another OP and this somewhat changes the definition of the SINGLE OpenID identifier.
6) Standards
- OpenID Authentication 2.0
openid.net/specs/openid-authentication-2_0.html
- OpenID Attribute Exchange 1.0
openid.net/specs/openid-attribute-exchange-1_0.html
- OpenID Simple Registration Extension 1.0
openid.net/specs/openid-simple-registration-extension-1_0.html
- Yadis Discovery Protocol (Developed separately from OpenID)
svn.infogrid.org/infogrid/docs/yadis/yadis-v1.0.pdf
findings
1. OpenID technology is a convenient authentication method on sites that support this technology.
2. The OpenID owner does not need to store multiple passwords for various sites and provide his email address, he only needs to know the URL to his OpenID account and the password to it.
3. When authenticating and maintaining an active session on the site of the OpenID provider, authentication on other sites via OpenID will take place without entering a password, only by specifying the URL of your OpenID.
4. The specification of version 2.0 does not provide the proper level of security when using OpenID. Improvement of security is possible in new versions of specifications or in the development and use of special plug-ins for Web browsers (for PC / PDA / Mobile browsers). So far, for increased security, experienced users can advise registration with OpenID providers that provide SSL certificates.
5. Developers of WEB sites and services can easily add OpenID authentication functionality, since all the necessary libraries for this are freely provided. OpenID authentication support significantly increases the usability of the site, which is a prerequisite for the development of this concept.
1) Use standard registration by entering email and filling in the required data.
2) Use authentication by specifying the personal identifier of the OpenID provider.
3) Use authorization through the open protocol OAuth
Support for the second and third methods is one of the advantages, which should increase the number of registered users.
')
1) Purpose of using OpenID authorization
The main purpose of using OpenID is to simplify user registration. Simplification is achieved in a decentralized single sign-on system, which allows you to use one login and password on a large number of sites. On sites that support OpenID, users do not have to register and remember the data for each site every time. Instead, it is enough for them to be registered on the site of the OpenID identification provider (providing the identifier). Since OpenID technology is decentralized, any site can use OpenID software as a means of entry. Convenience of OpenID also lies in the fact that when logging in via OpenID, the user's personal data (email, name, gender, date of birth, etc.) can be immediately transferred to the visited site and he will not have to enter this information every time - it’s enough to do it once on the site OpenID provider.
2) OpenID authorization principle
The principle of OpenID authorization, we consider an example.
The user through the WEB browser comes to some of his site of interest (according to official terminology in OpenID - Relying Party, RP). Suppose that the user further wants to leave a comment on one of the site’s blogs. Without the support of the OpenID technology site, the user will be asked to register, which means creating or receiving the next login and password. If the site supports the OpenID technology, then next to the registration field will be indicated by the entrance to OpenID (most often indicated by the OpenID logo). Next, the user can enter the OpenID address — the address of the user's personal page on the OpenID provider server (OP). For example, if a user received his OpenID on the Yandex website, then this OpenID has the form username.ya.ru (“username” is the username of yandex.ru). The further authorization process is shown in the diagram below.
The following screenshots are shown when authorizing on the site www.livejournal.com using the OpenID identifier issued by the OpenID provider myopenid.com
a. The user wants to write a comment on the site www.livejournal.com . However, it has not yet been registered on the site, but it has the OpenID identifier with the provider myopenid.com
b. User opens the site www.livejournal.com
c. Next, the user selects the authorization method through OpenID and logs in to the site of the OpenID provider.
d) The OpenID provider prompts you to enter a password that was entered earlier by the user during the creation of an OpenID account. Next, we consider below what features should be addressed to the user at this step.
e) the user enters his login and password for the OpenID provider, after which the user is authenticated on the site www.livejournal.com .
f) after a moment, www.livejournal.com appears in the browser, where the user is already authenticated and can write comments.
3) OpenID Analogs
In addition to OpenID, there are other ways to use the resources of the site without registering.
a) First of all, we will consider single sign-on technology through “Single sign on”. The technologies are very similar in the way they work, but there are some differences:
- If there are several extensive independent sections on the web portal (forum, chat, blog, etc.), after having passed the authentication procedure using Single sign on technology in one of the services, a person automatically gets access to all the rest, which saves him from multiple data entry of your account. Here, the OpenID and Single sign on functions are similar.
- “Single sign on”, in contrast to OpenID, is centralized, which implies the ability to use the account only within a certain system, for example, within the corporate network. For example, the user leads the username and password and authentication takes place in a certain trusted corporate resource (for example, Active Directory). Further, automatic authorization is possible in many applications and programs of this corporate network (including IE). If a user leaves the corporate network, he will not be able to use the Single sign on account.
b) Open OAuth authentication protocol. It allows you to provide a third party with limited access to the user's protected resources without the need to give her (a third party) a login and password. Examples of OAuth providers can be found at ru.wikipedia.org/wiki/OAuth . There is a misconception that OAuth is an extension of the OpenID protocol; in fact, it is not. Although OpenID and OAuth have a lot in common, the latter is an independent protocol that is not related to OpenID.
OAuth is an authorization protocol that allows you to grant rights to use a resource (for example, the API of a service). For example, I log in via OpenID on livejournal.com through OAuth provider vkontakte.ru, the latter can provide constant access to some user information.
OpenID is a means of authentication: with the help of this system, you can make sure that the user is exactly who he claims to be. What actions a user who is authenticated through OpenID can perform is determined by the party performing the authentication.
4) Large OpenID providers and writing their own OpenID server
Some list of OpenID providers is available at openid.net/get-an-openid . When choosing an OpenID provider, the user needs to be careful, since it’s not a fact that the small provider will not distribute user data to the outside and that this provider will not close in a year, which will lead to the need to create a new OpenID identifier from another provider.
For advanced users, it is possible to authorize via OpenID with the URL of your site (for example, www.ivan-petrov.ru ), which, in turn, will forward the authorization request to the OP (OpenID provider) specified in the HTML header. In this case, when changing the OpenID provider, it is enough to change the code of your main HTML page, and the URL for authorization by OpenID remains the same - in our example, www.ivan-petrov.ru . Using your site as an OpenID identifier is possible on those sites that offer to log in by entering the OpenID URL. On LiveJournal.com this is possible.
If a user doesn’t trust third-party OpenID providers at all, then with little programming skills he can write his own OpenID server and use it both for his authorization and for distributing OpenID identifiers to other users (see an example on www.opennet.ru/base/dev/ openid_server.txt.html ).
5) OpenID security analysis
Unfortunately, the OpenID technology specification (currently OpenID Authentication 2.0) does not describe how security is guaranteed when using OpenID.
In this regard, on the Internet, long discussions are held on how to get confidential user data (for example, a password to your OpenID account) by hackers. Ben Laurie described a simple scenario in which your login / password to an OpenID provider (OP), for example, LiveJournal, can be easy prey to phishers if you are not careful. In general terms, the script is as follows:
a) A user visits a certain site, for example, to view photos. If the user wants to leave a comment under the photo, then the only thing that asks the site is to register or authenticate using OpenID. The user selects OpenID, writes there, for example, user_xxx.livejournal.com, and submits the form.
b) According to the general operation of OpenID, users should now be sent to www.livejournal.com/openid/server.bml . If the user is already authenticated with livejournal.com, then a photo with a photo will be returned with a sign of successful authentication and additional parameters will be sent. If not, LiveJournal will ask for a login / password first. This is in theory. In practice, a website with photos may belong to attackers, and instead of OP, the endpoint can send the user to your proxy by disguising the url accordingly, for example www.livejournal.com/openid/server.bml?lot_of_junk@evilcats.example.com . The user will see in front of him the same page from livejournal.com, on which you need to enter your data, only it will be shown through a proxy evilcats.example.com and the login / password to livejournal.com will remain in the logs of the proxy server. Thus, if the user does not closely monitor the URL on which the page he enters his username and password, then there is a chance that the attackers will get this data. This fact is a deterrent to the rapid spread of OpenID technology.
Some users blogging on OpenID are actively discussing how to avoid the above scenario. For example, the following methods of protection are proposed:
a) One-time password generation option:
- organization of the SSL channel between the user from the OpenID provider
- the presence on the user's PC of a special cookie, which is recorded when you first access the site of the OpenID provider
- The cookie is sent to the user when confirming the password sent to his OpenID email provider. Also, cookies are stored on the side of the OpenID provider, and which must match.
- Cookies are sent over SSL to the user's PC only after correct password entry
- With subsequent OpenID authentication on various sites, the OpenID provider checks the cookie with the one received from the PC and then displays a special picture that only the user knows and which is uploaded on the OpenID server of the provider. If the user does not see this picture, it means that there is no real communication with the OpenID server.
This method allows you to improve OpenID authentication, but requires enabled cookies in the browser, and an additional link appears in the form of an email password.
b) Another, more universal way to increase security when using OpenID is the emergence of special plug-ins in the user's browser. Without this plugin, it is not recommended to enter the OpenID password to the user. However, it is not a fact that these plugins will be done by all the major browser developers.
c) And the third way is to use SSL certificates when authenticating with an OpenID provider. This method, on the one hand, improves security and facilitates authentication, since the user does not need to enter a password. On the other hand, a certificate can be obtained by an attacker through Trojans. In addition, support for SSL certificates is only for large OpenID providers, such as myopenid.com.
It should also be noted that some OPs do not accept OpenID registered with another OP and this somewhat changes the definition of the SINGLE OpenID identifier.
6) Standards
- OpenID Authentication 2.0
openid.net/specs/openid-authentication-2_0.html
- OpenID Attribute Exchange 1.0
openid.net/specs/openid-attribute-exchange-1_0.html
- OpenID Simple Registration Extension 1.0
openid.net/specs/openid-simple-registration-extension-1_0.html
- Yadis Discovery Protocol (Developed separately from OpenID)
svn.infogrid.org/infogrid/docs/yadis/yadis-v1.0.pdf
findings
1. OpenID technology is a convenient authentication method on sites that support this technology.
2. The OpenID owner does not need to store multiple passwords for various sites and provide his email address, he only needs to know the URL to his OpenID account and the password to it.
3. When authenticating and maintaining an active session on the site of the OpenID provider, authentication on other sites via OpenID will take place without entering a password, only by specifying the URL of your OpenID.
4. The specification of version 2.0 does not provide the proper level of security when using OpenID. Improvement of security is possible in new versions of specifications or in the development and use of special plug-ins for Web browsers (for PC / PDA / Mobile browsers). So far, for increased security, experienced users can advise registration with OpenID providers that provide SSL certificates.
5. Developers of WEB sites and services can easily add OpenID authentication functionality, since all the necessary libraries for this are freely provided. OpenID authentication support significantly increases the usability of the site, which is a prerequisite for the development of this concept.
Source: https://habr.com/ru/post/142925/
All Articles