Venus
Lek ؋ $ ƒ $ ₼ $ $ Br BZ$ $ $b KM P лв R$ $ ៛ $ $ $ ¥ $ ₡ kn ₱ Kč kr RD$ $ £ $ € £ $ ¢ £ Q £ $ L $ Ft kr ₹ Rp ﷼ £ ₪ J$ ¥ £ лв ₩ ₩ лв ₭ £ $ ден RM ₨ $ ₮ MT $ ₨ ƒ $ C$ ₦ kr ﷼ ₨ B/. Gs S/. ₱ zł ﷼ lei ₽ £ ﷼ Дин. ₨ $ $ S R ₨ kr CHF $ £ NT$ ฿ TT$ ₺ $ ₴ £ $ $U лв Bs ₫ ﷼ Z$
Trust Nexus
WebAuthn+ JSON DLT ~ The Internet of Value
Home WebAuthn+ Identity Distributed Ledgers Finance Demo IVY Test DEV Contact License
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?
  
The Internet of Value
Imagine that for every business process and every financial transaction it was possible to touch a button on your mobile device that would generate a hashcode that represents all the elements of the process/agreement and then that hashcode would be cryptographically signed by your private key.
The elements, hashcode and signature would all become part of a cryptographically secure distributed ledger (not a "blockchain") that would provide an inviolable record that could be further extended in a similar process.  This will be how the Internet of Value will work.
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 following critique of WebAuthn is harsh.  Any assertions are mearly the opinion of this author.  If you think any part of the critique is unfair or inaccurate, please contact us:  trustnexus.io@austin.rr.com
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 completely unnecessary.
Even though WebAuthn has support from some of the major corporate players, the recommendation has glaring deficiencies:
  • The WebAuthn spec is a jumble of three specifications for authentication:  physical security keys, biometrics and mobile authenticators.  There really is no one standard for authentication.
  • Currently, a physical security key, 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 security keys.
  • There are "platform authenticators" (e.g., fingerprint readers, iris scanners, voice authenticators, facial recognition, 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.  There is no open source reference implementation in the WebAuthn documentation set.  In fairness this presentation provides a good overview for implementing security keys.
  • A major flaw in WebAuthn is that there is no simple process for developers to code a universal solution. From a developer's standpoint WebAuthn is a convoluted mess.
  • 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 mobile 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 and Opera 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 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 major problem.  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.
  • It is time for the members of the FIDO Alliance to recognize the limitations of WebAuthn:  the specification is a workable solution for physical security keys and biometric readers, but not great for the general public and not easy for developers to create a universal authentication solution.
Rather than giving consumers what they really want, the FIDO Alliance is pushing physical security keys and biometrics.  In my judgement, consumers definitely do not want the inconvenience of physical security keys, which are a security threat if left plugged into a system and an annoyance when lost, misplaced or stolen.  Most consumers do not trust biometric surveillance (whenever I get a new laptop the first thing I do is put a piece of black electrical tape over the camera) and they think biometrics are intrusive (Big Brother really is watching.).
Those who are focused on WebAuthn from the FIDO Alliance are on the wrong path.  By the end of 2020 WebAuthn will be seen as just another failed authentication standard.
The "Nirvana Solution" for authentication will enable users to keep simple passwords (which is what they really want).
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 technology companies set out on a path that in my opinion has lead to failure?
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 influences."[ref]
"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.
  • WebAuthn+ utilizes simple JavaScript.  Other than two basic method calls from Web Bluetooth, there are no specialty APIs or frameworks.
  • 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 Test page.
  • The user experience (UX) for WebAuthn+ is simple and friendly.
  • No cookies are used to track users in WebAuthn+.
  • WebAuthn+ enables the "Nirvana Solution" for authentication which will enable users to keep simple passwords (which is what they really want).
  • 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 password, then steals your smart phone, and defeats the fingerprint reader (or other security) before you can report your smart phone lost or stolen... then the bad actor can access your account.
System Architecture
First, take a look at WebAuthn from the FIDO Alliance.
The graphic below is from a Google I/O presentation which provides a comprehensive overview of WebAuthn from the FIDO Alliance.
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 in WebAuthn the process is primarily controlled by the browser.  WebAuthn is an extension of the JavaScript 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.
For step four to work in a secure manner the host's domain name needs to be sent from the browser application code to the Bluetooth Gatt Server running on the user's mobile device.  Application level (from within the browser code) messaging from the browser to the smart phone over bluetooth is not yet supported by the Web Bluetooth API.  The prototype uses a direct Java Script method call: 
domainNameCharacteristic.writeValue(textEncoder.encode(domainName));
With this direct java Script call, the domain name could be spoofed in a sophisticated man in the middle attack.  All that is necessary to make this process completely secure is a simple addition to the Web Bluetooth API.  A method needs to be added and this method needs to be run from within the browser context.  The domain name needs to be sent by the browser, not as a parameter in the Java Script method call (which would enable spoofing):
writeDomainNameCharacteristic()
This is the key problem that needs to be solved for web authentication to be secure:  a secure "out of band confirmation" that the user is on the "right" web page.  The solution is a simple addition to the Web Bluetooth API.
Once this change is made, excluding attacks against the operating systems, there is only one threat vector:  If a bad actor "looks over your shoulder", steals your password, then steals your smart phone, and defeats the fingerprint reader (or other security) before you can report your smart phone lost or stolen... then the bad actor can access your account.
Session Specific Pairing
The pairing process currently specified by the Web Bluetooth API is NOT user friendly.  "Session Specific Pairing" would be a great improvement.
Currently, JavaScript code in the web browser makes a request for a Bluetooth device advertising a specific service.  Any device with the service UUID within sixty meters will show up in the pairing screen.
The user must select from potentially multiple devices in the pairing list.  The reason for this manual selection has to do with security.  The creators of the Web Bluetooth API did not want a web application to pair with just any Bluetooth device that happened to be close by and advertising a specific service.
However, it is incredibly annoying to have to manually pair your mobile phone whenever you sign on, especially when your phone is the only device in the list.
The process would be far more efficient and secure if a session UUID was added to the filters for the Bluetooth.requestDevice() JavaScript method.  This session UUID would be sent to the mobile device by the browser and checked against the session UUID sent to the mobile device from the server.  With this change, Web Bluetooth pairing could become automatic and more secure (no chance of the user selecting the wrong device).
A "message" attribute could also be added to the filters; e.g., "{message: ['Activate your WebAuthn+ mobile app.']}"
Once the app is activated it will start advertising with the service UUID and the session UUID; it will be picked up by the browser and automatically paired.  Life will be beautiful.
Establishing a Trusted System ~ The Nirvana of Simple Passwords
Once the user successfully signs on, he/she can designate the system as a "trusted system".  In the future, the user can authenticate with a user name and password.
The password can be incredibly simple because the value that the user enters is combined with a UUID salt value that is stored on the user's system as a cookie (hence, the system needs to be secure).  The values are used to generate a cryptographic hash using the Stanford JavaScript Cryptography Library.
        var out = sjcl.misc.pbkdf2(password, sjclSalt, sjclIterationCount, sjclLength);
        var passwordHash = sjcl.codec.hex.fromBits(out).toUpperCase();
        console.log("passwordHash: " + passwordHash); // TODO: remove
A simple user password of "asd" becomes "7C3249A2415F53FC1A8A150C60C9347CBC14AE0C62C7C5C73FF4BC45A15ECFCA"; this value is essentially a generated password and is sent to the server over encrypted HTTPS.  The value is hashed once again with the Argon2id hashing algorithm (most secure) and stored on the server as a set of Argon2id parameters:
'$argon2id$v=19$m=1048576,t=4,p=8$HQiUtZvto2icGsXVTF/BJw$emWzw24cLFhmnd8WUhZDyjRJHCg1C0J9542yTPCiACE'
Whenever the user signs on, the hash values are recalculated and compared with the stored hash value.  Without access to the user's physical system and knowledge of the user's password, it is impossible for a bad actor to sign on,  even if there was a complete breach of the server data.  The user can use the same simple password across multiple sites because each time it will be combined with a different salt value and will be stored on different servers as a completely different hash value.
A cookie with a password on a trusted system is actually more secure than a digital certificate on a "trusted system".  With a digital certificate a bad actor just needs to access the system, either physical access or through malware.  When a cookie and a password are required a bad actor would need both.  Essentially, the cookie turns your trusted system into a "something you have" authentication factor.
Also, the user can always reset his/her own password.  There is no need to call tech support.
Everyone assumed that user names and passwords had to be eliminated in order to solve the authentication problem.  The paradox of the WebAuthn+ solution is that most users will be able to keep their user names and passwords, and passwords can become even simpler.
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.
No Bluetooth
How does the WebAuthn+ process work without bluetooth communication?
There will be times when a user attempts to sign on from a browser on a system that does not have bluetooth capabilities.  WebAuthn+ works with or without bluetooth communication.  Users with older systems are not excluded from the process.  The graphic below provides an overview.
The most important step is step 5:  The user must check the domain name which appears on both the sign on web page and on the user's smart phone.
Hover over the numbers below in sequence and you will realize how simple and elegant the WebAuthn+ process truly is.
Even without the bluetooth communication between the browser and smart phone working yet, the WebAuthn+ process is highly secure.  Excluding attacks against the operating systems, there are only two threat vectors when there is no bluetooth communication between the browser and smart phone.
First, if a bad actor can convince you that you are on "www.chase.com" when you are really on "www.chaze.com" a "man-in-the-middle" phishing attack can be launched.  The graphic below, from a Google I/O presentation on WebAuthn, portrays such an attack.
If a user is diligent about checking the domain name which appears on both the sign on web page and on the user's smart phone, all will be well.
In order to simplify the user's check, we clear the address bar of everything except the domain name.  The following excerpt is from our open source code:
Unfortunately, relying on users to check the address bar in their browsers is a bad plan.  A better plan is to send the domain name from the web browser to the user's mobile device for programmatic verification.
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 browser context:
writeDomainNameCharacteristic()
Every Web Bluetooth service would have a default "DomainNameCharacteristic".  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 password, then steals your smart phone, and defeats the fingerprint reader (or other security) before you can report your smart phone lost or stolen... then the bad actor can access your account.
If a bad actor kidnaps you and attempts to torture you into giving up your password, you will be able to give up a false password which will be a "duress code" that will lead the bad actor to believe access has been granted and will alert the authorities to your geographic location.
Other threats against the operating systems on smart phones are now less problematic (reading into another app's memory space, etc.), especially if you stay with the main app stores.  If you download a "free" copy of Angry birds from an Elbonian website, you will get what you deserve.
Implementation
Any organization with a significant IT staff will be able to take the WebAuthn+ source code and implement the system as a microcosm within their own environment.  For companies with a modest IT staff, WebAuthn+ will be provided as a service by one of the dozens of existing players in the identity management space.
Implementation and support are always the most difficult aspects in providing software as a service (SAS).  For users of WebAuthn+ as a service, the configuration will involve four very simple steps:
  • Modify CSS styles for a template authentication page.
  • Enter a JavaScript parameter for the URL of the App Server.
  • Configure a REST process to accept the user's credential UUID and authentication UUID when confirmed by the TNX Server (step 8).
  • Configure the Web App's authentication process to accept the authentication UUID (step 9).
In the graphic below, steps 1 through 7 are provided by the WebAuthn+ service provider.
Service providers will be able to incorporate the WebAuthn+ platform into their offerings.  We expect major corporate funding for this endeavor and the use of this technology will be completely free.  Until that funding is finalized, the source code is only available for prototyping and testing.  Click here for license details.
© Copyright 2020 ~ Trust Nexus, Inc.
All technologies described here in are "Patent Pending".