Hive Authentication Services - Protocol description
(Edited)
To avoid redundancies and inaccuracies, the content of this post has been moved to the official HAS Documentation website!
https://docs.hiveauth.com
Support the HAS project |
|---|
Vote for the proposal on Ecency vote for the proposal on Hive.blog Vote for the proposal using HiveSigner |
Check out my apps and services
Vote for me as a witness 
0
0
0.000
PIZZA Holders sent $PIZZA tips in this post's comments:
pixresteemer tipped arcange (x1)
@eii(10/10) tipped @arcange (x1)
Learn more at https://hive.pizza.
That is a great insight into the technical aspects of how authentication works on Hive blockchain. Usually, we treat it lightly but is the most important component that puts our mind at ease at night...
Posted Using LeoFinance Beta
Thank you @behiver. Can't wait to get your vote to support the HAS proposal
Keep up the good work @arcange am really enjoying to see this happening in this platform. It's really awesome
Thank you @emeka4
I'm going to need to learn how to speak Blockchain 🙊 @oneup #oneup #hiveblogshare @doomz
!PIZZA
!BEER
Following this closely for two reasons, it's an awesome feature for hive, but also for the education. These posts are really well explained and accessible. A lot is way over my head but i am getting some good stuff.
Thank you for your feedback @eroche
Education is the key to getting people to buy into a project.
PS: Do not forget to vote for the proposal to support the project. 😉
Pretty and Smart, we should marry this idea.
Congratulations @arcange! Your post has been a top performer on the Hive blockchain and you have been rewarded with the following badge:
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPThank you for this post. He sheds light on the structure of the project.
"Where the darkness is, he will bring the light" 💡
arcange, 2021.10.22
Nice job! It looks like the security of the protocol depends on how good communication channels are protected ( I suppose You assumes protection by HTTPS or any other server authentication and channel encryption), otherwise, malicious actors may listen and/or spoof the protocol messages. My question is do You plan to use the Hive chain to hold information about the valid HAS servers and their public keys/certificates, or the system will depend on external certification entities ? I mean the App may ask the Hive Blockchain for a list of valid HAS servers and all the information required to establish a secure connection with them.
Thank you for your feedback @mickiewicz
I go much further. HTTPS only secures its communication but not its content. HAS protocol will use encryption extensively to validate the data exchanged between the parties.
It is important that the HAS server itself cannot access the content of the communications. If that was the case, it could easily modify the exchanged data and lure either the application or the Wallet app (PKSA).
This is a possible solution, but it is not planned at first.
No. The protocol was designed not to depend on any external entity and to allow full decentralization. It will work as we are used to with Hive API nodes. We can even imagine integrating HAS as a microservice deployed on each Hive API node.
@tipu curate
Upvoted 👌 (Mana: 62/82) Liquid rewards.
Hats off, great idea. Hive has to seemlessly fit in the web.
Voting for the proposal.
Thank you for your support @marki99
Hello @arcange… I have chosen your post about “-Hive Authentication Services - Protocol description-” for my daily initiative to re-blog - vote and comment…
Let's keep working and supporting each other to grow at Hive!...
Super nice diagrams (they help a lot understanding this). I can see already the Hard work behind the scenes... so well done for this.
Some questions from me for each of the steps:
1. Looks all good here. 😎
One request though, even if the QR code is a great way to simplify the validation of who is requesting, it would be nice to have a way to see the IP of who is requesting, to allow users to have a second way to troubleshoot things when they are not making sense.
I am thinking about phishing situations when eventually users get emailed with QR codes in the name of the apps asking for authentications (of course no one should do this).
This IP (or session) validation could be done either at the PKSA side (and visually validated by the user) or using a phishing code as 3rd-step of an MFA (in case you activate it) provided by the library the "apps" would need to use. Effectively stamping that "confirmed" session in the blockchain. Comments...
2. and 3.
How is the user able to understand if the transaction request is from the browser/app/host he/she is requesting/interacting with?
For example, if I use the phone to accept and broadcast a transaction that is initiated on my PC. Is there a mechanism that only allows this after the authentication happens (which I would say, that can either have protection towards the active session, or something like, identify the session with a name or IP)?
I am looking at the same perspective of what I described on the authentication, and I understand that at the same time we want to make this simple for the user. So, maybe either provide a way to identify sessions (if multiple are allowed) or only allow one to persist, forcing the user to first authenticate before going through sign/broadcast transactions.
The scenarios above are probably important for public places where wireless devices can be trying to listen and be also man's in the middle. But I agree for most situations it will not be a problem.
Thanks
Cheers for all this work and the courage to deep dive into resolving this "complexity" problem for the community. Feel free to always tag me on these. My pleasure to support/review/discuss stuff like this. Hopefully, the proposal will go ahead.
Thank you for your comment @forykw
Not sure it will help. When you're on mobile, people often don't even know which IP they use or how to display it, as the "requester" is the device itself, not an app running a remote server.
Moreover, the incoming IP seen by the PKSA will always be the one of the HAS it is connected to.
That being said, the App and the PKSA can display the uuid of the request for the users to match it.
This will be explained in details in the coming posts. TLDR; communication between App and PKSA is a one-to-one once the user authenticated with an App
Ok, I can wait for it. Maybe in the HiveFest we can chat... easier.
PS: I was not covering people that know how to deal with IPs... but instead the other way around, the ones that don't know and will get "tricked" by people that wish to take the glorious stupid creative path.
In normal circumstances yes... but behind firewalls anything can happen. And big commercial buildings have huge problems with these. Most household ISPs will be ok... but when we move to IPv6, this will be uncontrollable. Not something to worry for the immediate future, but something to think about ahead of time and make some "preventive" countermeasures.
Thank you for providing such a level of technical detail on HAS! I am convinced of its security, but what do you think about voting for or against it? Is there any reason not to support this proposal?
Thank you for your comment @catotune
Honestly, I don't think I'm the best person to answer this question as I'm really convinced of the added value for Hive of this project. 😅
Ok NOW i love it <3
Just WOW - great job and a !BEER from me
Will get my vote
Thank you @detlev. Have a !BEER too
Would love to see your idea work. All the technical data above are confusing to me but it looks like it's for seamless and easier transactions. You have my vote :)
Thank you for your vote @ifarmgirl, really appreciate it!