Unikname Development Report #15
Welcome to the 15th edition
How does URL checker work? 🔍
Unikname for WordPress 8.6 has been released see announce!
It ships a very cool new feature to make Unikname Connect integration in WordPress site easier than ever.
What makes Unikname Connect so unique is that to connect a user on a website, the protocol uses strong cryptographic algorithms to identify all stakeholders through their public (digital and pseudonym) identity on the decentralized registry (uns.network blockchain). Protecting three actors from fraud: user, website and authentication service. Thus, the user is sure to connect to the wanted website and the website owner is sure to give private access to the right user.
When you’re setting up Unikname Connect integration on your website, you create a digital identity for your website (a.k.a @unikname). This identity will be secured by asymmetrical cryptographic keys kept in a safe and offline place. But once done, you haven’t any relation between your website and your identity. This relation is called a Trust Certificate and is named because of the incontrovertible (mathematical) trust to the website owner.
What better trust to sign domain ownership on a public and decentralized registry? Probably none. So let’s deep dive into what’s under the hood of so-called url checker verification process.
1. Get the verification package:
Use our command-line tool to generate enough info to prove domain ownership : uns properties:register […].
This command will create a JSON Web Token containing data to give a known third party ability to verify that your @unikname wants to declare ownership of a given domain. The token is also cryptographically signed by your @unikname private key.
Issuer and Subject are your @unikname unikId (on-chain identifier) and Audience is the verifying third party unikId.
The verifying third party is a known service provided by uns.network ecosystem called url-checker. It has a @unikname (so it’s a real entity on-chain), is public and sealed on-chain and is rewarded for verifying URLs. It has to follow the rules and be honest to keep its seat and get rewards or it would be kicked off by the community.
2. Upload the package to your website:
Once you got the package, you have to link it to your domain.
You have multiple choices:
- upload the previously generated file on your website,
- insert previously generated signature (verification-key) into a meta-tag of your website index.html,
- NEW : if you’re on WordPress, paste the verification key into the “Unikname > General” admin panel and it’ll do it for you.
- or simply ask for human verification (contact Unikname support team).
In this step, it attests that if you have access to deployed files under a given domain, you must be its owner (or at least you must have the ability to claim ownership).
3. Get the ownership proof
Last but not least, you must get url-checker verification stamp through our command-line tool: uns properties:verify […].
It creates an unikname.network transaction (unikname property update) to add a new property to your @unikname containing:
- currently claimed and owned domain
- verification package generated in the first step.
To sum up, what do we have after step 3:
- a website with its own decentralized identity (organization @unikname)
- an on-chain certificate which proves that this website is owned by given @unikname
- all the proofs to verify at any time ownership (that’s why it’s important to keep signature uploaded to the website).
During connection, the user is able to verify ownership (through Unikname Connect UI), and Unikname Connect protocol is also be able to verify that a user wants to connect to a previously registered website.
Here was the description of the process to register your website with Unikname Connect, but you can also use url-checker service to get irrefutable proof of your domain ownership, build your own url-checker or any other service based on uns.network blockchain. It’s up to you now.
👉 You’re interested in Unikname Connect integration? Follow the link!
Unikname products passed the security bench 🔐
We are progressively submitting our products to security audits by specialized companies.
Today, we’re proud to announce that our 3rd product has officially passed the bench.
uns-core, unikname connect authentication server and unikname services have been audited during the last months.
uns-core is the name of the unikname.network blockchain node project.
It contains all the code to manage a relay and forging unikname.network node: handling transactions, interact with peers, build blocks,…
The majority of the code comes from ArkEcosystem framework which is daily audited by bug-bounty, open-source community and specialized companies. What unikname.network brings on top of Ark framework is the ability to work with non-fungible tokens (create, update and transfer UNIKs), and NFT related transactions (register @unikname as a delegate, vote for a @unikname, disclose a @unikname,… ).
unikname-services is the name of a set of public and restricted APIs required to work with @unikname. It aims to provide services that couldn’t be included in a blockchain protocol (like costly and expensive tasks, work with centralized and dynamic data, and so on). Among all its services, it can certify transactions for unikname.network blockchain, verify domain ownership, compute unikname price or compute unikname secured id.
unikname-connect authentication server is the name of our authentication server executing Unikname Connect protocol. It’s the central element between My Unikname App and partner website during authentication. It’s configured to enable authentication through Unikname Connect protocol, built on top of OpenID Connect protocol, itself built on top of OAuth 2.0. The server’s role is (mainly) to verify the authenticity, validity and capacity of authentication stakeholders. To complete its job, it works in harmony with uns-core and unikname-services products.
Only 3 minor vulnerabilities have been identified during the products audit: 1 with the medium severity and 2 with information.
The one with medium severity was the ability to vote for a delegate that hasn’t “active” or “everlasting” lifecycle status. This vulnerability could lead to unexpected results in code based on this assertion or abuse in delegate registration. It has been fixed in the latest released version.
Another one with information level is the ability to send protocol tokens to himself. It’s a wanted behaviour because protocol token transfer transaction could be used to persist information on-chain, to have a timestamped data. It’s also up to the client application to do the verification and warn or block when the user wants to send tokens to himself. Blockchain can’t know if the user is aware of what is he doing.
The last information vulnerability is on certified transactions signature (unikname mint, update and transfer). Vulnerability is that one signature is not verified by the NFT-factory which certify the transaction. But this signature is verified by the blockchain before being sealed in the registry. It means that an attacker could send fake data with an invalid signature to NFT-factory and get its certification. It couldn’t seal its transaction in the chain, but it could send it to a third party service. This third-party service shouldn’t assert that received data are valid.
This vulnerability won’t be fixed, for 2 reasons:
- verify mint transaction signature is a non-sense. Anyone should be able to acquire a @unikname and we haven’t discriminant criteria to reject this demand based on the wrong signature. Any wallet is valid (with current rules).
- verify transfer transaction signature has sense. We don’t want a cryptoaccount to transfer a @unikname to another cryptoaccount without being the current owner.
But today, it has no sense to do the verification by NFT-factory because no third party service is using this transaction. And this transaction is only used after being sealed on-chain, where verification is currently made.
Our technical infrastructure has also been pentested without any leak. Only one header is missing in our HTTP communications : Strict-Transport-Security (HSTS). This vulnerability could lead to authorizing not secured HTTP (without the ‘s’) communications between client applications and one of our servers. Leading to man-in-the-middles attacks due to not encrypted communications.
It’s a major forward step to open-source uns-core code and start to collect public reviews and enhancements. 💪🏼
Dashlane, one of the leading password management solutions, estimates that by 2022, the average...
Traditionally, digital identities are managed, generated, and owned by centralized service...
Dear community,Something big has been on the horizon for quite some time now and our team is super...