Releases: EOSIO/tropical-example-web-app
Tropical Example Web App v1.1.0
Tropical Stay v1.1.0 Release Notes -- Adding WebAuthn Support
What is WebAuthn?
WebAuthn is a new web standard that enables web applications to strongly authenticate their users using public key cryptography. Up until recently we used things we knew like usernames, passwords, and secret questions to authenticate ourselves, and then had to rely on the website we’re interacting with to protect this information. As we have seen in the news many, many times over the past few years, an alarming number of companies have failed to do this properly which has resulted in the compromise of their users' personal information. These breeches have caused millions and millions of people to have their sensitive personal data exposed and often sold for criminal purposes. See the Block.one blog post that tells a bit of that story.
WebAuthn is a significant upgrade in authentication technology and allows a more reliable, harder-to-hack form of authentication that could very well lead to “password-less login” for your favorite websites. To read what a password-less future would be like, see this Block.one article.
Here is a great non-technical introduction to the kind of password-less authentication WebAuthn enables.
A quick, mildly-technical video brief can be found here.
For a somewhat-detailed, but readable introduction, read this article from PCWorld.
For more in-depth, see this article from Yubico.
Read more about WebAuthn support in the EOSIO 2.0 Medium article. For technical details, see the PR.
Use Cases
Authentication
WebAuthn provides interactive strong authentication between two entities, typically an end user and a website or app provider, known as the Relying Party, without the Relying Party having to trust the client software -- browser, web page, mobile app, etc. The blockchain network cannot perform the role of Relying Party so WebAuthn can’t generally be used as a login for an EOSIO blockchain, but it can be used as primary or secondary authentication factor for a specific blockchain application communicating with a particular EOSIO-based blockchain.
Let’s look at two domains: public (systems that are transparent and in the cloud like most blockchains we are familiar with) and private (services provided by a private company or government services, where the websites and services are owned privately).
Public Systems
In the case of smart contract-based blockchains, individual apps written for those platforms could use WebAuthn to act as a second factor added on top of a traditional primary authentication, reducing the attack surface of the components typically involved in signing a transaction, eg. browser, signature provider, web connection. See below for more on this topic.
Private Systems
WebAuthn can also secure and simplify the login process for websites as well as private, web-serviced blockchain applications. Once the user has authenticated themselves they can enroll a key from a WebAuthn-enabled device, then use that enrolled device as a primary authentication replacing the need to log in with a password.
Mitigation of Common Web Security Issues
Web browsers are notoriously insecure. They have implemented strict policies that restrict what can happen in code in the browser’s context, but attack vectors continue to be hard to avoid in some cases.
WebAuthn allows for an end-to-end path of trust from server to authenticating device, reducing the potential of a malicious actor tampering with a transaction in the browser. WebAuthn also allows the authenticator function to be moved to an external physical device, eliminating one of the weaknesses in signing a transaction; namely that the software-based authenticators doing the signing have an attack surface a hacker can try to exploit. The attack surface of a WebAuthn-enabled device is far smaller than the attack surface of a software authenticator.
WebAuthn Example
Visual Walk-through
When you launch the app, you’ll see the pre-existing not-logged-in state. Click Login to initiate the normal login.
I’ve configured the Chrome Reference Authenticator and Scatter as my Authenticators. Choose your Authenticator and complete the action to sign and send the transaction.
Now, when you return to the app, you’ll see that in the drop-down menu, you now have an Enable WebAuthn 2FA option in the login drop-down menu. Click that to begin the WebAuthn ceremony. Behind the scenes, this ceremony is establishing a private key that will represent you to the Tropical Stay example app.
The Tropical example requests that your browser verify you. In this screenshot, you see Chrome asking the user which form of authentication they would like to use: the “USB security key”, a hardware authentication device, or the “Built-in sensor” which is the TouchID fingerprint reader on my Macbook Pro. I’ll select the fingerprint reader.
Chrome then shows that it’s waiting for me to provide my fingerprint authentication.
I touch my finger to the fingerprint reader.
Chrome then does a final check with the user to ensure I intend to share this important information with the browser. I click Allow to give Chrome access to the key that has been generated in the background for me. Chrome can now use this key to confirm with websites that it is actually me sitting in front of my computer and logging in or taking other action.
Click the Continue button to proceed to the Properties page.
On the Properties page, we now have the “Rent” button, which allows us to commit to renting a property. This is a high-risk activity when compared to Liking a property, so we will again verify the user’s identity via WebAuthn.
You’ll see Chrome again waiting for a fingerprint scan or for you to touch the sensor on the USB Security Key.
Or if you’re using a USB Security Key, it might look like this.
The transaction request will then pop up in Scatter and request you Allow the transaction to be signed.
Then finally, the UI will show the successful result of the Rent commitment.
How The Demo Works
Overview
NOTE: This is not a description of the WebAuthn standard itself. WebAuthn is acting as only part of the specialized use of the standard in the sample app as a second factor.
Both the server and the user have key pairs. The user’s is generated from some sort of specialized hardware made for this purpose, eg. a USB Security Key or other authentication device, and the server’s is a pre-generated key pair, like a server would use to sign/verify a JWT token. When a higher-risk action is taken by the user, the client and server communicate and each other and sign a challenge. That challenge can then be verified in a smart contract as having been provably signed by the server and a WebAuthn authenticator the server believes is associated with the user.
The Process -- Step 1: Enrolling a Device
First, the app enrolls a public key and Credential ID from a local hardware authentication device. This consists of the browser requesting a public key and the associated Credential ID from the authentication device and sending it to the server, where the user’s public key and Credential ID are stored. The client doesn’t need to store any state about the key pair the device generates. The Credential ID is what the authentication device uses to re-generate the appropriate key pair. It is stored by the server and passed to the client each time something is signed.
The Process - Step 2: Performing a Higher-Risk Action
When the user performs a higher-risk activity and they or the application wants that action protected by a second factor, the client requests a challenge from the server. The server returns a challenge that it has signed with its own private key, and which it generates from the public key it already knows to be associated with the user from the user’s enrollment process, and some concrete data associated with the higher-risk activity...
Tropical Example Web App v1.0.0
Tropical Example Web App v1.0.0
The v1.0.0 release updates the chain icon to the EOSIO community icon.
Changes
- The chain's icon for the Manifest Specification has been updated. This changes the
app-metadata.jsonhash and the chain's hash.
Update Steps
If the eosio docker container is already running with the current Master branch, when pulling these changes, the following commands will need to be run:
- The following command stops the container and removes the volumes. This means that all transactions executed will also be removed:
docker-compose down -v- The following command rebuilds the container and does not use the cache to ensure that the latest changes are applied:
docker-compose build --no-cacheAfter those commands are successfully executed, the container can be brought back up with:
yarn upDisclaimer: Block.one makes its contribution on a voluntary basis as a member of the EOSIO community and is not responsible for ensuring the overall performance of the software or any related applications. We make no representation, warranty, guarantee or undertaking in respect of the releases described here, the related GitHub release, the EOSIO software or any related documentation, whether expressed or implied, including but not limited to the warranties or merchantability, fitness for a particular purpose and noninfringement. In no event shall we be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or documentation or the use or other dealings in the software or documentation. Any test results or performance figures are indicative and will not reflect performance under all conditions. Any reference to any third party or third-party product, resource or service is not an endorsement or recommendation by Block.one. We are not responsible, and disclaim any and all responsibility and liability, for your use of or reliance on any of these resources. Third-party resources may be updated, changed or terminated at any time, so the information here may be out of date or inaccurate. Any person using or offering this software in connection with providing software, goods or services to third parties shall advise such third parties of these license terms, disclaimers and exclusions of liability. Block.one, EOSIO, EOSIO Labs, EOS, the heptahedron and associated logos are trademarks of Block.one. Other trademarks referenced herein are the property of their respective owners. Please note that the statements herein are an expression of Block.one’s vision, not a guarantee of anything, and all aspects of it are subject to change in all respects at Block.one’s sole discretion. We call these “forward looking statements”, which includes statements in this document, other than statements of historical facts, such as statements regarding EOSIO’s development, expected performance, and future features, or our business strategy, plans, prospects, developments and objectives. These statements are only predictions and reflect Block.one’s current beliefs and expectations with respect to future events; they are based on assumptions and are subject to risk, uncertainties and change at any time. We operate in a rapidly changing environment. New risks emerge from time to time. Given these risks and uncertainties, you are cautioned not to rely on these forward-looking statements. Actual results, performance or events may differ materially from what is predicted in the forward-looking statements. Some of the factors that could cause actual results, performance or events to differ materially from the forward-looking statements include, without limitation: market volatility; continued availability of capital, financing and personnel; product acceptance; the commercial success of any new products or technologies; competition; government regulation and laws; and general economic, market or business conditions. All statements are valid only as of the date of first posting and Block.one is under no obligation to, and expressly disclaims any obligation to, update or alter any statements, whether as a result of new information, subsequent events or otherwise. Nothing herein constitutes technological, financial, investment, legal or other advice, either in general or with regard to any particular situation or implementation. Please consult with experts in appropriate areas before implementing or utilizing anything contained in this document.