StellarAuth

Authenticate using your Stellar account

Summary:
Authentication, identity and security are all hard to get right but Stellar has all of these built in at the core level, so why not take advantage of these features and put them to use for something other than just value transfer? Authentication at its core is simply a process for providing appropriate permissions for specific actions. Stellar transaction submissions are uniquely qualified to provide this service via the signatures concept. You can tweak access nearly infinitely simply by using signers as the block. If a transaction is successfully signed and makes it to the ledger you can rest assured any dependent action now is safe to execute.
Take application login for instance. If a Stellar account is tied to a user object you can block access to the user object until the associated Stellar account successfully submits an authentication transaction. Tie that account to StellarGuard and you've got a fully secured multi-signer 2fa authentication flow essentially for free.
This is the mission of StellarAuth, a tremendously secure, yet fully flexible permissions service.

Links:

How it works:

  1. Make a request to access something secure via a public Stellar account
  2. Receive back a partially signed transaction XDR
  3. Sign and submit that transaction via your favorite wallet
  4. Verify the transaction hash and pass the success or failure to load or block whatever you're securing

Features:

  • Auth requests must be signed only by the requesting account
    • Entire transactions are secured not just individual operations
    • Transactions must be sent and verified by the the ledger not just signature checked
  • Requests must be timed and valid only for a short period of time
    • Just because a transaction is valid today doesn't mean it should be valid 2 years from now
  • Requests should not drain the account of any balance, not even the transaction fee
    • Transaction fees are covered by the StellarAuth service
  • Universal support of third party wallets and signing apps (like StellarGuard or Ledger)
    • Should be able to plug in and use StellarAuth with existing systems

Future features:

Just checked out your code. Binding the hash of a pre-signed transaction to the auth session is quite a clever technique to prevent timing based attacks to circumvent login.

It's come to my attention that StellarAuth is incredibly similar to SEP-0010 and as it does serve the same purpose I'm opening up a discussion on the differences between StellarAuth and SEP-0010. SEP-0010 has been around for awhile and it's to my shame for not doing better research around existing proposals and solutions to the authentication problem of Stellar. However after digging in and discussing with @nebolsin and @cballou I think there's still room for StellarAuth as a vehicle for getting SEP-0010 wider adoption and for adding the appropriate updates and changes which could make the proposal more secure and usable. To that end I'm going to dig in a bit into the internals of StellarAuth and point out the difference to SEP-0010 and why I've made the choices I have and why they may in fact be preferable to SEP-0010 as it stands today. Discussion is welcomed.

The largest difference would be that StellarAuth requires a transaction to be submitted to the ledger while SEP-0010 just verifies the transaction signatures. The reason for this I assume was to keep Stellar from being flooded with authentication transactions by only using the signature check functionality to verify identity rather than going the whole way to push a transaction into the network. While I understand the sentiment I A) don't think the volume would be large enough to make a difference, (if it were we'd have larger problems) and B) I think there's a lot of value to be gained by having login records embedded into the ledger. Immutable access logs are a powerful security measure and with tools like StellarGuard you can get TFA essentially for free. There's a reason we have blockchain and not just successful signatures, there's more to security than signing things.

Additionally there are several concerns I have with SEP-0010 when actually using it most significantly in the areas of additional signers and replay attacks.

SEP-0010 relies on the maxTimeout of the transaction to determine how long any given transaction can be used for verification and as long as you're under that timestamp you can use the same XDR to verify a session. This is probably an unwarranted concern though as the XDR must be successfully signed before it can generate a session but best practice would say once a challenge (transaction) has been used to generate a session it shouldn't be able to be used again ever in any case, currently it can. StellarAuth combats this be proactively generating a JWT which will remain invalid until the transaction it's associated with is submitted to the ledger. Each session then is tied individually and only to a specific pre-ledger transaction. To gain access to that session you must have access to the transaction and once it's been submitted the JWT goes live and replay attacks become a non issue as there's nothing to replay.

The second concern I encountered was specific to the implementation of SEP-0010 in the Evil Martians' demo in the fact that they bypass additional signers like StellarGuard. While this isn't specific to SEP-0010 and you could implement further checks on your own, it calls into question again the choice not to push transactions live to the ledger. In StellarAuth you would be blocked from authenticating until the transaction made it successfully to the ledger which will encompass all the checks including signers but also any future blocks which may be implemented. With so many potential pitfalls here and any given implementer of SEP-0010 left to handle this responsibly on their own it leaves SEP-0010 a little thin right now and opens the door for a service like StellarAuth to fill in the gaps and ensure all possible scenarios are covered.

