StellarExpertID provides a safe and reliable way to use your Stellar accounts without trusting anyone with your secret key. All sensitive data is encrypted with your password and securely stored in the browser. Key features Secure key management – your secret key is never exposed to third-party services. Secure transaction signing – transactions are signed without exposing a secret key. SEP-0007 compatible – can be used to handle "web+stellar" links. Web apps Single Sign-On – login to third-party websites, just like with Google or Facebook OAuth. Two-factor authorization support – provides another level of protection for your accounts. Digital identity – associate a nickname, email, or avatar with your account address (or leave it blank if you prefer to stay incognito). Multi-account support – use multiple accounts and switch them when you need it. Message signing tools – sign and verify arbitrary data with your private keys. Inflation voting – vote for inflation pools with a single button click without worries for your funds' safety. Federation support – make use of a human-friendly address for your account. Works everywhere – the same account operates seamlessly via desktops, smartphones, and tablets. Intents There are 4 main groups of intents: Request transaction signing. The signer app prepares and signs a transaction which then can be returned to the initiator website or submitted directly to the network. Request specific action. Either "transfer funds", "vote for inflation pool", or "establish a trustline". Each action is effectively a simplified wrapper for the transaction signing request. No custom logic or even JS SDK is required on the initiator side. Request information. The website may request a user's personal info (email, avatar) or Stellar account public key. Request cryptographic signature of the arbitrary data. The website may request a crypto signature to verify a keypair ownership (authentication, secure messages exchange etc). Authorization flows The signer supports two authorizaton flows: an implicit flow and callback flow. Implicit flow A popup window with request details is shown each time an initiator website requests the action. A user invokes some action on the third-party website (a wallet, DEX interface, inflation pool etc). Let's say, he wants to create an offer. The website prepares the requested transaction and it's XDR representation in base64 format. The website initiates the intent (see intent list in the project description) using js module that provides an interface for all supported intents. The interface module opens a new pop-up window pointing to id.stellar.expert . All intent parameters are serialized and transmitted in a form of GET parameters. So the full URL will look like https://id.stellar.expert/confirm?intent=tx&network=testnet&xdr=AAAAALPZeTF82... . Signer application reads parameters from the URL and asks the user for a confirmation. The user chooses a keypair from the list of stored accounts (or adds a new one) and confirms the action. The signer app signs the transaction the same way any other wallet do it. The signed transaction is serialized into XDR as TransactionEnvelope and transmitted back to the opener site in base64 encoding via the built-in browser postMessage mechanism. The third-party website receives a signed transaction envelope and may choose either to submit it to the network or store somewhere in case if the tx needs more signatures or if it has time bounds set. Intent confirmation dialog always contains extended request information, including intent description (like "Sign transaction"), initiator website ("origin: example.com"), risk level ("high", "medium", or "low"), information about personal data disclosure (only for personal_info intent), and safety status ("safe" or "potentially unsafe"). Intent-specific details allow a user to review the request before confirmation. For instance, a dialog with sing_tx intent displays full transaction information including all meaningful properties and the list of operations in a human-friendly format adapted for the ordinary users. Callback flow The callback flow supports Stellar SEP-0007 link format. Instead of showing a popup authorization dialog, it redirects the browser to the signer page. A signed transaction can be either submitted to the network or returned to the specified callback URL via POST request. Technical details The project consists of three modules: The signer website itself – provides a user-friendly interface for key management and operation intents. Client intent module – JS library that simplifies StellarExpertId integration and usage. Server-side vault – a simple server that provides API for encrypted credentials storage and 2FA verification. (Server-side vault storage option is temporarily disabled). The intent library supports the following actions ("intents"): signTransaction(xdr, options) – requests transaction signing (returns signed transaction envelope, can be used for multi-sig). pay(destination, amount, asset_code, asset_issuer, memo, memo_type, options) – requests a payment. trust(asset_code, asset_issuer, limit, options) – requests inflation pool voting. inflationVote(inflationDestination, options) – requests inflation pool voting. signMessage(msg) – requests arbitrary data signing. verifyMessage(msg, signature) – requests arbitrary data signature verification. requestAddress() – requests account public key (for basic web authentication). authenticate() – requests user identity verification (for SSO login). requestPersonalInfo() – requests personal info access (avatar, nickname etc). Available transaction intent options: network – stellar account network identifier ("public", "testnet") or private network passphrase. horizon – the url of a Stellar Horizon server (for transactions only). prepare – if set, the signer will return a signed tx envelope instead of submitting it to the Horizon server. Formal intent data contracts can be found here . "web+stellar" links In order to set up this application as a signer for "web+stellar" links as described in SEP-0007 , you may either use navigator.registerProtocolHandler() (works in Chrome and Firefox) or configure the protocol binding manually . navigator.registerProtocolHandler('web+stellar', 'https://id.stellar.expert/confirm?encoded=%s', 'StellarExpertId signer') Please note: it's a developer preview software version, do not store your real Stellar account secret keys here. Secret key storage options Choose security options that suit you. Multi-login with Two-factor authorization Allowing this feature increases security and simplify your account usage across all your devices and browsers. Your secret key is encrypted with your password in the browser and securely stored on our servers. We do not have access to your account. Account log-in and all subsequent actions are protected with 2FA TOTP authorization. This feature works with 2FA applications like Google Authenticator , Free OTP , or Authy . Browser-only storage with password protection Credentials are encrypted with your password and stored in the browser. Nobody except you can obtain access to your account. Account log-in and all subsequent actions require your password. Paranoid mode StellarExpert ID never stores your credentials or any other info on our servers, nor in the browser. Nevertheless, you still can sign transactions and use other features providing your secret key to confirm all actions. Account log-in and all subsequent actions require your secret key. Next steps Once the interfaces and modules are stable and documented, I'm going to add support of other security-related applications, like Ledger Nano support, StellarGuard by Paul, CosmicLink by MisterTicot etc. Liabilities and trust Originally this application was designed as a part of StellarExpert, but the more I think about it, the more I convince myself that it should be maintained and operated by the reliable public entity. Why would you trust some random anonymous guy from the internet? Hence I decided to ask SDF to maintain and host the application. I'm ready to transfer the repositories, all explicit and implicit copyrights, claiming only as much as a reference in the readme/license repository file. The reasons behind this decision: Safe development. All pull requests will be reviewed by SDF maintainers, and we all know that Bartek is a top-notch security specialist. Trusted infrastructure. The application will be deployed and administrated by guys who support Core nodes and publicly available Horizon. Trusted entity. I think we all can agree that SDF is the most trusted entity across Stellar Network as it runs the crucial part of the network and holds the largest part of all available Lumens. If SDF itself runs the application under its own brand (say, "StellarID"), it will give green light to all developers and users. We all can be sure that guys from SDF won't modify sources to steal users' private keys and everyone will be able to participate in the process. As for me, I'll keep contributing to the project with pull-requests. So here I'm asking for the opinion of Stellar community. If you think that such an application will be useful, I will contact SDF with this matter. The project demo is available here . Source code on GitHub. Issue tracker . Will be glad to hear any questions and feedback.

