1-Click Sign-on to a Web Page using Metamask — A slightly different approach
To get straight to the source code, please visit the GitHub page.
This writing is not a “how-to”. It is simply a high-level explanation. The technical document is currently under development (and this writing will be updated with a link when it is done).
1-click sign on is nothing new for anyone who has used decentralized applications built on Ethereum. Basically, we want to be able to log-in into a web-page without providing any e-mails, usernames, passwords. Furthermore, we do not want to go through the steps of registering, keeping the passwords, confirmations, and all of the other things and forms that take away our valuable time.
This writing is meant for developers as well as anyone interested in how the Krakin’t approach works.
The key security concept is that nobody should know what the nonce is, yet we should be able to sign it. This is accomplished by using the BCrypt and AES encryption algorithms… OK, let us go back to the beginning so this can be understood.
First, our technology stack is a bit different from what the online tutorials were suggesting. However, we did not reinvent the wheel by adding some extra security. The technology stack consists of Vue.js (Javascript), Java (with Spring Boot framework), MySQL (actually MariaDB for now), and in-memory storage. The online tutorials are simply concerned with Javascript, and therefore, they are slightly incomplete.
Although Javascript has the backend and the front-end components, to me as a full-stack developer, the Javascript always belonged to the front-end world, and therefore it was treated as such, thus adding some extra security features to the core backend.
The well known design which is several years old is:
Since the technology is new, it is possible that the security is not good enough for authenticating the users, so we are adding 2FA sign on as the final step. Nevertheless, before the user gets to the 2FA part, here is what our architecture looks like:
So, although it looks complicated, the process is very simple.
First, we confirm the nonce using the Javascript, and if it is a pass, we do the same using Java. The nonce that Javascript is checking is encrypted, and we are signing the encrypted nonce. The nonce that Java is checking is decrypted and we are checking it with the encrypted nonce stored in the SQL database. This way, nobody, at any time, can see what the real nonce is. This is how we are adding to security.
Yes, we are using in-memory file storage. Some developers may disagree with this approach, nevertheless, in my opinion, it is safer than a plain-text application.properties. This is simply secured by adding the user-only permissions to a folder and a file. Spring Boot does not allow us to initiate the global classes, so we can solve this lack of features by using a database connection, saving it as a file or making another micro-service that acts as a global Java class. Connecting to a database requires a password to be stored somewhere, while using the micro-service depends on the network connection. Using the small-file as storage can be easily regulated by adjusting the permissions. Furthermore, the more complicated the solution, the better the chances are that it can be hacked. Therefore, the best solution is to use small-file storage.
Please feel free to break this design, and you will be rewarded 1000 KRK tokens! Simply show how you can log-in as any other user (provided you don’t have their ETH private key).
