> Running a permissioned blockchain is nontrivial.
You are right. It's needed a relevant BFT protocol, a lot of work with masternodes community and smart economic system inside. You can look at an example of a such protocol:
https://github.com/Remmeauth/remme-core/tree/dev
Thanks for the references! The main issue isn't the support and maintenance of a such distributed network, but its integration with current solutions and avoiding centralized middleware services that will weaken the schema described in the documents.
You are right. There are a lot such ideas of implementations for DNS, CA level etc. For authentication, there are also field to try it, but of course, blockchain isn't a solution that would fit everywhere.
It depends on how you estimate CA vulnerability and how much your organization ready to trust it. There are enough cases when important auth info was leaked.
We understand your pain related to difficulties to get started with blockchain protocols. One of our goals actually makes it as easy as possible to interact with. Unfortunately, the time that we invest in such adaptation isn't enough, but we have tight terms for our roadmap realization.
Hi James and Angel! You are doing a great job with your project. Does CSPA concentrate only on hiring processes or also helps to find partners, contributors and the possibility to develop tech community?
REMChain is only part of certificate management infrastructure and also an open source solution. We are working on applications that related to web authentication through OAuth standard, domain validation, KYC, SDK for IoT, but also propose to more broad tech community to search useful approaches for its current functionality. Users pay to the network for the work related with certificate generation, registration, and checks of its validity status during a login process. REMChain makes available to companies to generate its own protected certificates for different uses.
Yes, it is right. You can read more about the concept of consensus here: https://medium.com/remme/proof-of-service-consensus-algorith...
It is still under development, hope I can share tech docs about its implementation soon. 2 stages are important for raising the speed of certificate generation that is critical for that sphere.
Many changes occur only after the painful experience experienced by the company. The first ones to implement cybersecurity solutions are cautious and prudent, who do not want to find themselves in a situation where a cyber attack will erode confidence in them.
Of course, there are no solutions that will 100% prevent cyber attacks. The task is to increase the cost of such an attempt when efforts aren't worth the result. In a distributed PKI, it is not possible to access all accounts through a server attack, and it is also possible to dynamically and transparently track all changes in accounts.
REMME WebAuth solution uses one of the better ways of authentication through X.509 client certificates. Certificate-based authentication allows users to securely access a server by exchanging a digital certificate instead of a username and password. This means the client is not sending a username or password to the server which helps in preventing phishing, keystroke logging and man-in-the-middle (MITM) attacks among other common problems with password-based authentication. The certificate hash and status are stored on the REMME Blockchain. Server checks status of the certificate before login on the site/service.
You can start with the use of available libraries. You can read about them here https://docs.remme.io/. There are some examples for the beginning that are presented in the description.
It is necessary to consider in the framework of a specific case, but REMME WebAuth is just an example of how to use dPKI with a centralized application. Here you can see the demo: https://webauth-testnet.remme.io/register