Summary

Cosmic.link is the next-gen solution for signing Stellar transactions from various applications without granting them control over your account.

Cosmic.link is user-friendly, open-source, vendor-neutral, community-designed, and production-ready.

Live Example

Goals

  • Provide a user-friendly yet secure way to explore the Stellar ecosystem.
  • Provide a standardized solution for passing transaction requests between applications and wallets.
  • Provide useful open-source libraries to the community.
  • Raise awareness around issues related to asymmetric cryptography & the cryptocurrency security model.
  • More specifically, raise awareness around the one golden rule in crypto: "Never share your private key!".

At that time, those goals have been met − except of course the part about informing the community which is a never-ending task. Most of the work is currently focused on continuous improvement, communication, and partnerships.

Description

CosmicLink is a project made of several components: an open protocol, a web front-end and several open-source libraries.

Please keep in mind that the front-end (Cosmic.link) is only the emerged part of the iceberg.

What is Cosmic.link?

Cosmic.link is a solution for signing Stellar transactions from various applications without granting them control over your account.

Each CosmicLink contains a request that is displayed on your screen. Then, you can pass it to your wallet where the transaction can be double-checked & safely signed.

Your secret key never leaves your wallet, as it is meant to be.

Why Cosmic.link?

Before Cosmic.link, Stellar applications had two ways to have you sign transactions:

  • Have you create and fund a new Stellar account, which they would control.
  • Ask for your secret key.

Having as many accounts as applications is painful, and sharing secret keys is dangerous. Cosmic.link solved it all thanks to an innovative solution: transaction requests.

How does Cosmic.link work?

Transaction requests get encoded into what is called a query string for the purpose of passing them into normal web links:

?type=payment&destination=tips*cosmic.link&amount=20

Transaction requests can then get passed to any compatible service by using their address:

https://cosmic.link/${tx_request}
${handler}${tx_request}

