SQRL for non website login


Status
Not open for further replies.
G

Gristle

Guest
Hi,

I'm curious about how to apply SQRL's technology to non-website login, such as logging in to an app, or SSH server, or any service that doesn't necessarily have a unique and static domain name. Since the static nature of the domain name is what binds a user to their identity, any ideas how would this work? I have a few ideas but I'm curious to hear from this community.
 
  • Like
Reactions: Hzy

ramriot

Well-known member
May 24, 2018
134
15
Hi,

I'm curious about how to apply SQRL's technology to non-website login, such as logging in to an app, or SSH server, or any service that doesn't necessarily have a unique and static domain name. Since the static nature of the domain name is what binds a user to their identity, any ideas how would this work? I have a few ideas but I'm curious to hear from this community.
There was much discussion of this in the early days under 'Alternative Use Cases', some of it I tried to document on the Wiki but some of those pages seem to be gone now. It all comes down to how far can we stretch what an existing client does before we need to write an alternative implementation.

As currently accepted, web based authentication requires secure HTTP endpoints accessible via static domain names, such that the internet based communication can be assured as e2e secure & we have a reliable string to use as the unique Realm for keying. There is no reason the protocol cannot be used other other communication protocols provided there SQRL server can provide a static Realm, secure communications & a nonce NUT.

As to the two cases you mention though I think mostly we could make those work as normal web authentication where the web portion is replaced with a launch point from the service done via remote authentication mode through a QR_Code or SQRL link.

Many alternate use cases can be made to work around that principle e.g:-
  • Point Of Sale: Where the SQRL client is used via remote QR_Code scanning to authenticate a financial transaction where the service provider knows you & maintains credit for you. (Vending Machines). This also made use of the mostly deprecated SFN url parameter so the client could display a description of the requested transaction as well as the domain name for transaction identity confirmation.
  • Door Access Systems: Where there would either be a printed or dynamic QR_Code displayed by a door such that your SQRL client authenticates to the service against a known NUT value which the service associates with this specific entrance & can operate remotely. This also made use of the now optional second authentication loop "query" then "auth" so that even if a static code was used, replay attacks could be mitigated by having a second dynamic NUT authentication loop between client & server.
Outside of this we looked at other use cases where minor changes would be required e.g:-
  • BlueTooth / NFC door locks with no internet connection where since the communication would be all between client & lock over short range secure radio it is possible to dispense with using HTTP DNS & use a unique device serial number as the Realm where it generates random NUT on each query.
 
G

Gristle

Guest
The use case I'm considering is a replacement for SSH keys.
 

AlanD

Well-known member
May 20, 2018
129
23
Rutland, UK
That was exactly the proposal that I was suggesting some 3-4 years ago. To allow SQRL rather than SSH authorized keys, or passwords. My thought is that the easiest way might be to write a module which interfaced to PAM, and could be called by any application that needed to verify a user, e.g. SSH, or POP/IMAP mail.

I don't have the skills to write such a module, but conceptually it sounds simple.
 
Status
Not open for further replies.