Cool to see you using message signing/verification.

OrbitLens Is this done as a browser extension, injecting an API into web pages, à la MetaMask?

dzham No, it works like Google/Twitter/Facebook OAuth. Once you have initiated an action, a new browser window is open and the user can approve or reject the action.

I spent almost 6 months on the development, including 3 major refactors and multiple fixes after peer security audits. And to my mind, the result was definitely worth it, because this application may gradually simplify the life of developers (one simple interface that covers all major use cases and encapsulates other providers, like Ledger Nano, StellarGuard etc), as well as end-users (safe key management and turn-key experience across all applications). Please check the updated project description and the demo .

How are you doing message signatures to stop people from maliciously sending regular txs, and having people sign them?

dzham I'm going to parse the message. If it is a valid tx xdr, the signer will return an error. Something like try { new Transaction(xdr) // a valid transaction wouldn't throw an error return Promise.reject(new Error('Potentially malicious message.')) } catch(e) { return Promise.resolve(xdr) }

OrbitLens I've been doing hash(hash(msg)) to get away from it

OrbitLens Absolutely interesting!

From Reddit : @doomslise: Cool! I was planning on developing something like this for StellarGuard -- mind if I use this for inspiration? Additionally, would you be open to talking about integrating StellarGuard into this, as I believe it might be complementary? Yeah, for sure. It will be open-source. Hopefully it will be maintained by SDF, as it's the most trusted public entity on the Network. I specifically mentioned StellarGuard integration in the article. It would be great if we could integrate all existing key management and security-related solutions like StellarGuard, CosmicLink, Ledger Nano support into one single full-featured application. It will be better tested and easier to support. And Stellar application developers will need to integrate only one micro-module with standard interface to make it accessible for all Stellar users. I hope that we all can agree on the new key management standard (e.g. SEP-0011). It doesn't mean that I will be in charge of the development. I will contribute to the project working with pool requests, the same way as any other developer.