When applications generate those links, they choose which handler to use (it doesn't have to be Cosmic.link). Here's, for example, the request on the cosmic-lib demo interface.

In some cases, it is possible to pass the request directly to the users' wallets. For example, here's the same request pointed at Stellar Authenticator. (You can view it by clicking Guest Mode)

In other cases, wallets don't use the same format for transaction requests, and conversion has to happen. Cosmic.link does it under the hood.

Which Services are Compatible?

Thanks to its open design, CosmicLinks can be implemented in any software, independently from any organization or service. There's a growing list of compatible services, some of them being well-known to the community:

Applications:

Wallets:

*: For now, those wallets only support a subset of possible transactions.

Libraries

Cosmic.plus philosophy is to provide the community with as many reusable components as possible. Some of them are among the most downloaded Stellar libraries, which is greatly motivating!

The following libraries have been developed in the context of the CosmicLink project:

cosmic-lib

This is the JavaScript implementation of CosmicLinks. It features helpers to create transaction requests:

const { CosmicLink } = require("cosmic-lib")

// Create a request.
const txRequest = new CosmicLink({
  network: "test",
  memo: "Hello, World!",
  maxTime: "+5"
}).addOperation("payment", {
  destination: "tips*cosmic.plus",
  amount: 20
})

// Open the signing interface.
txRequest.open()

It also provides helpers for wallets to receive and sign transactions:

const { CosmicLink } = require("cosmic-lib")

// Configuration.
const network = "public"
const source = keypair.publicKey()

// Parse, sign & send the transaction.
const txRequest = new CosmicLink(location.search)
await txRequest.lock({ network, source })
txRequest.sign(keypair)
const response = await txRequest.send()

Open the documentation

@cosmic-plus/ledger-wallet, @cosmic-plus/trezor-wallet

Popular hardware wallets support, as simple as it can be:

const ledgerWallet = require("@cosmic-plus/ledger-wallet")

// Connect with the device.
await ledgerWallet.connect()

// Get the public key.
const pubkey = ledgerWallet.publicKey

// Sign a transaction.
await ledgerWallet.sign(transaction)

Open the documentation

@cosmic-plus/tx-result

A convenient helper that tells you if a transaction has been validated, and if not, what went wrong:

const TxResult = require("@cosmic-plus/tx-result")
const result = new TxResult(horizonTxResponse)
// {
//  validated: false,
//  title: "The transaction has been rejected",
//  errors: [
//    "Operation 1: The destination account doesn't exist."
//  ]
// }

Open the documentation

Other Contributions

The very nature of CosmicLink is to make connections with other developers and open-source projects.

As the Cosmic.link maintainer, I'm constantly checking over projects such as stellar-sdk, @ledgerhq and trezor-connect.

I'm writing bug reports and pull requests to them when necessary. Lately, this led to major improvements in Trezor wallet support. At that time, I'm working on getting the new Stellar operations into Ledger & Trezor firmware (manageBuyOffer, pathPaymentStrictSend). #Ledger #Trezor

I'm also cooperating with community projects that are looking into using Cosmic.link. For example, I've recently worked with StellarAuth, StellarPay, Lumenthropy, PublicNode, and r/stellar community.

Future

The development of CosmicLink is centric to Cosmic.plus (hence the name). It's been continuously developed since two years, and there's more ahead. Here are the ongoing developments:

  • Publish comprehensive, not-so-technical documentation.
  • Publish explanations about how to host an alternative CosmicLink relay.
  • Publish a library that makes high-level integration even easier.
  • Publish a TxRequest library that doesn't depend on StellarSdk (450kb).
  • Design a solution for applications to acquire user publicKey/wallet.
  • Provide helpers for short-circuiting Cosmic.link (direct application-wallet communication).

Links

Application: Cosmic.link

Organization: Cosmic.plus | @GitHub | @NPM | @CodePen

Weekly updates: Reddit | Twitter

Talk: Keybase | Telegram

Your vote matters

Cosmic.link is an ambitious open-source project. Because it doesn't receive direct funding, community support is critical in financing its continuous development. Thank you! 🙂

    4 days later

    Never (Ever) Copy/Paste Your Secret Key

    20 years ago, people made their first steps with email and online payments. Many of them learned the hard way. For scammers, it was an age of abundance. Things improved thanks to two keys: education and better software design. Today, that’s exactly what crypto needs and, users are fortunate, the rules are simple. Rule 1. Keep your secret key secret / Rule 2. Never (ever) break rule 1. Let’s talk about it.

    Read more...

    9 days later

    Continuing the discussion from this StellarTerm thread as my reply mostly relates to the "clipboard vulnerability" described here and CosmicLink itself.

    @gleb correctly pointed out that web pages have to request special browser permissions to interact with the clipboard content. Moreover, reading data from the clipboard can be executed only in response to a direct user action such as pressing a button. And the only way to do it in the background is to have the ability to execute arbitrary userspace code on the client-side. The thing is that neither of the existing key management approaches (including yours) protects a user if the local environment has been compromised.

    Yes, using the clipboard for sensitive data is not recommended because it somewhat simplifies the attack, and that's cool that you are raising awareness. But in your comment, you refer to the far-fetched arguments. That's like agitating for physically damaging the integrated laptop webcam to prevent the potential private information leakage. The webcam access is sandboxed in the browser and requires explicit access confirmation (just like the Clipboard API), but if the attacker has root access to your computer, nothing will help you. So it all comes to the client environment security in the end.

    However, instead of admitting that you exaggerated the copy-pasting problem (intentionally omitting the attack prerequisites) to support your point, you are throwing pretty aggressive comments. And going even further, you directly accused StellarTerm team of deliberately weakening the application security or intentionally misleading the users (not quite clear what you ment here) to gain some mysterious "profits":

    Properly informing people about how to stay safe is critical to the success of cryptocurrency. When a security-educated developer finds profitable to communicate against that goal − because that's what the whole story is about − that's a serious issue.

    I realize that you (both) are making efforts to turn this into something personal or, at least, into a trolly debate on an unrelated matter.

    Again citing your words, "Dude, that's off-limits." Clearly, you started all personal trolly debate on the unrelated matter.

    It looks like I also need to expand my previous statement on CosmicLink UX, to illustrate my point. To my mind, CosmicLink isn't suited for usage in most Stellar-based applications as a primary log-in and transaction signer option, and here is why.

    Let's imagine that StellarTerm throws away the existing logic and adopts CosmicLink instead.

    1. Each action takes a lot of time and requires multiple confirmations.
      Case: a user wants to remove two active DEX offers and place a new one. Each time she has to wait for the redirect to CosmicLink website, confirm the transaction, wait for the redirect to, say, a SEP-0007 wallet, confirm the transaction again (this a required step, I guess there is no need to explain why this is important), provide her credentials, press "submit", and wait for the redirect back to StellarTerm. Repeat this 3 times yourself and you will understand why this is frustrating.
      Users that actively trade or send payments on Stellar network will have a nightmare user experience, with each action taking 10 times longer than before. Of course, some people are ready to overcome difficulties, but most regular users will just switch to another Stellar DEX GUI (StellarPort, StellarX, InterStellar, you name it). The situation is better with hardware wallets because it's only one hop, but here comes the next problem.
    2. Single-page applications (like StellarTerm, StellarX, Lobstr, and many others) rely on the client-side state. When a redirect occurs, the application is unloaded and loses the entire current state. So it either needs to encode and transfer the state in the callback URL, or save it temporarily somewhere, for example, in the browser local storage.
      The former approach may be insecure (both CosmicLink and target signer app potentially have access to the private information), and the latter doesn't work out of the box when a user has more than one tab open (e.g., all markets page and current user's active offers page in our case). This can be addressed, but it really requires some additional coding. And a user gets old-fashioned website redirects experience instead of the streamlined UX of single-page apps with smooth navigation and responsiveness. That's also one of the largest problems of the SEP-0007 standard from my perspective.
    3. There is no way to retrieve the user's public key.
      The only way to implement this with your current logic is to ask a user to sign, say, an empty transaction. We won't ask a user to input the public key directly, right? Because asking for a public key and then using a delegated signing to confirm the transactions is the worst UX I can imagine.
      Case: a new user wants to check the current account balance, see open orders, and maybe exchange some assets. And when she clicks "login", the browser redirects her on some third-party website that proposes to sign a suspicious transaction that she didn't request. Such behavior will definitely scare away most users.
    4. Poor onboarding flow for new users.
      Case: a new user decided to explore StellarTerm and see how it works. When she clicks the login button, the browser redirects her to the CosmicLink website, which is literally hostile to newcomers. What transaction should she sign if she doesn't have any Stellar account in the first place? What's the signing method, and which one she supposed to choose, "Stellar Laboratory" or "Copy/Paste XDR"? What does the "Register as web+stellar links handler (SEP-0007)" means? What's an "Automatic redirection"? I'm developing on Stellar for years, have read through all available documentation and standards, but some things are not entirely clear even for me. For newcomers, this may be a huge stopper. And I doubt that StellarTerm or any other popular Stellar application will be eager to lose ten times more users during the onboarding. It is complex enough process with a low conversion rate even without the delegated signing.
    5. How do you suppose to support mobile platforms? Maybe this is covered somewhere, but I didn't find. Opening a CosmicLink URL from the app is pretty straightforward, but what about returning the response back to the caller application once the transaction is signed? This can be partially addressed with a message like "Now please close this browser tab and return to the application that requested the transaction signature", although that's so depressing to see such UX in the 2020s. Also, what if the application needs the signed transaction back, like in the case of multi-sig aggregation or the public key request(see #3)? I can think of several workarounds, yet each of them requires jumping through hoops. Without a unified UX on web and native mobile apps, this all looks questionable.

    Summing it all up, as I see it, CosmicLink may be used only as an additional option (not for login, only for transaction signing), and almost exclusively by advanced users with an existing Stellar account. That's like 2-3% of all Stellar users at best, not counting ecosystem developers. I'm pretty certain that until the described UX problems are solved, most ecosystems apps will be reluctant to replace their existing key management strategies (namely, requesting the secret key each time or storing it on the server-side) with your service. I'm obviously biased here, but this looks more like a neat playground for developers than a production-ready app for regular users.

    Again, you most likely know about the limitations of your approach since you are working on this for more than a year. In this context, your attacks on other ecosystem applications look really odd.

      OrbitLens

      Part of your message answers the issue I've raised about StellarTerm and doesn't belong here. Please note that I never said that StellarTerm should use Cosmic.Link. I've shown that it features a broken security model: there are several ways to fix it & I've not advised for one in particular (although I made my point that StellarTerm is not using delegated signing as intended).

      Please move the StellarTerm-specific inputs into the right place, I don't want to answer them here as thread-mixing is confusing. I can answer on the copy/pasting here, though.

      Edited

        MisterTicot

        Please note that I never said that StellarTerm should use Cosmic.Link.

        Here are your exact words from the original message:

        Logically, StellarTerm should use delegated signing so that users can safely validate offers using their wallet - and ultimately get rid of this shameful secret key login. But that's not what's happening. Not only StellarTerm isn't using delegated signing, but it offers to handle transaction requests from other services by signing them with the secret key too...
        I mean come on, that's complete nonsense! The very reason we implemented delegated signing in the first place was to avoid sharing those keys.

        Realistically, you are the only one providing the more or less viable solution for delegated signing with the support of third-party wallets at the moment. It supposed to be stable or at least in production for like a year. Everyone else have only working prototypes at best. So when you started criticizing current StellarTerm key management strategy, and urging them to replace it with delegated signing, which service do you have in mind here? You are happened to be the author of the delegated signer, and the comment is yours, so I assumed that by "we implemented delegated signing" you mean CosmicLink. What else can it be?

        Part of your message answers the issue I've raised about StellarTerm and doesn't belong here.

        They are closely related to this thread, and has nothing to do with StellarTerm in particular, as at the moment of writing almost every single Stellar-based app requests secret keys in order to sign transactions on behalf of the existing user's account. Some of them encrypt the keys and store them locally or on the server, but this is not essential because copy-pasting secret at least once is potentially almost as dangerous as using it all the time. The fact is that copy-pasting is ubiquitous and it can't be easily addressed right now because the existing ecosystem tools are not mature enough.

        I can start a new thread if you like, as discussing theoretical problems of the whole ecosystem in the StellarTerm thread doesn't seem right to me, especially after that heated dispute. Moreover, can we please just turn this page and continue debating on the things that really matter for the future? I'm genuinely interested in your opinion about improving delegated signer flow, and it would be cool to hear your thoughts on the highlighted problems as I'm engaged in this matter myself.

          OrbitLens Yes, using the clipboard for sensitive data is not recommended because it somewhat simplifies the attack, and that's cool that you are raising awareness. But in your comment, you refer to the far-fetched arguments. [...]. The webcam access is sandboxed in the browser and requires explicit access confirmation (just like the Clipboard API), but if the attacker has root access to your computer, nothing will help you. So it all comes to the client environment security in the end.

          However, instead of admitting that you exaggerated the copy-pasting problem (intentionally omitting the attack prerequisites) to support your point, you are throwing pretty aggressive comments.

          I believe my description of the issue is in tune with reality, and I think you should have taken the time to understand it before throwing uninformed accusations at me.

          I never said that this attack had anything to do with the browser or Chrome in particular.

          The clipboard is a system-wide interface, and any data the user copy in it is available to read for any process running on the machine. In some cases, it is also stored for long periods. You don't need root access to read the clipboard: this not an attack but an intended functionality.

          For example, on Android (what 2030% of people use), any app can read the clipboard but none of them can access the compartmented encrypted storage where apps keep secret keys safe.

          It is easy to install a malicious app on Android, or malware on most system, but it is considerably harder to break storage compartment - precisely because you need to be root for the second one.

          All attacks other than peeking at clipboards also request vendor-specific logic once root is acquired. Consequently, those attacks are harder to perform, easier to mitigate (because it involves sequences of code that is easier to flag as malicious) and less likely to hit (which means less likely to happen, because less profitable).

          In other words, storing a private key plain text and copy/pasting it is orders of magnitude less secure than storing it in an encrypted file as well as leveraging OS security features.

          I think this is obvious: else nobody would bother implementing those security measures in the first place.

          This adds up to the fact that the copy/pasting habit itself is what makes most scams profitable.

          And going even further, you directly accused StellarTerm team of deliberately weakening the application security or intentionally misleading the users (not quite clear what you ment here) to gain some mysterious "profits":

          Absolutely, as part of their SCF#3 marketing StellarTerm promoted secret key copy/pasting as a fancy sign-in method. Now, there's a gap between using this method - which is insecure - and actively promoting it as part of a vote gathering effort - which is factually misleading people.

          Misleading applies to situations where someone uses his influence in a way that negatively affects people who trust him. That's definitely what happened here.

          Again citing your words, "Dude, that's off-limits." Clearly, you started all personal trolly debate on the unrelated matter.

          I maintain that misleading people on security part of a profit-seeking effort is off-limits. There's nothing trolly or personal there.

          And btw, bullying someone for exposing & documenting a security issue, and for informing users about crypto good practices, is not much better.

          OrbitLens Realistically, you are the only one providing the more or less viable solution for delegated signing with the support of third-party wallets at the moment. It supposed to be stable or at least in production for like a year. Everyone else have only working prototypes at best. So when you started criticizing current StellarTerm key management strategy, and urging them to replace it with delegated signing, which service do you have in mind here? You are happened to be the author of the delegated signer, and the comment is yours, so I assumed that by "we implemented delegated signing" you mean CosmicLink. What else can it be?

          I think you're mixing things a bit, and I invite you to read my feedback again.

          1. I criticized the way StellarTerm uses SEP-0007. Delegated signing is meant to secure the ecosystem by having apps emit transaction requests, but StellarTerm does it the wrong way by offering people to sign SEP-0007 transactions by inputting their secret, which is self-defeating.

          2. I criticized the fact that StellarTerm actively promoted this insecure practice.

          My motivation for point 1 was that Gleb regularly claimed support for SEP-0007/delegated signing in SCF context while he implemented about 10% of it so far. I think that's unfair and given how wrongly it is done in StellarTerm, I felt like pointing it.

          At no point, I said that StellarTerm had to implement delegated signing, and if I had intended to have them support CosmicLink I'd have used a subtler method. I feel fine with whatever makes user's funds secure.

          As I already said in my article, keystores are also an option, and we know that other ways are possible as well, although I'd advise against gathering thousands of keypairs together on a centralized server.

          I'll go through UX questions. Remember that I never claimed that Cosmic.link is perfect, and in fact, there are many improvements on the way. Yet, I think that it offers a satisfying yet secure experience to its 1.5k regular users, and I invite you to experience it by yourself.

          Some improvements on my roadmap:

          MisterTicot

          • Publish a TxRequest library that doesn't depend on StellarSdk (450kb).
          • Design a solution for applications to acquire user publicKey/wallet.
          • Provide helpers for short-circuiting Cosmic.link (direct application-wallet communication).

          OrbitLens

          1. Each action takes a lot of time and requires multiple confirmations. Case: a user wants to remove two active DEX offers and place a new one. Each time she has to wait for the redirect to CosmicLink website, confirm the transaction, wait for the redirect to, say, a SEP-0007 wallet, confirm the transaction again (this a required step, I guess there is no need to explain why this is important), provide her credentials, press "submit", and wait for the redirect back to StellarTerm. Repeat this 3 times yourself and you will understand why this is frustrating.
          1. It is possible to shortcut Cosmic.link and go directly to the wallet. As mentioned, I'll release helpers to make this easier to implement. Nowadays, Cosmic.link offers an automatic redirection option that shortcuts its interface as well (although technically it goes through Cosmic.link).
          2. Now, the issue of having to sign each transaction also happens with hardware wallets, which is the very UX delegated signing is meant to mimic. An option here is to pack actions together and to offer to sign everything at once.
          1. Single-page applications (like StellarTerm, StellarX, Lobstr, and many others) rely on the client-side state. When a redirect occurs, the application is unloaded and loses the entire current state. So it either needs to encode and transfer the state in the callback URL, or save it temporarily somewhere, for example, in the browser local storage. [...]

          Equilibre.io is a single-page application that uses delegated signing, NiceTrade.co is another one. None of those suffers the drawback you described here as they don't use redirection but iframes or popups. Something you can do, when apps have no critical information anymore, is to store client-side state into LocalStorage which keeps data over sessions (the aforementioned apps do so).

          There is no way to retrieve the user's public key.
          The only way to implement this with your current logic is to ask a user to sign, say, an empty transaction. We won't ask a user to input the public key directly, right? Because asking for a public key and then using a delegated signing to confirm the transactions is the worst UX I can imagine. [...]

          In Equilibre.io, I simply ask for pubkey/federated. This is similar to what many wallets implement as read-only accounts, and transaction signing is required only for writing. One nice trick is that we can standardize the pubkey/address field id attribute, and leverage browser auto-filling to get a cheap yet efficient read-only login solution (sign in with pubkey). The browser will propose your addresses across websites the same way it does with emails.

          NiceTrade.co proposes either login with public key (works as described) or with sep10, in which case delegated signing callback property is leveraged (available in both sep7 and CosmicLink). We discussed the fact that sep10 transactions don't make their purpose very clear (a network: Won't be validated could be clearer). This is mostly a sep10-related problem.

          In any case, those 2 options have room for improvement. Option 1 could be improved by CosmicLink passing pubkeys to the application providing user grant permission, and option 2 could be improved by adding specific UX constraints to sep10 (a specific way to display sep10 tx to users).

          1. Poor onboarding flow for new users.
            Case: a new user decided to explore StellarTerm and see how it works. When she clicks the login button, the browser redirects her to the CosmicLink website, which is literally hostile to newcomers. What transaction should she sign if she doesn't have any Stellar account in the first place? What's the signing method, and which one she supposed to choose, "Stellar Laboratory" or "Copy/Paste XDR"? What does the "Register as web+stellar links handler (SEP-0007)" means? What's an "Automatic redirection"? [...]

          This pertains to the Cosmic.link UI itself rather than delegated signing. I'm in the process of upgrading the client-side framework I used for Equilibre.io and to port Cosmic.link & StellarAuthenticator on top of it. Then, I'll improve the Cosmic.link UI.

          It is also possible to develop an alternative UI on top of cosmic-lib and other Cosmic.plus libraries, which provides most of the Cosmic.link logic at that point.

          How do you suppose to support mobile platforms? Maybe this is covered somewhere, but I didn't find. Opening a CosmicLink URL from the app is pretty straightforward, but what about returning the response back to the caller application once the transaction is signed? [...]

          That's what the callback parameter is for. There is also the option of listening for transaction submission from the parent frame, which is something I'd like to implement but designing it is somewhat of a puzzle given the number of configurations involved. We already found out some cases will have to be left unsupported (mobile signing + callback that don't submit = impossible to catch submission from parent frame).

          OrbitLens [...] but this is not essential because copy-pasting secret at least once is potentially almost as dangerous as using it all the time. The fact is that copy-pasting is ubiquitous and it can't be easily addressed right now because the existing ecosystem tools are not mature enough.

          Many applications have addressed it already in many ways, and I'd advise against using "it's difficult" as an excuse for not implementing solid security. In fact, any excuse that goes toward lesser security should be looked at as suspicious, as in most cases it doesn't hold the test of healthy reasoning.

          I can start a new thread if you like, as discussing theoretical problems of the whole ecosystem in the StellarTerm thread doesn't seem right to me, especially after that heated dispute. Moreover, can we please just turn this page and continue debating on the things that really matter for the future? I'm genuinely interested in your opinion about improving delegated signer flow, and it would be cool to hear your thoughts on the highlighted problems as I'm engaged in this matter myself.

          Then let's do just that!

          Ah, now I finally understand what "automatic redirection" is. Quite an interesting approach. You save at least one website interaction for users. They will still need to provide credentials and confirm the signing request in the target wallet, but this option definitely saves a few seconds on each operation. Still, the problem remains. Users have to wait for at least 3 browser redirects and provide credentials, so each operation takes 10-20 seconds instead of one click as before. That's maybe ok for Equilibre and other apps that imply a few transactions a month, but completely ruins the trading experience (say, a dozen trades a day). Although I really like how you implemented interaction with hardware wallets.

          As for all other questions... Looks like you completely missed some of my points, as your answers do not address most of them at all. And I checked NiceTrade.co. I must say that it's the worst login form I have ever seen. Forcing a user to save a public key separately (where? in text file?) and copy-pasting it (following your logic, that's a big no-no, as it may break user's privacy by associating a person/device with a Stellar account) each time when a user needs to log in, and then requesting the credentials again after following a series of redirects – that's terrible. Even requesting to sign an empty transaction is better than that, at least it's possible to authenticate a user and retrieve a pubkey in one go.

          About my statement that copy-pasting is ubiquitous:

          Many applications have addressed it already in many ways

          Nope. I haven't seen any other option across the entire Stellar ecosystem. If you need to submit transactions on behalf of an existing account, you need to either request a secret key (at least once) or use delegated signing. Given current progress, mature delegated signing tools for Stellar Network will be ready in a year or so (hopefully). So...

          Re: clipboard security

          I never said that this attack had anything to do with the browser or Chrome in particular.
          For example, on Android (what 2030% of people use), any app can read the clipboard but none of them can access the compartmented encrypted storage where apps keep secret keys safe.

          The browser Clipboard API (I didn't mention Chrome specifically as this API is supported in Chrome, Firefox, and other popular browsers) was just an illustrative example for one of a few attack vectors exploiting the potential vulnerability you mentioned without breaking the sandbox. The Android example, of course, demonstrates much stronger case than, say, Windows XP (may it rest in peace) or careless Linux user running all processes under the root privileges (btw, why we are overlooking them?) For the particular case you described, I can agree that "it is orders of magnitude less secure", as you wrote.

          However, my main point here is that a compromised system (with the malware code in userspace) can't be viewed as secure even with all the delegated signing in place. Android Autofill framework and Accessibility API (previously it was used by password managers like LastPass to interact with text input of third-party apps) make it much simpler to steal login/password credentials. And if users are naive enough to install the malware, they will also allow all the requested app permissions without thoroughly reviewing them. So the app storing user's secret key on the server can be as easily hacked as the one requesting it directly from the user.

          It's always worth mentioning specific details about the environment and prerequisites in security-related articles.

          This adds up to the fact that the copy/pasting habit itself is what makes most scams profitable.

          It would be really awesome to check statistics supporting this claim.

          I maintain that misleading people on security part of a profit-seeking effort is off-limits.... And btw, bullying someone for exposing & documenting a security issue, and for informing users about crypto good practices, is not much better.

          Cherry-picking facts and describing an issue from a specific angle only to exaggerate a problem and support a particular theory (or application) doesn't seem so pure and selfless to me. Someone might even say that the intentionally misleading article that purposely omits important facts and attack prerequisites in profit-seeking effort may be viewed as unethical. But we are all adult people here and we never throw such absurd accusations at one another, right?

          Also, I apologize if any of my previous questions/comments upset or distressed you. By no means they were planned as bullying. And I rest assure you that none of your statements offended me.

          Thanks for taking time to answer my questions.

            OrbitLens

            I noticed you're bashing my login form. But it sounds like you haven't actually seen it. If you have, could you please suggest improvements? The default option is a flexible input that accepts federation address, public key, OR private key. Compared to some other apps, it saves the user an extra step to pick the login mode because it has logic to detect the input type.

            And obviously it does not require copy pasting a private key. And I don't think anyone has a problem with copy pasting public keys (that's how I use stellar.expert), but again, that's not required if you're using a Federation Address.

            Imgur

            Also nicetrade caches the public key in local storage (until user explicitly logs out) to avoid user having to re-enter, which again is standard practice for most wallets/exchanges.

              dexter That's exactly what I'm talking about. According to MrTicot, your application security model is flawed by default as clipboard is insecure. I have the opposite view - copy-pasting public or secret key may be a convenient option to login, at least until we have a better way to achieve that. So this option looks quite ok to me. Just read the whole thread, starting from the beginning.

              I was referring to the awful authorization flow using CosmicLink:

              Requesting user's public key just to force a user to go through another authorization flow immediately after that looks strange. Why do you need to request the public key in the first place? A user can select it in the signer app. There is a possibility that she may select another account in the signer and the login will fail. Also, the interface on the right requests checking the transaction on login, which is misleading and may be confusing.

              Regarding the improvements. Caching user's public key in the local storage is ok in most cases, but I'd advise you to add the ability to switch accounts, as many users have more than one.

                OrbitLens
                Regarding the specific login flow involving Cosmic Link, I agree with you it would be ideal for the user not have to input the account address in nicetrade. However for authentication, we have to bind the user's local nicetrade session with the transaction sent by Cosmic, and currently there is no mechanism for Cosmic to pass that information locally to nicetrade. This type of integration for implementing SEP-10 has never been done before (to my knowledge), so there are definitely room to improvements on both sides. For now, this is an extra step the user has to deal with, but it's usually not a problem because nicetrade supports support federation address, and for repeat users the address is cached from last use.

                Regarding your last point on switching account, that's actually one of nicetrade's strong points. Once you authenticate you have the option of associating multiple additional accounts with a primary account and switch through them without having to logout/log back in.

                Maybe I misunderstood your point, but specifically I was referring to this quote:

                And I checked NiceTrade.co. I must say that it's the worst login form I have ever seen.

                This kind of came out of the blue and caught me by surprised. If that comment was made in irony I definitely missed it.

                I really do not want to be caught in your beef with MisterTicot. But since I'm here I'll try to weigh in since there seems to be some confusion (at least for me)... I interpreted MisterTicot's original argument as "requiring copy paste of private key to use your app is bad", not "clipboard is bad in all cases". I agree with your point that the clipboard is a convenience/security trade off that some people may be willing to accept. But I do also think that most non-technical users are not fully aware of that usage of the clipboard increases the surface area of attack.

                OrbitLens

                Your repeated gaslighting attempts hardly hide your inability to make sense at the technical level. You should take care: people notice.

                I didn't mean to stir it up again, but it bothers me to leave so many misstatements & petty attacks unanswered in my own thread, so here we go:


                Message 1:

                [About Equilibre.io] They will still need to provide credentials and confirm the signing request in the target wallet, [...].

                False Equilibre.io signing interface doesn't ask for user public keys.

                Users have to wait for at least 3 browser redirects and provide credentials, so each operation takes 10-20 seconds instead of one click as before. That's maybe ok for Equilibre [...]

                False There's no configuration under which Equilibre.io requires 3 browser redirections + providing credential for tx signing.

                As for all other questions... Looks like you completely missed some of my points, as your answers do not address most of them at all.

                Unbacked accusation That sentence is dropped as it. We'll never know which point wasn't answered, and I believe there wasn't any.

                And I checked NiceTrade.co. I must say that it's the worst login form I have ever seen.

                Insulting Dexter is the first dev to use sep10 in production and deserves kudos for that. The first step is rarely perfect.

                Forcing a user to save a public key separately (where? in text file?) and copy-pasting it (following your logic, that's a big no-no, as it may break user's privacy by associating a person/device with a Stellar account)

                False There's no such thing as forcing users to save public key - federated addresses are supported in the software I mentioned. There's no such thing as copying a pubkeys from text files - most wallets provide a copy-on-click feature.

                Reinterpretation I never said that public key should not be copied.

                Poor technical understanding There's a difference between public and private keys. Public keys are meant to be shared and can safely be copy/pasted. The idea that an attacker would listen to the clipboard for public keys to break one's privacy is kind of ridiculous at that point.

                [about NiceTrade.co] each time when a user needs to log in,

                Disinformation it sounds like it happens a lot, while NiceTrade sessions are remembered. You need to log in once per machine, just like Keybase.

                Even requesting to sign an empty transaction is better than that, at least it's possible to authenticate a user and retrieve a pubkey in one go.

                Poor technical understanding Doing it that way, it wouldn't be possible to authenticate the origin of the login request... In other words, it wouldn't work.

                About my statement that copy-pasting is ubiquitous:

                [MisterTicot] Many applications have addressed it already in many ways

                Nope. I haven't seen any other option across the entire Stellar ecosystem

                Denial Here are solutions that have been used to prevent secret sharing, some of them since years:

                • Custodial wallet (PapayaBot)
                • Pubkey scanning (Stargazer)
                • Payment request (StellarKey, Stargazer)
                • Keystore (StellarPort)
                • Key Encryption + local storage (Stellar Authenticator)
                • Key encryption + distant storage (StellarX)
                • XDR copy/pasting (StellarLaboratory, Stellar Authenticator)
                • Sep7 (Keybase)
                • Sep10 (NiceTrade)
                • SatoshiPay (Lumenthropy)
                • Cosmic.link (PublicNode)
                • Payment plugins (StellarPay, SWPlug)

                If you need to submit transactions on behalf of an existing account, you need to either request a secret key (at least once) or use delegated signing.

                False Submitting transactions on the behalf of the user is not the same as signing transactions on the behalf of the user. The first happens part of multi-signature coordination and doesn't require secret key nor delegated signing. (e.g: StellarGuard)

                Given current progress, mature delegated signing tools for Stellar Network will be ready in a year or so (hopefully)

                Denial Mature delegated signing tools are ready right now, and Cosmic.link is production-ready since a year and a half. I'll add that no other cryptocurrency project has such a generic tool available yet.

                The browser Clipboard API [...] was just an illustrative example for one of a few attack vectors exploiting the potential vulnerability you mentioned without breaking the sandbox

                Technically false The browser clipboard API is precisely not an attack vector because it is sandboxed. There are workarounds but at that point, this renders the attack unprofitable.

                The Android example, of course, demonstrates much stronger case than, say, Windows XP

                Denial Using "of course" about something you couldn't figure out by yourself.

                careless Linux user running all processes under the root privileges (btw, why we are overlooking them?)

                Because nobody does that.

                For the particular case you described, I can agree that "it is orders of magnitude less secure", as you wrote.

                Denial Storing secrets in plain text and copy/pasting them around is orders of magnitude less secure in all possible cases.

                However, my main point here is that a compromised system (with the malware code in userspace) can't be viewed as secure even with all the delegated signing in place.

                Denial In your previous comment, you defined a "compromised system" as one where root access was gained. Now, you redefine it to avoid admitting your point was wrong.

                Technical false A malware is typically under the same security restrictions as other software and cannot perform actions that require permissions without asking the user first. Under Android/iOs, only copy/pasting is weak against malware without permission, and most of the alternative ways I mentioned are resistant against malware with permissions.

                (Namely: custodial wallet, pubkey scanning, payment request, key encryption + local storage, XDR copy/pasting, sep10, SatoshiPay, Cosmic.link, Payment plugins are resistant. Keystore, key encryption + distant storage and sep7 can be broken under certain specific conditions)

                Android Autofill framework and Accessibility API (previously it was used by password managers like LastPass to interact with text input of third-party apps) make it much simpler to steal login/password credentials

                False Accessibility API requires permission and both can be broken only when devs leave a hole. Peeking at clipboard is easier, works against all app and is less likely to get spotted as malicious.

                And if users are naive enough to install the malware [...]

                Denial This statement is meme-epic. Users don't know they are installing malware, that's the very concept. Under Windows, they remove them by dozen using tools such as CCleaner. On phones, most apps intentionally embed malware that shows ads, track users and harvest data for money.

                Apps that got spotted mining XMR could as well had peeked at clipboard for private keys. If your "view" of security only includes people who never installed malware, then you'll only have to care about a handful of *BSD users... who can already deal with themselves.

                So the app storing user's secret key on the server can be as easily hacked as the one requesting it directly from the user.

                Reinterpretation What I previously said was that applications storing encrypted keys locally, such as Stellar Authenticator, are resistant against the attack. Apps that store secrets online & allow to sign in from any client are out of the public key cryptography security model & are indeed weak to credentials stealing attacks.

                It's always worth mentioning specific details about the environment and prerequisites in security-related articles.

                Denial No it's not: it would inform script kiddies, it would be too complicated for casual readers, and wouldn't be of much use for decent developers as they can figure out by themselves the consequences of a statement such as "the clipboard is readable system-wide".

                [MisterTicot] This adds up to the fact that the copy/pasting habit itself is what makes most scams profitable.

                It would be really awesome to check statistics supporting this claim.

                Denial If scammers were the only ones to ask for secrets, few people would get caught. It doesn't take statistics to understand that.

                Someone might even say that the intentionally misleading article that purposely omits important facts and attack prerequisites in profit-seeking effort may be viewed as unethical

                Denial Security advisories are always written in a concise way (example). They describe a security flaw & devs are expected to be able to infer attacks for that description. For obvious reason, I never intended to describe the attack or provide the code snippets Gleb asked for (sic!).

                Gaslighting

                1. Your friend market secret sharing in his SCF communication.
                2. I inform users that this is an insecure practice.
                3. You say that my work could be seen as unethical.

                Also, I apologize if any of my previous questions/comments upset or distressed you.

                Gaslighting is a form of intentional aggression that is meant to trigger those very emotions. This is offensive regardless of whether or not it succeeds.


                Comment 2:

                That's exactly what I'm talking about. According to MrTicot, your application security model is flawed by default as clipboard is insecure. I have the opposite view - copy-pasting public or secret key may be a convenient option to login, at least until we have a better way to achieve that.

                Re-interpretation I never said copy/pasting public keys was a problem.

                Denial You make it sound like we're discussing opinions, but cryptography is rarely a matter of views but a matter of logic. By "security model", I refer to a set of conditions under which a given security feature is guaranteed. For instance, when it comes to asymmetric cryptography:

                The identity of the signer is guaranteed as long as he did not share his private key.

                Security feature: The identity of the signer is guaranteed.
                Set of condition (1): The private key hasn't been shared.

                That's how keypairs are meant to be used, this has been settled by scientists & experts more than 25 years ago and I don't think there's any debate going on on that matter.

                IF the set of condition is not respected, THEN the security model is broken.

                I agree that there are cases where it doesn't matter so much, but wallets in production are not one of these.

                If one is looking for a well-implemented usage of cryptographic keypairs, GPG is the way to go. It protects identities, not money, but still: devs were serious and did things "the right way".

                I reiterate my belief that cryptocurrency applications which doesn't respect this security model will hit a disastrous fail on their way toward mass adoption.

                Serve Your Own CosmicLink Front-End

                What makes CosmicLink different from most Stellar-related services is that it is an open solution. In other words, instead of jailing users for growth & profit, it gives the keys to everyone. Let’s dig together into one of the greatest feature of such an open system: forks.

                Read more

                Trying to wriggle out of the situation by diverting attention and posting lengthy unrelated answers is often used by politicians. However, this is a technical community, and people here are smart enough to draw their own conclusions despite all the manipulations. That's really entertaining to watch how you undermine your own previous statements, again and again, coming up with even more ridiculous narratives each time.

                Just to mention a few exciting excerpts from the last comment.

                Equilibre.io signing interface doesn't ask for user public keys.

                Don't know where you find the term "signing interface" in my previous comment as public keys were mentioned only in the context of the app login process. And hey, you know what? The public key request form is the first login step at Equilibre!

                So looks like a user still needs to save public key somewhere (or setup a federation record on some third-party service) and the signer app itself is not sufficient for the login. You should know about this tiny nuisance as you are the author of that application, right? So what's the point of denying the obvious facts and trying to spoof the context? It looks like an attempt to ignore anything that doesn't fall in line with your agenda.

                There's no configuration under which Equilibre.io requires 3 browser redirections + providing credential for tx signing.

                Reality denial? Let's try to count together. A series of screenshots below shows the transaction signing process using Lobstr wallet (the steps will be similar for any other wallet or SEP-7 link handler).

                So... we've seen three browser redirects (or subsequent page loads if you like – loading something in iframe is essentially the same as loading a new browser page), the last screen shows the credentials request form. Do forget about one more redirect back to the original site once the transaction was submitted. Of course, Equilibre does not request any credentials itself (and it shouldn't as delegated signing is all about using other apps for login), but the flow implies that the target wallet always asks for user credentials to authenticate the transaction signing request. And that's exactly what I pointed earlier.

                Mature delegated signing tools are ready right now, and Cosmic.link is production-ready since a year and a half.

                Despite the "year and a half" of development, it looks like a prototype coded by students on a hackathon. From my point of view, it is not ready for production usage because of several architectural flaws outlined above. It's a critical part of the ecosystem and adopting it as-is can do more harm than good.

                Here are solutions that have been used to prevent secret sharing, some of them since years:

                • Custodial wallet (PapayaBot)
                • Pubkey scanning (Stargazer)
                • Payment request (StellarKey, Stargazer)
                • Keystore (StellarPort)
                • Key Encryption + local storage (Stellar Authenticator)
                • Key encryption + distant storage (StellarX)
                • XDR copy/pasting (StellarLaboratory, Stellar Authenticator)
                • Sep7 (Keybase)
                • Sep10 (NiceTrade)
                • SatoshiPay (Lumenthropy)
                • Cosmic.link (PublicNode)
                • Payment plugins (StellarPay, SWPlug)

                Each of these applications directly or indirectly requests the user's secret key at least once. Citing my original comment: "almost every single Stellar-based app requests secret keys in order to sign transactions on behalf of the existing user's account". I don't know how to make it even more clear, maybe a real-world example would help. I own a few Stellar accounts myself. To use any of them with, say, Stellar Authenticator or Keybase, I need to import my secret key to this application first. And the only way to do it is to copy-paste the secret key. Only those secret keys created inside the app/wallet itself may never touch the clipboard (unless I need to import them somewhere else). Therefore, almost any of the projects you mentioned can become the target of your righteous wrath since they allow me to import my secret key, right? Or maybe you'll focus only on those participating in the current round of SCF?

                "Poor technical understanding" remarks look especially funny from someone who doesn't understand the basic security principles, and can't comprehend that sometimes associating a blockchain account with a real person (the case when malware intercepts public key on user's device) may be even more severe than stealing funds (malware intercepts secret key). All this public/secret key differentiation is based on the assumption that a person's public key is public knowledge and does not relate to the sensitive data. In the real world, news about journalist tortures and assassinations emerges with frightening regularity. A public key leakage may cost someone's life as it allows to associate blockchain account with a real person and track the transactions up to some fiat gateway. I can't understand how you can concentrate entirely on one side of the problem completely ignoring the other.

                Let's be honest – if an attacker installs malware on a user's device, the client-side security model is corrupted. Delegated signing can't address this issue with 100% certainty. The process of crypto signing in an untrusted environment is insecure. Period. Therefore, the problem of copying secret keys itself has been intentionally exaggerated. I have a lot more to say, but this will be tiresome for all participants of the discussion. Anyone who gets to this point should be able to grasp the essence of it.

                Building far-fetched postulates (quote: "...the copy/pasting habit itself is what makes most scams profitable") not backed by real-world statistics (quote: "It doesn't take statistics to understand that") is unprofessional. Using such postulates as a foothold to promote own projects by attacking other developers is unethical. Accusing others of profit-seeking at the expense of their users based on made-up arguments is immoral.

                As a closing note, just wanted to say that I hate the type of people who arrogantly start attacking others, throwing unmotivated accusations, passive-aggressive all-personal comments, and then playing bullying victims when pointed the inconsistency.

                1. My point was about the signing process, but you posted a screenshot of the login form. I already said in my entry that login was worked on.

                2. My point was about the number of redirections: there are at most two (->Cosmic.link->wallet). You answered on the number of interactions, which is not related to my software. Lobstr takes two. Trezor takes more. Keybase takes less.

                3. Cosmic.link development has been limited by SDF funding, which ceased its programs for almost a year and preferred to promote sep7. I never said it was under development for one year and a half: I said it's been ready all that time.

                4. In two years, I received $7,500 for it and worked for about 6 months, including studying Stellar functioning, debatting the concept & its design, doing researches about different ways to make it work, then writing the specs, the SDK, the front-end, the Ledger and Trezor libraries, the developer tools, articles, documentation, and helping people integrating it. Not bad for a "student on a hackathon".

                5. Fun fact: that wallet you never released, and that is inspired by my work, received more funds than that. (StellarExpertID got money from the SBC#7 and the SDP)

                6. My point was about solutions that don't require copy/pasting secrets, and you answered that all wallets need private keys to sign transactions. This is true but unrelated.

                7. My "wrath" was specifically about one well-known dev who went out of his way by promoting private keys copy/pasting as part of his SCF strategy. So yes, it happened during SCF.

                8. You're defending private keys disclosure and public keys protection in the same post. I guess you just invented the one-man-pincer-movement.

                9. I said that copy/pasting secrets is insecure and it is. I said that secrets are not meant to be shared and they aren't. Ultimately, there are only two ways devs can figure that out: by thinking or by failing.

                10. Here's your demonstration: even by doing things the right way some systems won't protect the secrets very well (namely Windows) THEREFORE MisterTicot intentionally exaggerated the issue of copy/pasting secrets. This is not actually logic, and you're not doing good at reading my intentions.

                11. Security measures are rarely 100% effective. Audits, peer reviews, firewalls, sandboxing, permissions, antivirus, antimalware, antispam, passwords... We only hope several layers of those will be enough to prevent or mitigate the consequences of breaches. Let's see why proper keypair handling is worth implementing:

                  • As I already explained, this is efficient in defending secrets in several scenarios - including on infected systems - which is in itself a sufficient reason.
                  • Even on insecure systems, people copy/pasting secrets will get harvested before people encrypting keys. Security is not about being 100% but about doing better than that neighbor who leaves the doors wide open.
                  • The threat I mentioned will make the news in a spectacular way sooner or later. Why? Because there will always be careless developers who don't understand an issue until it blows in their face. And that day, those people who red my article and understood it won't be part of the casualty. This is what "informing users" achieves.
                12. Only hate is hateful.