Dive into the blockchain technology: Decentralized password-free security system
Talking about the technological side of the blockchain in the articles from the series “Immersion in the Blockchain Technology” we faced the questions: “Why is this necessary? What problems solves? How to use? ”Therefore, it was decided to dedicate this material to the answers using emcSSL as an example — the WWW user identification system based on the NVS subsystem, EmerCoin cryptocurrency and decentralized client SSL certificates.
1. A series of materials on Emer technology:
1.1. The secrets of EmerCoin .
1.2. Decentralized uncensored domain name system .
1.3. Worldwide public key infrastructure .
1.4. Decentralized password-free security system .
2. Fast and secure transactions .
3. Ecosystem of digital dentistry .
4. Combating counterfeit goods .
5. Mutual insurance of animals .
6. What is ICO and how to conduct it .
7. Loading ...
As you know, the most common way to authenticate a user is a password. This practice has historical roots and is based on the paradigm of gaining access to a trusted device (computer). This approach worked well in the past, when the computer was isolated from the network, and just like that no trojan could intercept the password, and even if it could, it couldn’t use it anywhere, because why did the trojan password, which is already in the computer? wielding?
')
This paradigm, ideal for personal computers, began to give up slack in multi-user systems, where the hacker, having unprivileged access, ran a program on his terminal that simulated a standard login, and thus left a trap for the next operator. Such systems had limited popularity in the student environment of the 80s, when a particularly sneaky student, instead of completing the session, left behind such a trap in a computer class. A kind of modern phishing.
And this paradigm does not at all satisfy the security conditions of modern systems, where untrusted can be a device, a network connection, or even a server.
A recent example is the seizure of the blockchain.info domain, followed by capturing users 'passwords with a fake website and stealing Bitcoins from users' accounts. Eight million accounts were potentially compromised. At the same time, the site itself was not hacked, but the network infrastructure was hacked, which made it possible to “catch” passwords with a fake website.
There are also incidents involving the hacking of popular sites and the “dumping” of user databases, including password hashes.
For example, several recent high-profile incidents:
It is no longer possible to write off such incidents as an “exceptional special case,” one can say that the system can be traced. Of course, we will not argue - each hacking was unique in its own way, but the result is the same - a massive compromise of user accounts, reputational losses of sites and organizations, and in some cases - significant financial losses both for users and for sites and their owners .
Looking at the current plight of things, two eternal Russian questions arise, formulated by Herzen and Chernyshevsky:
Let's try to answer them in order.
Obviously, the main fault lies with the outdated password authentication system, which was good for a single-user PC, but not suitable for the modern network-centric world.
The key disadvantage of password authentication is that the operator, by presenting a password to the device, fully discloses his secret. For a trusted device, it's not scary. But in the case of an untrusted device, or intruder intrusion, the latter, by intercepting the password, gets full access to user accounts. In other words, a user, once having uncovered a password, becomes defenseless against malicious actions “on the other side of the monitor”. And since it is unlikely that any device in the modern networked world can be considered trusted, the theft of passwords becomes inevitable and systematic. Attempts to improve this system by forcing users to frequently change passwords - annoying users, creating a lot of problems for them, and in fact is a palliative solution. The same palliative solution is modern two-factor authorization systems based on SMS, which require confirmation of ownership of another untrusted device connected to another untrusted network.
The second key disadvantage is the centralization of accounts, that is, their storage in huge databases. If only the UserID would be contained in the account, the “overflow” of such a database would not lead to a catastrophe - after all, just the UserID is not secret information. But the databases, along with the UserID, also store other information that is not subject to disclosure - for example, password hashes. Yes, the hash of course - not the password. But having the appropriate dictionary, the hashes can recover a significant part of the passwords of the merged database, about a third. In addition, heuristic attacks on weak passwords also add something. And then - the secret is known, and the keys in the hands of the attacker.
Summarizing the above - we have:
It should be noted that the fulfillment of both of the above conditions makes hacking useful for an intruder from the practical side.
So, if it was impossible to recover passwords from the merged database, then its value would be very doubtful (although personal data may also be of interest), since it would be impossible to access the account anyway.
Also, the centralized storage of accounts makes the idea of hacking and draining the database attractive to intruders. Indeed, if there were no centralized storage, there would be no mass drains, as in the above examples.
In general, we are all guilty because we use architecture that does not meet modern requirements. Both site owners and users who agree to use it.
As noted above, the systematic compromise of the user base makes sense in the case of using both mechanisms of an outdated architecture - passwords with full secret disclosure, and centralization, which makes the theft of the user base with their passwords attractive and cost-effective. The rejection of any of these mechanisms (or better, both at once) will make senseless hacking, similar to those discussed above.
In other words, a new authentication architecture is needed, which:
a. Does not reveal the user's secret during the authentication process to the server.
b. Uses decentralized storage of accounts.
Ideally, the server should know only the UserID of the user, and nothing more.
It cannot be said that no attempts were made to replace password authentication. For example, in order to avoid the full disclosure of a user's secret, user-defined SSL certificates have received limited use. When using them, the public part of the certificate is presented to the server, and the private key never leaves the user's computer, which solves the problem (a). But the purchase of such certificates costs some money and is fraught with hassle, as a result of which such systems have become very limited even in the corporate sector.
In addition, the issuance of these certificates is also centralized, which exacerbates the issue of centralization already at the level of the certifier, and its compromise also leads to mass compromise of users. In the case of a compromise of a certifier on a state scale or worldwide, losses will be immeasurably higher than when a particular site is compromised. And although this phenomenon is less likely than hacking the site, it cannot be ruled out, and such incidents have already taken place, for example, the story of DigiNotar is quite indicative.
For a long time, the problem of centralization did not have a good solution. However, the emergence of the cryptocurrency phenomenon and a public blockchain provided with independent trust gave the world a tool on the basis of which a new authentication architecture can be built that satisfies both conditions - (a, b).
Based on this tool, such an architecture was created, and has been in operation for over a year. Meet the heroes of our time - emcSSL + InfoCard!
The description of the architecture and operation mechanisms of both systems are described in detail here .
Now, the answer to the eternal question number 2 has become clear.
Below we take a quick look at how the proposed architecture helps in solving questions (a, b).
As mentioned above, the client SSL certificate system solves the problem of full disclosure of the secret (a). However, for a number of reasons, including those listed above, it does not scale very well, and has not received wide distribution.
There is no certificate authority in the emcSSL system, and the users themselves issue certificates. Accordingly, issuing a certificate is by definition free. The Blockchain EmerCoin acts only as a public trusted repository of SSL certificate hashes and ensures the uniqueness of Serial, which is a unique UserID.
Thus, in the emcSSL system, both problems were successfully solved - both non-disclosure of the secret (a) and decentralization (b), which allows the system to be scaled to the global level. The user of the emcSSL system receives a kind of “pass-all-terrain vehicle”, which does not depend on anyone except the user. Not from the “site on the Internet,” not from the certifier, or from anyone else. Accordingly, the system does not allow attacks of the type discussed above, which lead to a massive compromise of accounts, because private keys are generated by users and never leave their computers, and there simply is no such central place that can be compromised.
In particularly important cases, it is advisable to use emSSL with a password in the framework of two-factor authentication . In this case, emcSSL authorizes the device and provides a secure channel of communication with the server, and the password authorizes the operator.
It is also worth mentioning that the emcSSL blockchain architecture effectively and safely solves the problem of revoking a compromised certificate and its quick replacement, which compares favorably with CRL and OCSP protocol, which is vulnerable to the MItM attack.
So, the emcSSL system solves all the tasks. Compromise of any server does not lead to compromise of accounts, since the password is not stored in any form on the server. However, the server may store additional information about the user that is of interest to the attacker, such as a phone number, home address, and the like. In an amicable way, it is highly desirable that this information is not stored on the server either. Some online stores do this for security reasons - they allow the user to make a purchase as a “guest”, and do not save information about the user after making a purchase. The approach is certainly barbaric, but true. At least in terms of security.
An ideal user account system on the server side should have information about it when this information is required (say, at the time of the purchase), and not contain it when the attacker who received the base is trying to merge it.
The InfoCard system does just that. User information (info card) is created by the user himself, encrypted and placed on the Emercoin blockchain. When a user logs in with an emcSSL certificate, the certificate contains a link to the info card and the decryption key. The server at this moment can extract the contents of the info card and use it - for example, take the delivery address of the order and fill it with the contents of the order form field. After making a purchase, the server “forgets” the contents of the info card - until the next user login. As a result, only the UserID can be stored in the account on the server, and nothing else. No password, no personal user data. Not too rich catch for a cracker, is it? Accordingly, if there is nothing to take from the server, they will most likely not try to hack it.
In addition, it is worth noting that the InfoCard system, besides enhancing security, enhances user convenience, since:
The emcSSL system was open for public use about a year ago. During this year, the system was put into commercial operation by a number of organizations and websites. Some of the uses we know of are listed below:
First, we advise you to read the detailed article in which you will find the most basic. Then you can explore the video , which shows step by step how the operator generated his SSL certificate and placed it in EmerCoin blockchain.
This classic way, when the user generates a certificate himself and publishes his hash to NVS, is the most correct in terms of security. For in this case, the user believes only himself, and his private key is generated locally and never leaves the user's device.
If you consider it acceptable to entrust your security to an external site, as it happens in the case of a login through social networks, then you can order a certificate online on the Cryptor site for free , and then place your hash in NVS on your own. If you wish, you can then generate another certificate locally and update its hash in NVS, which will raise your security to the “classic” level.
If you don’t want to contact EmerCoin at all, but nevertheless use the emcSSL system, then you can use the service from Remme , which provides a service of password-free authorization based on emcSSL technology. It is clear that in this case the company becomes your trusted agent.
You can check the work of the newly generated certificate and info card on the emcSSL website. From there, you can also download scripts for generating certificates, as well as two variants of the PHP server application, as well as an archived copy of the entire site. By deploying this copy on your own, you can see from the inside how it all works and use it as the basis for integrating emcSSL into your site.
In conclusion, we want to share a good article about creating a server application for using authorization through emcSSL.
Oleg Hovayko is a leading cryptocurrency developer EmerCoin, an expert in the field of cryptography and computer security. Since 1994 he has been working in IT. Currently, he is also the vice-president of the American investment bank, which makes operations with securities - Jefferies & Company. Which is considered one of the largest independent US banks.
The series of articles "Immersion in technology blockchain"
1. A series of materials on Emer technology:
1.1. The secrets of EmerCoin .
1.2. Decentralized uncensored domain name system .
1.3. Worldwide public key infrastructure .
1.4. Decentralized password-free security system .
2. Fast and secure transactions .
3. Ecosystem of digital dentistry .
4. Combating counterfeit goods .
5. Mutual insurance of animals .
6. What is ICO and how to conduct it .
7. Loading ...
What's happening?
As you know, the most common way to authenticate a user is a password. This practice has historical roots and is based on the paradigm of gaining access to a trusted device (computer). This approach worked well in the past, when the computer was isolated from the network, and just like that no trojan could intercept the password, and even if it could, it couldn’t use it anywhere, because why did the trojan password, which is already in the computer? wielding?
')
This paradigm, ideal for personal computers, began to give up slack in multi-user systems, where the hacker, having unprivileged access, ran a program on his terminal that simulated a standard login, and thus left a trap for the next operator. Such systems had limited popularity in the student environment of the 80s, when a particularly sneaky student, instead of completing the session, left behind such a trap in a computer class. A kind of modern phishing.
And this paradigm does not at all satisfy the security conditions of modern systems, where untrusted can be a device, a network connection, or even a server.
A recent example is the seizure of the blockchain.info domain, followed by capturing users 'passwords with a fake website and stealing Bitcoins from users' accounts. Eight million accounts were potentially compromised. At the same time, the site itself was not hacked, but the network infrastructure was hacked, which made it possible to “catch” passwords with a fake website.
There are also incidents involving the hacking of popular sites and the “dumping” of user databases, including password hashes.
For example, several recent high-profile incidents:
- Adultfriendfinder - 412 million user accounts stolen ;
- OPM (US Public Service Base) - 22 million records stolen ;
- Domestic hackers are also not lagging behind - Hacking “VKontakte” has compromised 171 million user accounts .
It is no longer possible to write off such incidents as an “exceptional special case,” one can say that the system can be traced. Of course, we will not argue - each hacking was unique in its own way, but the result is the same - a massive compromise of user accounts, reputational losses of sites and organizations, and in some cases - significant financial losses both for users and for sites and their owners .
Looking at the current plight of things, two eternal Russian questions arise, formulated by Herzen and Chernyshevsky:
- Who is guilty?
- What to do?
Let's try to answer them in order.
Who is guilty?
Obviously, the main fault lies with the outdated password authentication system, which was good for a single-user PC, but not suitable for the modern network-centric world.
The key disadvantage of password authentication is that the operator, by presenting a password to the device, fully discloses his secret. For a trusted device, it's not scary. But in the case of an untrusted device, or intruder intrusion, the latter, by intercepting the password, gets full access to user accounts. In other words, a user, once having uncovered a password, becomes defenseless against malicious actions “on the other side of the monitor”. And since it is unlikely that any device in the modern networked world can be considered trusted, the theft of passwords becomes inevitable and systematic. Attempts to improve this system by forcing users to frequently change passwords - annoying users, creating a lot of problems for them, and in fact is a palliative solution. The same palliative solution is modern two-factor authorization systems based on SMS, which require confirmation of ownership of another untrusted device connected to another untrusted network.
The second key disadvantage is the centralization of accounts, that is, their storage in huge databases. If only the UserID would be contained in the account, the “overflow” of such a database would not lead to a catastrophe - after all, just the UserID is not secret information. But the databases, along with the UserID, also store other information that is not subject to disclosure - for example, password hashes. Yes, the hash of course - not the password. But having the appropriate dictionary, the hashes can recover a significant part of the passwords of the merged database, about a third. In addition, heuristic attacks on weak passwords also add something. And then - the secret is known, and the keys in the hands of the attacker.
Summarizing the above - we have:
- Password system with full disclosure of the secret that does not meet modern requirements.
- Centralized storage of user data, which leads to catastrophic consequences if the database is compromised.
It should be noted that the fulfillment of both of the above conditions makes hacking useful for an intruder from the practical side.
So, if it was impossible to recover passwords from the merged database, then its value would be very doubtful (although personal data may also be of interest), since it would be impossible to access the account anyway.
Also, the centralized storage of accounts makes the idea of hacking and draining the database attractive to intruders. Indeed, if there were no centralized storage, there would be no mass drains, as in the above examples.
In general, we are all guilty because we use architecture that does not meet modern requirements. Both site owners and users who agree to use it.
What to do?
As noted above, the systematic compromise of the user base makes sense in the case of using both mechanisms of an outdated architecture - passwords with full secret disclosure, and centralization, which makes the theft of the user base with their passwords attractive and cost-effective. The rejection of any of these mechanisms (or better, both at once) will make senseless hacking, similar to those discussed above.
In other words, a new authentication architecture is needed, which:
a. Does not reveal the user's secret during the authentication process to the server.
b. Uses decentralized storage of accounts.
Ideally, the server should know only the UserID of the user, and nothing more.
It cannot be said that no attempts were made to replace password authentication. For example, in order to avoid the full disclosure of a user's secret, user-defined SSL certificates have received limited use. When using them, the public part of the certificate is presented to the server, and the private key never leaves the user's computer, which solves the problem (a). But the purchase of such certificates costs some money and is fraught with hassle, as a result of which such systems have become very limited even in the corporate sector.
In addition, the issuance of these certificates is also centralized, which exacerbates the issue of centralization already at the level of the certifier, and its compromise also leads to mass compromise of users. In the case of a compromise of a certifier on a state scale or worldwide, losses will be immeasurably higher than when a particular site is compromised. And although this phenomenon is less likely than hacking the site, it cannot be ruled out, and such incidents have already taken place, for example, the story of DigiNotar is quite indicative.
For a long time, the problem of centralization did not have a good solution. However, the emergence of the cryptocurrency phenomenon and a public blockchain provided with independent trust gave the world a tool on the basis of which a new authentication architecture can be built that satisfies both conditions - (a, b).
Based on this tool, such an architecture was created, and has been in operation for over a year. Meet the heroes of our time - emcSSL + InfoCard!
The description of the architecture and operation mechanisms of both systems are described in detail here .
Now, the answer to the eternal question number 2 has become clear.
Below we take a quick look at how the proposed architecture helps in solving questions (a, b).
emcSSL
As mentioned above, the client SSL certificate system solves the problem of full disclosure of the secret (a). However, for a number of reasons, including those listed above, it does not scale very well, and has not received wide distribution.
There is no certificate authority in the emcSSL system, and the users themselves issue certificates. Accordingly, issuing a certificate is by definition free. The Blockchain EmerCoin acts only as a public trusted repository of SSL certificate hashes and ensures the uniqueness of Serial, which is a unique UserID.
Thus, in the emcSSL system, both problems were successfully solved - both non-disclosure of the secret (a) and decentralization (b), which allows the system to be scaled to the global level. The user of the emcSSL system receives a kind of “pass-all-terrain vehicle”, which does not depend on anyone except the user. Not from the “site on the Internet,” not from the certifier, or from anyone else. Accordingly, the system does not allow attacks of the type discussed above, which lead to a massive compromise of accounts, because private keys are generated by users and never leave their computers, and there simply is no such central place that can be compromised.
In particularly important cases, it is advisable to use emSSL with a password in the framework of two-factor authentication . In this case, emcSSL authorizes the device and provides a secure channel of communication with the server, and the password authorizes the operator.
It is also worth mentioning that the emcSSL blockchain architecture effectively and safely solves the problem of revoking a compromised certificate and its quick replacement, which compares favorably with CRL and OCSP protocol, which is vulnerable to the MItM attack.
Infocard
So, the emcSSL system solves all the tasks. Compromise of any server does not lead to compromise of accounts, since the password is not stored in any form on the server. However, the server may store additional information about the user that is of interest to the attacker, such as a phone number, home address, and the like. In an amicable way, it is highly desirable that this information is not stored on the server either. Some online stores do this for security reasons - they allow the user to make a purchase as a “guest”, and do not save information about the user after making a purchase. The approach is certainly barbaric, but true. At least in terms of security.
An ideal user account system on the server side should have information about it when this information is required (say, at the time of the purchase), and not contain it when the attacker who received the base is trying to merge it.
The InfoCard system does just that. User information (info card) is created by the user himself, encrypted and placed on the Emercoin blockchain. When a user logs in with an emcSSL certificate, the certificate contains a link to the info card and the decryption key. The server at this moment can extract the contents of the info card and use it - for example, take the delivery address of the order and fill it with the contents of the order form field. After making a purchase, the server “forgets” the contents of the info card - until the next user login. As a result, only the UserID can be stored in the account on the server, and nothing else. No password, no personal user data. Not too rich catch for a cracker, is it? Accordingly, if there is nothing to take from the server, they will most likely not try to hack it.
In addition, it is worth noting that the InfoCard system, besides enhancing security, enhances user convenience, since:
- When registering on the next site - no need to re-enter personal information.
- The probability of data errors is reduced, since there is no manual entry.
- If something in the personal information has changed - then changing the contents of the info card will automatically lead to the work of all sites with the updated information. That is, we change it once, use it everywhere.
Application examples
The emcSSL system was open for public use about a year ago. During this year, the system was put into commercial operation by a number of organizations and websites. Some of the uses we know of are listed below:
- Emercoin Blockchain Engine - BaaS application for MS Azure .
- Poole mining EmeCoin .
- EmeCoin online wallet .
- Authorization module for Drupal CMS .
- Management system data centers and miners of the company HashCoins .
- Mass system of passwordless authorization from the company Remme .
How to start using
First, we advise you to read the detailed article in which you will find the most basic. Then you can explore the video , which shows step by step how the operator generated his SSL certificate and placed it in EmerCoin blockchain.
This classic way, when the user generates a certificate himself and publishes his hash to NVS, is the most correct in terms of security. For in this case, the user believes only himself, and his private key is generated locally and never leaves the user's device.
If you consider it acceptable to entrust your security to an external site, as it happens in the case of a login through social networks, then you can order a certificate online on the Cryptor site for free , and then place your hash in NVS on your own. If you wish, you can then generate another certificate locally and update its hash in NVS, which will raise your security to the “classic” level.
If you don’t want to contact EmerCoin at all, but nevertheless use the emcSSL system, then you can use the service from Remme , which provides a service of password-free authorization based on emcSSL technology. It is clear that in this case the company becomes your trusted agent.
You can check the work of the newly generated certificate and info card on the emcSSL website. From there, you can also download scripts for generating certificates, as well as two variants of the PHP server application, as well as an archived copy of the entire site. By deploying this copy on your own, you can see from the inside how it all works and use it as the basis for integrating emcSSL into your site.
In conclusion, we want to share a good article about creating a server application for using authorization through emcSSL.
about the author
Oleg Hovayko is a leading cryptocurrency developer EmerCoin, an expert in the field of cryptography and computer security. Since 1994 he has been working in IT. Currently, he is also the vice-president of the American investment bank, which makes operations with securities - Jefferies & Company. Which is considered one of the largest independent US banks.Source: https://habr.com/ru/post/316864/
All Articles