|WebAuthn+ JSON DLT ~ The Internet of Value
|The first wave of Blockchain/Distributed Ledger applications will most certainly fail; however...
|There will be a new beginning. Eventually, Distributed Ledgers (not crypto-currencies),
as a cryptographically secure shared source of truth
that can be processed by intelligent systems, will provide great benefits to all businesses, from startups to multi-national corporations to impoverished villagers in the third world.
|The Internet of Value[ref] will become a reality.
Some have estimated that the resulting economic efficiencies (by reducing time, costs and risk) will be measured in trillions of
|Secure identity will make the
Internet of Value possible.
|A W3C recommendation was recently published:
Web Authentication: An API for accessing Public Key Credentials
|This recommendation is commonly referred to as WebAuthn; it is exceptionally detailed and complex, perhaps unnecessarily so.
|The WebAuthn document reads like the blueprint for a massive suspension bridge to be built across a "narrow creek".
The problem that needs to be solved for secure web authentication is actually very simple: insure the user is on the right web page; "www.chase.com" not "www.chaze.com".
This could be accomplished by a simple change to the Web Bluetooth API;
the complexity of WebAuthn is unnecessary.
Even though WebAuthn has support from some of the
major corporate players, the recommendation has glaring deficiencies:
The banking community will NEVER adopt a platform that allows others to harvest their customer data.
Banking IT professionals will want to inspect every line of source code in an authentication system and will reject any system that exposes a data breach.
While the WebAuthn recommendation mentions privacy
in terms of keeping user credentials private from other users, there is no mention of restrictions on the providers of
browsers and operating systems in harvesting a user's personal data. Corporations spying on their users has become a
Corporations should become proactive participants in the privacy debate. If they do not help guide the debate, the tide of public opinion will result in punitive legal restrictions.
Anyone familiar with Identity and Authentication Management (IAM) who reads the WebAuthn recommendation will realize the proponents of WebAuthn
are attempting to co-opt a large portion of the IAM process. Control is being centralized.
When there is centralized control, bad actors both in big corporations and in big governments can corrupt the process. Our Orwellian future is
close at hand. If it becomes very easy to track the authentication to every mobile and web application, our privacy will be diminished.
The WebAuthn recommendation is over one-hundred pages long and it reeks of artificial complexity. Anyone who has been involved in IT for any reasonable period of time
will see the WebAuthn recommendation as an opportunity to create complex systems and sell consulting services.
- Currently, a physical
which must be plugged into the computer's USB port, is the primary way to authenticate to a web application on a desktop system.
While inconvenient for the user (and a security threat if the user leaves the key plugged in), this is a great deal for anyone selling security keys.
- The need for physical security keys explains why
Yubico is one the the major driving forces for WebAuthn and why Google (another major driving force) is now selling
- There are "platform authenticators"
(e.g., fingerprint readers, iris scanners, voice authenticators, etc.). While some new mobile devices and some new laptops have fingerprint readers,
older mobile devices, older laptops and most desktops do not.
- A "mobile authenticator" has been promised; this will allow users running Android 7 and above to use the security in their mobile phone as an authenticator.
This promise is now more than a year overdue. No doubt, the complexity of the WebAuthn
protocol (100+ pages) has been a limiting factor.
- Even for the existing physical security keys, the complexity of the WebAuthn
protocol has resulted in implementation problems.
It was recently reported
that the Titan security key which Google sells for two-factor authentication can be hijacked by nearby attackers using flaws in the Bluetooth implementation.
- As a recent analysis in Wired pointed out, the Bluetooth protocol itself has become so complex (3,000+ pages) that
it is now a security threat. Any application that implements Bluetooth must do so with crystal clear clarity and provide detailed guidance for IT professionals.
- Not just in regards to Bluetooth, but overall, the proponents of WebAuthn provide minimal guidance for IT professionals. There are limited resources for developers (just some brief code samples).
There is no open source reference implementation in the WebAuthn documentation set.
- The following is a quote from the W3C docs: "As part of the standards process, the W3C requires that groups demonstrate implementation experience."[ref]
In this regard, WebAuthn represents a failure of the W3C process and steps should be taken to
rescind the roaming authenticator portion of the recommendation.
- Browser compatibility
is a glaring deficiency for any web application provider with a large user base.
Only the newest versions of Chrome, Edge and Firefox will support (some aspects) of WebAuthn. Internet Explorer, Opera and Safari (Apple) have no support.
- Portions of the WebAuthn recommendation (e.g., bluetooth communication from the browser to a smart phone) are not yet supported.
- The most glaring deficiency of WebAuthn is privacy protection. The WebAuthn API seems designed to give the makers of browsers
the ability to monitor a user's sign on to every application and to harvest data from that process.
|The WebAuthn promise of "simpler stronger authentication", is a noble goal.
How did the implementation get so screwed up? How did an alliance of the world's leading tech companies fail?
|There are some incredibly smart people promoting WebAuthn.
When incredibly smart people engage in tribal mentality, bad things usually happen, especially when their tribal leaders have bad motives. It seems that the major proponents of WebAuthn
are more concerned with controlling the IAM process, invading privacy, selling security keys,
creating complex systems and selling consulting services than with creating a simple and elegant solution to the authentication problem.
|The problem affecting WebAuthn is the same problem affecting many aspects of our society, especially our politics:
the mindset of the tribal group.
|"Groupthink is a psychological phenomenon that occurs within a group of people in which the desire for harmony or
conformity in the group results in an irrational or dysfunctional decision-making outcome. Group members try to minimize conflict and reach a consensus decision without critical
evaluation of alternative viewpoints by actively suppressing dissenting viewpoints, and by isolating themselves from outside
|"Groupthink requires individuals to avoid raising controversial issues or alternative solutions, and there is
loss of individual creativity, uniqueness and independent thinking. The dysfunctional group dynamics of the 'ingroup' produces an 'illusion of invulnerability'
(an inflated certainty that the right decision has been made). Thus 'the ingroup' significantly overrates its own abilities
in decision-making and significantly underrates the abilities of its opponents (the 'outgroup')."[ref]
|It is possible for one individual to breakthrough the
the mindset of the tribal group, even when he/she is going up against some incredibly smart people who are absolutely certain they know what they are doing.
The story of John C. Houbolt
from the early days of NASA is a story that should be taught in every engineering program. John C. Houbolt was THE guy who figured out how to go to the moon.
He succeeded against strong opposition because his solution was technologically superior and because his ultimate concern was the success of the mission.
|A revised standard, WebAuthn+, will remedy the deficiencies of the current WebAuthn proposal:
- The foundation of WebAuthn+ is a simple "Cloud to Mobile Authenticator"
that enables users to simply touch a "Sign On" button on their smart phone and securely authenticate to a web application.
- No extraneous physical security keys are required.
- There is no registration process in the browser. The Credential Management API becomes superfluous.
- WebAuthn+ implements Bluetooth with exceptional simplicity. We only use Bluetooth to send the host's domain name
(prevents phishing) and the generated Session UUID to the user's smart phone.
- WebAuthn+ works with or without bluetooth communication. Users with older systems are not excluded from the process.
- WebAuthn+ provides an open source reference implementation.
"A system is secure if the plans for the system are public, and the bad actors can still not break in."
- WebAuthn+ protects privacy. It is not designed to harvest data from the authentication process.
- WebAuthn+ provides secure support for
Distributed Ledger Technology (DLT)
which will make the Internet of Value a reality.
It is impressive to see a distributed ledger signed by one touch on your mobile device.
You can test this for yourself. Install the
TNX WebAuthn+ mobile app and then go to our
- The user experience (UX) for WebAuthn+ is simple and friendly.
- No cookies are required with WebAuthn+. Users are not tracked.
- WebAuthn+ is incredibly secure. Excluding attacks against the operating systems, there is only one threat vector:
If a bad actor "looks over your shoulder", steals your six-digit HEX pin, then steals your smart phone, and before you can report it lost or stolen
defeats the fingerprint reader... then the bad actor can access your account.
|The graphic below is from a
Google I/O presentation which provides a comprehensive overview of WebAuthn.
|The graphic below is from the Medium article,
Introduction to WebAuthn API by Ackermann Yuriy; this article is a
non-trivial introduction even for experienced developers.
|The key difference between the architecture for WebAuthn and WebAuthn+ is that
Credential Management API which,
"lets a website [through the browser] store and retrieve user, federated, and public key credentials."
|In WebAuthn+ the authentication process
is in complete control of the web application provider (the code is open source and available to all). Credentials are stored on the user's smart phone and within the data structures of the web application provider.
|Hover over the numbers below in sequence and you will realize how simple and elegant the
WebAuthn+ process truly is.
The user goes to the web application's "Sign On" page.
The generated Session UUID and the
host's domain name (prevents phishing) are sent to the user's smart phone directly from the web browser
over a local bluetooth connection.
The generated Session UUID,
the Credential Type and the User Identifier (email) are sent to the server.
The server returns a visual Authentication Code (e.g., "WHSL LRTU FLVM") to the browser.
The generated Session UUID,
the Credential Type, the User Identifier and the
visual Authentication Code are sent to the user's smart phone
through an encrypted Firebase channel.
On a set interval (5 seconds), the browser pings the server;
the server either responds with, "Not Authenticated", or with a valid Authentication UUID (if step 7 has been completed).
A secondary implementation that utilizes Web Sockets is in development.
If the values from the server and the web browser are a valid match,
the user is notified of the sign on request.
The user touches the sign on button on his/her smart phone which initiates step 7.
The Session UUID is signed with the user's private key
(which is stored securely on the user's smart phone) and the signed
value is sent to the server which has a record of the user's public key. If the signature is valid an authenticated session is established for the user.
With an authenticated session, the user now has secure access to the web application.
The simplicity of this authentication process is that the user goes to a web page, receives a notification on his/her smart phone and simply touches the sign on button.
|All that is necessary to make this work is a simple addition to the
Web Bluetooth API. A method needs to be added and this method needs to be run within the
|writeDomainNameCharacteristic(serviceUuid, domainNameCharacteristicUuid, domainName)
|Once this is implemented, excluding attacks against the operating systems, there is only one threat vector: If a bad actor "looks over your shoulder",
steals your six-digit HEX pin, then steals your smart phone, and before you can report it lost or stolen defeats the fingerprint reader...
then the bad actor can access your account.