Zenome Wallet Developments: Working group’s report
Q: What were the initial requirements for Zenome wallet?
There are 4 “must” requirements:
- Security, that involves reducing attack surface and doing much testing before going into production.
- Extensibility, that is required for the Zenome Wallet to be the starting point of the Zenome platform Account manager.
- Modularity, so in the future, new features can be achieved with less cost.
- Integrity, to provide a seamless user experience.
In fact, achieving all these at the same time is a great challenge. You can easily have security and integrity at the price of modularity and extensibility, or modularity at the expense of compromised security. But having all these at the same time is a lot of work.
Doesn’t modularity imply extensibility? Isn’t it the opposite of integrity?
Well, not always. In fact, these are unrelated properties of the system.
Concerning the first question you asked, modularity may not imply extensibility because of poor design or for a purpose. Simply breaking the monolithic system into interconnected parts will not make it modular. In truly modular systems, each part (a module) is designed without making assumptions regarding the implementation details of the others.
Designing non-modular systems to look modular is sometimes beneficial (for the software author, not the user) in the case of proprietary software. This is because it involves so-called vendor lock-in.
Regarding the second question, it’s better to put it this way: “May modular systems feature integrity?” Of course, it may — if designed properly.
That sounds like a lot of work. How did you plan to finish before February 1st?
Right. The idea was to involve a group of developers that claimed to have a working solution already in place to start the automatic sale on February 1st. The requirements were that the resulting set-up could be updated to work with our software and also includes the KYC procedure. Their solution lacks KYC at the moment.
We admit it was the worst decision we could make. Not only did we waste time reporting bugs in their software and also explaining the nature of these bugs to them (in the hope that it would help start sales faster), but there also were fundamental disagreements about the overall design of the system.
That’s not cool. What do you mean by “explaining the nature of the bugs”?
The developers were confident that their solution was flawless. They denied obvious problems. After admitting the problem, they came up with a patch that made things worse. Much time was wasted. As time went on, the system was falling apart.
What were the fundamental disagreements? Wasn’t it obvious beforehand?
Their wallet site was dependent on their proprietary infrastructure. Source codes were to be hosted in our repository, but a quick inspection found the code covers only the front-end. They may have thought hosting static files on our server would make us believe the site connects to our server.
But it was not obvious. If it were the way they claimed, everything would be fine. It turns out our mistake was to believe them.
What about the solution you are developing?
For the back-end we use PostgreSQL and nodejs powered by modern koa framework, running on different servers. The front-end is powered by vuejs.
We bundle everything except the security-critical portion to the client side. The server only does the following: sends the “user state” object to the client, executes a very limited set of allowed actions, and checks for credentials. Forming web pages, based on the state and routing between pages — that all works client-side.
For user authorization, we use so-called JSON Web Tokens — a modern way to implement authorization. The idea is that when you log-in using a login and password, your browser will get an access token. This token contains information about the user, the expiration time and the IP the user uses. It’s cryptographically signed so that user cannot modify the containing data. The client-side software uses this token to authorize on the server.
Does that mean that having a token I can access somebody’s else account?
It is not that simple. First of all, we do not use cookies to store the token. We store it in the client-side execution environment. So after the user closes the page, it gets lost. Even under the assumption that an attacker or the malicious code has full access to a user’s computer, found it in the RAM then sent it to the attacker’s computer, the attacker will only get a “your IP changed; please re-login” message. We keep track of all such events and notify users about suspicious activity.
What about the token sale?
We use quite a different approach to the token sale that might look strange. We allow users to register a number of addresses they will use to send us BTC or ETH. We expect some bad guys to try to add the same address to their accounts at the same time. They will not be able to do that. The PostgreSQL will handle this race condition (by rejecting transactions) and allow only one account associated with an address.
What about people simply registering addresses they do not own?
Their account will be frozen after the legitimate owner of the address finds out that the address has been taken by somebody else. We will request that they prove address ownership (by sending a tiny transaction to the address we provide). After that, we will investigate the issue. Given that (thanks to KYC) we have a photo ID of each user, trying to steal other people’s addresses hoping to get their tokens is reckless behavior.
What are the benefits of that?
For legitimate users, this way of buying tokens is safer. The procedure of creating temporary address per each payment was designed to avoid users creating accounts. Times have changed, and now we have KYC — the user must register an account anyway.
This way of purchasing tokens is suitable even for buying small amounts of tokens (there won’t be any minimal amount), as it implies less associated costs on transaction fees. Users that want to get tokens to use the system when it’s ready will appreciate that.
The wallet site will guide the user through all the steps of purchasing tokens. When making a payment, the user may have a contract for the purchase of tokens that will contain his name and the address he will use to make the payment. The contract can be downloaded as a PDF. We hope it will make the process transparent and easy for all users.