OrbitLens I really like what you're doing. I'm trying to do this integration job with cosmic links. I recently added transparent support for StellarGuard. Right now I'm working on integrating transparent signatures sharing. Recently, I made the cosmic.link website compatible with Ledger Wallets, Stellar Laboratory and future Sep-0007 wallets: https://cosmic.link/?setOptions&inflationDest=GCCD6AJOYZCUAQLX32ZJF2MKFFAUJ53PVCFQI3RHWKL3V47QYE2BNAUT I'll be happy to add support for Stellar Expert Id. I wrote an article that have few proposals about how to work together under a common language: Understanding Cosmic Links I think that in the near future every wallet will have to offer such features. Would be great to agree upon simple GET/POST scheme that everybody could implement, rather than multiplying custom solutions. The reason I favor GET request despite their lack of privacy is that it works with serverless wallets.

StellarExpert ID – Single-Sign-On App and Tx Signer for Stellar Network

OrbitLens

MisterTicot It's my implementation, I designed it 7 months ago, when CosmicLink was not announced yet, and SEP-0007 was not defined. As I mentioned earlier, the application will support CosmicLink format. I spent last month fixing StellarExpert, so I had no time to properly clean up the code and implement the latest specs. If you are going to create your own implementation based on my open-source project and it will be better in terms of usability, I will gradually switch to your project, ditching my codebase.

I'm going to update GET params mapping to match your notation (for example, xdr instead of txXdr). I do like the format you proposed, the only thing which seems completely wrong to me is a callback logic. If the browser follows redirects, the initiator application will lose its current state. For example, you prepared a transaction on, say, super-cool-trading-bot.io, then you are redirecting the user to cosmic.link?xdr=...&url=super-cool-trading-bot.io. In this case, a developer of super-cool-trading-bot.io has to save current application state either in URL or in localStorage in order to restore it once the transaction is signed.

My implementation works transparently. You just invoke the intent which returns a standard promise. Once the promise is resolved, the application receives the result, and it does not lose the current state.

MisterTicot

OrbitLens Hi,

I totally missed this answer.

I think you're right about callback: I need to re-work that part. I really focused on the wallet-side functionality, like multisig support and such. Now I need to focus on non-wallet side stuff, like methods to build and edit transaction and callbacks.

I'll have to take a look at how you did that, for sure.

OrbitLens

MisterTicot You are absolutely right,

sign(...keypairs) {
    let txHash = this.hash();
    let newSigs = each(keypairs, kp => {
      let sig = kp.signDecorated(txHash);
      this.signatures.push(sig);
    });
  }

In this situation keypair.sign(keypair.publicKey() + input_message) looks like a better alternative to double-hashing to me.

Once again, when it is about login/authentication (automatic signing) I would prevent any kind of text input as it may have legal value in the future.

Legal implications definitely should be considered. The signing itself is very simple and robust way to confirm the identity or secret key ownership, so I don't want to give up on it so easily.

MisterTicot

OrbitLens

Legal implications definitely should be considered. The signing itself is very simple and robust way to confirm the identity or secret key ownership, so I don't want to give up on it so easily.