One of the cool things about StellarAuth is its flexibility for far more than just login. Since the account acts as a sort of “role” you could create some pretty complex authentication scenarios. By just adding signers you can block authentication until all signers have added their signature. You can also create “teams” by adding all team members as signers with the same weight. Now any of them could sign into a single company account via that one Stellar account. Add custom metadata, home domains, assets, trustlines etc. and you’ve got room for a very robust authentication flow all from within the Stellar ecosystem. Some of this could work alongside SEP-0010 but because you aren’t actually submitting transactions to the network the functionality and checks for the authentication would have to be made on the implementers side rather than on the Stellar side greatly reducing the usefulness of the proposal as it stands today.

Ultimately it may come down to preference. Perhaps you don't want to flood the ledger with auth transactions or have to worry about the transaction fees. Perhaps you want to be able to authenticate accounts which don't even exist on Stellar or have been locked out due to high weights and a lack of appropriate signers or maybe bypassing additional signers is a non issue. It's possible but I don't think it's ideal or a good default. Both could be options but actual submissions to the ledger should at least be an option if not the recommended default in my opinion.

Apologies again if I've misrepresented or misunderstood SEP-0010 in any way, feel free to correct me and discuss further. Authentication via Stellar is an important yet tricky subject and the discussion is worth it to ensure we get it right.

    @tyvdh It's great to see some more work going on the web authentication / authorization using Stellar accounts. I'm happy that we can continue the discussion about this complicated problem and put more thought into the design.

    You definitely made some great points and in the following posts I'll try to address them, elaborate a bit on SEP-10 design decision and share my current thoughts on the subject. It might take a day or two to write, so let me start with a few links to the previous discussions and relevant materials to get some common ground for discussion and provide context for future readers:

    @tyvdh

    Great that you start a community discussion on that matter!

    When it comes to user authentication, publishing the transaction on the ledger has several drawbacks:

    • It makes user activity public. Do you really want to fill a log of each time you log into your mailbox, your newspaper website or your favorite forum ?
    • It comes with a cost. Do you really want to pay a fee to log in?

    In fact, the very idea of signing transactions that could be submitted for login purpose seems wrong to me. I would prefer signing a sequence=0 transaction, using a randomized challenge to prevent replay attack.

      MisterTicot Fair points, though if you're using Stellar all your payments, trades and deposits are already public, something I would argue is much more private than authentications. Also no one will have any idea what you're logging into or even who you are, just that this address successfully authenticated something, that's random enough to be a non-issue for me. For the fees StellarAuth comps them as part of the authentication transaction. The transaction you submit has an operation which pays back the transaction fee. I understand the sentiment behind SEP-0010 not pushing to the ledger but I still hold that the benefits to submitting to the ledger outweigh any negatives and that really not submitting poses more risk than it's worth.

          Just added SEP-0007 support for both the test and public networks!

          Try pasting
          web+stellar:tx?xdr=AAAAAOawgDnjTgvRIJ6OhEO6oMgb3yswewQsMxMkokCNizz4AAAAZAAGlxEAAAACAAAAAQAAAABdAqruAAAAAF0CuP4AAAAAAAAAAQAAAAEAAAAA3OA2klSdlKofmbLxzJd8VllfpZH1pONSUSQ32iY0fPAAAAABAAAAAOawgDnjTgvRIJ6OhEO6oMgb3yswewQsMxMkokCNizz4AAAAAAAAAAAAAABkAAAAAAAAAAEmNHzwAAAAQCuByUMqraxXOW%2BnrB7L8aBM2WjxiUtsqrMrpqmaKxyoioie0iHAU9fZtEre9%2B%2Bn0RUN67YTy0cdATYT0SXpoQI%3D&msg=StellarAuth+transaction&origin_domain=stellarauth.com&network_passphrase=Test+SDF+Network+%3B+September+2015&signature=4s2cBtu3lIU1aC0ss5DOadcKU2pjPbTNIOYfwKsiMq%2F%2B4MzWTtpBEGkpD6vFb7Ql0mIAiB5yWvdmW%2F6FiXoUBg%3D%3D
          into https://stellarguard.github.io/stellar-uri/demo/

          Thanks @StellarGuard for the heads up!

            tyvdh @StellarGuard

            Can also be played with here: https://cosmic.plus/web-cosmic-lib/demo?xdr=AAAAAOawgDnjTgvRIJ6OhEO6oMgb3yswewQsMxMkokCNizz4AAAAZAAGlxEAAAACAAAAAQAAAABdAqruAAAAAF0CuP4AAAAAAAAAAQAAAAEAAAAA3OA2klSdlKofmbLxzJd8VllfpZH1pONSUSQ32iY0fPAAAAABAAAAAOawgDnjTgvRIJ6OhEO6oMgb3yswewQsMxMkokCNizz4AAAAAAAAAAAAAABkAAAAAAAAAAA=&network=test

            It won't support the msg parameter because I think this is insecure. Basically, it allows any untrusted service (an arbitrary transaction emitter) to display a message into a trusted interface (the wallet). At some point, SEP-0007 author said about removing it for that very reason, but somehow it's still here. In any case, I think wallet-independent services should clarify the purpose of the transaction before sending the request - which your app does very well.

              Nice to see CosmicLink put at use.
              Testing your poc went flawlessly, just as I like.
              I hope you'll release an open-source library for this feature 🙂.

                MisterTicot 😃 Great to hear!

                The code for the poc is here:
                https://github.com/TinyAnvil/stellarauth-nuxt
                https://github.com/TinyAnvil/stellarauth-postgresql

                The code for the actual StellarAuth API service is here:
                https://github.com/TinyAnvil/stellarauth-serverless

                Obviously still more I want to do and future versions will be more useful as I build out the poc into a more full service.

                Appreciate you trying it out, reporting back and voting! Your CosmicLink apps are amazing.

                  Your summary is bad.

                  I tried to read it to understand what you do. After reading the first two paragraphs I kind of got bored and was too lazy to read the rest.

                  It needs a clear and concise description so that regular people can read and understand it .

                  I still don't understand what the project does.

                  Does it allow me to make a purchase online and transfer Lumens to a vendor knowing 100% that his payment address is actually his and not a phishing account?

                  Authentication at its core is simply a process for providing appropriate permissions for specific actions. Stellar transaction submissions are uniquely qualified to provide this service via the signatures concept. You can tweak access nearly infinitely simply by using signers as the block. If a transaction is successfully signed and makes it to the ledger you can rest assured any dependent action now is safe to execute.

                  This reminds me of the Charlie Brown cartoons when the adults speak. Bla, bla, bla, bla, bla, bla, bla.

                  Okay, now in twenty words or less please tell me what your project does?

                    tyvdh Here're the main reasons why SEP-10 uses off-chain transactions:

                    1. privacy — for security reasons we want the auth transaction to include the name of the entity it authenticates with, and you don't always want to make the log of your authentication sessions a public knowledge. SEP-10 is designed to work with traditional web services, which could work on top of their own databases and don't necessarily leave any traces of you using the service on a public ledger.
                    2. genericity — using on-chain transactions limits authentication to accounts which exist on the network, while with off-chain flow you can authenticate with any Ed25519 keypair. For example, as an extra protection against scam and user mistakes, traditional exchange like Binance could use the SEP-10 authentication flow upon XLM withdrawal to ensure that user has control over the destination account. Another use case is a multisig orchestration service, where signer needs to authenticate in order to get the list of transaction pending his signature (and Ed25519 account signer in Stellar is just a keypair which doesn't necessarily exists as account on the network).
                    3. speed — with on-chain transactions you have to wait for the next ledger to verify the tx, which slows down the process and increases the integration complexity with handling delays and retry semantics
                    4. cost and unnecessary load on the network — you already discussed this above, but I'd like to point out that refunding user's transaction fees via service's own funds is not a scalable model

                    tyvdh best practice would say once a challenge (transaction) has been used to generate a session it shouldn't be able to be used again ever in any case, [but with SEP-10] currently it can

                    In SEP-10 challenge transaction includes cryptographically strong random nonce, and the issued JWT is linked to the challenge transaction through jti claim. So when it's necessary the implementation can keep track of the nonces and provide strong replay guarantee, but in simpler cases you can keep auth service stateless which is a lot easier.

                    tyvdh With so many potential pitfalls here and any given implementer of SEP-0010 left to handle this responsibly on their own it leaves SEP-0010 a little thin right now and opens the door for a service like StellarAuth to fill in the gaps and ensure all possible scenarios are covered.

                    SEP-10 is intentionally minimalistic and only focused on the authentication (not authorization, which can be defined by higher-level SEPs or by the particular service like StellarAuth). It defines a simple challenge-response flow which allows a client, identified by Ed25519 public key, to prove the possession of the corresponding secret key to an external service and exchange it for service-specific auth token. It's designed to be implemented by wallets, and it puts minimal required restrictions on the service side of the process to support as many use cases as possible.

                    And before diving into SEP-10/StellarAuth compatibility discussion, I would love to better understand the use case StellarAuth is targeting. Can you please share some specific examples of how projects would integrate and use StellarAuth?

                            deylandra Ha! Sorry for the confusion, I agree it's not crystal clear and even as I've become aware of SEP-10 and SEP-7 things have changed a bit. So in 20 words.

                            StellarAuth is an authentication API service which generates pre-signed timed transactions primarily for use as authenticated web sessions.

                            At the end of the day it's an API for developers to implement into their services as a sign-in method or permissions system. Think login (how the demo uses it) or as a prerequisite to performing some protected action like updating a password or email address. It could also be used as an alternative to tools like Authy or Google Authenticator especially when paired with multisig services like StellarGuard or Lobstr Vault.

                              tyvdh changed the title to StellarAuth - Authenticate using your Stellar account .

                              nebolsin Thanks so much for the thorough response and clear reasoning. Those are all legitimate reasons to keep a transaction off-chain, especially for the genericity and speed. I don’t think privacy is really an issue considering what is stored on the network and I personally disagree that refunding is not a scaleable model. It’s actually quite common for services to refund or comp network fees.

                              nebolsin In SEP-10 challenge transaction includes cryptographically strong random nonce, and the issued JWT is linked to the challenge transaction through jti claim. So when it's necessary the implementation can keep track of the nonces and provide strong replay guarantee, but in simpler cases you can keep auth service stateless which is a lot easier.

                              Great point. This is something I actually do in StellarAuth now via the memo and a double hashed SHA token.

                              nebolsin SEP-10 is intentionally minimalistic and only focused on the authentication (not authorization, which can be defined by higher-level SEPs or by the particular service like StellarAuth). It defines a simple challenge-response flow which allows a client, identified by Ed25519 public key, to prove the possession of the corresponding secret key to an external service and exchange it for service-specific auth token. It's designed to be implemented by wallets, and it puts minimal required restrictions on the service side of the process to support as many use cases as possible.

                              Also fair enough. I think fundamentally SEP-10 is a really good starting point for building on top of with slightly higher level services like StellarAuth. Gives some good guidelines for best practices and how you would create a baseline for authentication. What it really needs is some strong implementation use cases you could point to so folks could get how it’s meant to be used.

                              nebolsin And before diving into SEP-10/StellarAuth compatibility discussion, I would love to better understand the use case StellarAuth is targeting. Can you please share some specific examples of how projects would integrate and use StellarAuth?

                              For sure, and I’ll have to tip my hand a little here, StellarAuth is the beginning of something much larger for me. I’m not ultimately targeting existing Stellar users or just login. The next iteration of StellarAuth will actually be a signing wallet which can be managed directly by applications. In my mind Stellar is a low level library not a high level service. For Stellar to succeed it will need to be adopted as a transparent service where users have little to no idea of secret keys or copying and pasting xdrs or remembering bip32 phrases. It will need to be much much simpler than it usually is.

                              This has become incredibly clear to me as I’ve worked on Colorglyph 2.0. Most of my work since launching that app has been around how do I build modern usable applications utilizing everything Stellar has to offer while not limiting my audience to an existing and limited user base of crypto savvy nerds? I want to build for usage not users. I want Colorglyph to be appealing to anyone, not just those with existing Stellar accounts or those who have the knowhow or courage to dive into it. I want my mom and brothers, my sisters and cousins, my neighbors and friends, very few of which do or will ever care about Stellar as a company, to be able to jump right in and play with minimal technical friction. This will require a massive shift from our current thinking when it comes to how we build Stellar apps and who we build them for.
                              For me that boils down to abstracting Stellar away into services other applications like Colorglyph can implement to gain all the benefits of Stellar without having to surface any technical friction directly to their users. StellarAuth is the linchpin for this initiative. An onramp into the network which is managed by applications but controlled transparently or familiarly by users. The goal would be for StellarAuth to have a client facing web, mobile, browser extension app which serves as a sort of Authy or Google Authenticator for Stellar. The permissions gateway for applications to perform actions on a users account. Much like StellarGuard or Lobstr Vault do today. The big difference is that StellarAuth will be both a signing app and a wallet. New accounts can be created transparently from the application side much like you would add 2FA to an account today. From there future transactions submitted to the network would pass through this client app for the final yes/no.

                              This is obviously far from what StellarAuth is today, though not as far as it may seem. It is clear then that for my use case funded accounts and actual transaction submission to the ledger would be baked into what StellarAuth would be doing. If StellarAuth was just authenticated web sessions than SEP-10 would likely be sufficient, but as you can see I have bigger goals than just login.

                              All that to say there probably isn’t much or anything that needs to change with SEP-10, it’s been an incredibly helpful SEP along with SEP-7 for guiding the future of StellarAuth and ensuring I’m building a compliant, secure and usable service.

                                      Definitely want to continually advocate for this to push forward SEP-0010 — I know @nebolsin has had a lot of they've wanted to refactor and make better about it, and if any of this project ends up making SEP-0010 better, that would be amazing.

                                        theaeolianmachine I'd love to hear more about what @nebolsin has planned for SEP-0010. Curious what they see as potential shortcomings or where things could be improved or expanded on.

                                          12 days later