You are absolutely right. This is precisely the reason why they start to be considered a legal proof of identity/ownership by administrations.

Using it as a login/authentication means is great: it is clearly something we want to do. It is done right only if it doesn't collide with legal use cases that we'll need to support as well at some point (contract signing).

For login a number big enough to prevent collision appended to the site domain is enough: you don't need to accept any abritrary data and you can specify the number to be a certain length that is not 256. This also have the benefit that external service would more likely use the feature in a proper way.

keypair.sign(keypair.publicKey() + message)

This works as long as you enforce message to be non-empty (or the DKIF weakening attack is possible again).

Maybe

keypair.sign(domain + message)

Would do better. It also greatly reduce chances of collision, because no cross-domain collision could happen anymore. This imply that requester website let the document.referer field set. I'm not sure if it can be handled properly by installed software/applications, though.

dzham

MisterTicot keypair.sign(keypair.publicKey() + message)

This works as long as you enforce message to be non-empty (or the DKIF weakening attack is possible again).

Maybe

keypair.sign(domain + message)

Would do better. It also greatly reduce chances of collision, because no cross-domain collision could happen anymore. This imply that requester website let the document.referer field set. I'm not sure if it can be handled properly by installed software/applications, though.

Message signing isn't only done for specific domains.

dzham

MisterTicot Once again, when it is about login/authentication (automatic signing) I would prevent any kind of text input as it may have legal value in the future.

What do you mean by this?

MisterTicot

dzham

There's a use case of blockchain that is signing legal contracts and storing signatures on on-chains. Voting can also be implemented as signing a specific piece of data. If your application automatically sign arbitrary messages I can abuse it. This is why I think automatical signing should be restricted to meaningless numbers.

Message signing isn't only done for specific domains.

Can you please elaborate on that?

dzham

MisterTicot Can you please elaborate on that?

Message signing can be use for absolutely anything. I don't see why you'd want to restrict that.
I'm using is for applications that don't come from a specific domain, e.g.

MisterTicot This is why I think automatical signing should be restricted to meaningless numbers.

How do you differentiate meaningless numbers from meaningful numbers?
If I give you a number I want you to sign, it definitely has meaning to me

MisterTicot

dzham

How do you differentiate meaningless numbers from meaningful numbers?
If I give you a number I want you to sign, it definitely has meaning to me

Not necessarily. Basically I can differentiate 2 use cases:

Signing for the purpose of login/authentification. What you're actually signing doesn't matter in itself. What matters is to prevent collision to ensure that old signatures can't be re-used by illegitimate party. Here, you wouldn't display the data you're signing because it is likely cryptic and meaningless. What you would ask to user is his agreement to authenticate himself to a given service. Here, you could make use automatic signing (such as "automatically log me in").
Signing for the purpose of accepting a contract, claiming authorship, voting and so on. What you sign is what matters. Collision doesn't, in the meaning that you could very sign several time the same statement (typically "I can legally buy securities in my country."). Here, you must display what is about to be signed to the user. What you ask for is his agreement about the data being signed regardless of which service did issue it. This kind of data should never be signed automatically or without user consent.

As you can see both use case are symmetrically opposed so I think it would be better handled by two separate interfaces. One should ensure there's no collision between them to prevent abuse.

It is still not clear to me which use cases you're trying to cover right now. Could you please give me example of cases were you would sign messages unrelated to a specific domain?

OrbitLens

Update 2018-08-31

Publicly released stable development version. Check the repository here.
Improved security: secret (request secret key) intent removed.
New pay intent added.
SEP-0007 support added.
Fixed potential vulnerability with transaction hash signing via sign_msg intent.

I faced some problems implementing SEP-0007 standard. Maybe someone knows other SEP-0007 signer open-source implementations?

OrbitLens

MisterTicot Sure, feel free to fork. The more developers adopt the same signing schema, the better. It will be a giant step toward more secure key management.

MisterTicot

OrbitLens

I think you should check Android Chrome support: request windows stay empty.

OrbitLens

MisterTicot Yes, I see a few new bugs on Android. Thanks for the bug report!

« Previous Page