Introducing Secure Share (2023): A CLI to Share Dev Secrets with Teammates

We’re excited to introduce one of our first open-source contributions: secure share (scs).

Whether you’re a startup or a bigger company, you always need a proper way to share secrets with teammates for effective collaboration while protecting sensitive data―if you have to run around after everyone to get access to a file, you’re losing precious time! But improperly sharing secrets also greatly increases the risk of unauthorized access.

To address all these challenges, you need secure communication channels to transmit secrets to authorized teammates. That’s where scs comes in.

Secure share is an open-source CLI program to send and receive sensitive information:

Share anything with teammates via CLI - Secure share allows users to exchange a wide range of information with their colleagues using the command-line interface, streamlining collaboration.
Secure peer-to-peer connections - The program ensures that all connections are encrypted and peer-to-peer, enhancing the security of shared data.
Exchange of secrets, files, and messages between machines - Users can exchange sensitive information, files, and messages between different machines seamlessly.
Accessibility with or without internet access - Secure share enables sharing even in scenarios where direct internet access may not be available, like in a demilitarized zone.
Zero-trust architecture - The program employs a zero-trust approach, meaning it prioritizes security and assumes potential threats from the start, reducing vulnerabilities.
High-performance with Rust - Secure share is built with the Rust programming language, ensuring high-performance and reliability.

Secure share protects how we collaborate and share information with ephemeral, encrypted P2P messages, right from the CLI by promoting smoother workflows and fostering more secure communication among team members. The ease of use through the CLI and the robust security measures encourage everyone to exchange information freely and without worries.

Secure sharing protects your business.

Data breaches caused by stolen credentials are alarmingly common. According to IBM, these breaches take an average of 327 days to be identified, resulting in millions of dollars in losses.

Phishing attacks account for 37% of all cyberattacks. A study by Statista emphasizes that education is crucial in combating this type of attack, as it involves tricking individuals into revealing sensitive information through fraudulent emails, messages, phone calls, and other social engineering methods.

The risk of insider threats arises from employees or contractors leaking sensitive data intentionally or unintentionally. Cyber attackers may exploit human vulnerabilities to gain access to critical information. Humans are the weakest link in the cybersecurity chain. Many cyber attacks succeed due to simple human errors that could have been prevented with proper preparation and awareness.

Send secrets

To share a secret, both the sender and receiver need to have scs installed and follow these steps:

Receiver:

Open a terminal or navigate to where scs is installed.
Run scs in listen mode. It will assign you a PeerId and start on a random port (you can choose a specific port with the -p flag). You’ll see a response like this:

scs receive

INFO  Your PeerId is: 12D3KooWA768LzHMatxkjD1f9DrYW375GZJr6MHPCNEdDtHeTNRt
INFO  Listening on "/ip4/172.19.192.1/tcp/54654"
INFO  Listening on "/ip4/192.168.0.197/tcp/54654"
INFO  Listening on "/ip4/127.0.0.1/tcp/54654"
INFO  Listening on "/ip4/157.245.40.97/tcp/4001/p2p/12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4kx6nXTN/p2p-circuit/p2p/12D3KooWA768LzHMatxkjD1f9DrYW375GZJr6MHPCNEdDtHeTNRt"

Sender:

Get the PeerId of the teammate you want to send a secret to.
Run scs to see your IP address and PeerId. This verifies that your machine can communicate with your teammates.
Attempt to send the secret. If successful, scs will relay messages to both parties, keeping them informed of the sharing session’s status and progress.

scs send -r 12D3KooWA768LzHMatxkjD1f9DrYW375GZJr6MHPCNEdDtHeTNRt -s "hello, world"

After a session with a new peer, scs will prompt you to save the information of the connected peer under an easy-to-remember name if you wish to do so. This will allow you to send messages to that peer without having to specify a long PeerId using the -n flag:

scs send -n dante -c config.yml

Zero knowledge

Secure share doesn’t store any data at rest or in transit. It uses local variables whose values are erased as soon as the exchange ends or the program stops.

Files too

scs also supports sending entire files by adding the -f flag and a file path to the command:

scs send -r 12D3KooWLaLnHjKhQmB46jweVXCDKVy4AL58a4S4ZgHZGuJkzBf9 -f ../path/to/file1 -f path/to/file2

Note that you can also send plain text files in a similar way:

scs send -r 12D3KooWLaLnHjKhQmB46jweVXCDKVy4AL58a4S4ZgHZGuJkzBf9 -m "hi there" -m "foo"

Whitelists/Blacklists IP addresses

By default, anyone with your PeerId can send you a message, and you can send a message to anyone whose peerid you know. To prevent that, you can specify IP addresses to whitelist of blacklist using a config file. A whitelist is a list of addresses to allow, while a blacklist is a list of addresses to block.

To enable this feature, just add the IP list to the config file:

blacklists:
  - 34.138.139.178
whitelists:
  - 34.193.14.12

Then pass your configuration file in the command:

scs receive -c ./config.yml
# or
scs send -r 12D3KooWLaLnHjKhQmB46jweVXCDKVy4AL58a4S4ZgHZGuJkzBf9 -c ./config.yml

If whitelisted IP addresses are specified, only traffic originating from those addresses is permitted.

Note that generic IP addresses like 127.0.0.1 (localhost) or 192.0.0.0 (firewall access points) aren’t allowed for security reasons.

Signed Certificate

Additionally, receivers can add a connection parameter to the configuration file to only allow connections from users using a signed certificate from a certificate authority, including self-signed certificates:

connection: trusted # or self

Typical use cases

Sharing sensitive employee data during onboarding and securely transferring access credentials during offboarding processes.
Sharing confidential partnership details with external vendors and collaborators.
Sharing financial projections, business plans, and due diligence documents with potential investors.
Collaborating with remote teams and freelancers while safeguarding proprietary project details.
Sharing sensitive legal documents with legal counsel and regulatory bodies while maintaining confidentiality.
Facilitating secure communication among remote team members and ensuring secure access to company secrets.
Sharing financial reports, forecasts, and sensitive banking information with financial advisors and auditors.

Disposable

If you prefer a graphical user interface, we also built Disposable: a real-time, end-to-end encrypted, and ephemeral online chat. Based on secure share’s open core, the messages disappear as they are read, no data is stored or retained, and all data is encrypted in transit using perfect forward secrecy. You just have to send a temporary invite link via email or text and your teammate will be able to view the required credentials right away:

This is perfect for one-time transactions when you don’t want to setup an Onboardbase account for a temporary stakeholder.

Codebase tour

Secure share is a Rust program:

The messages disappear as they are read and no data is stored or retained. No traces!
The messages are end-to-end encrypted using TLS and the tokio library
Perfect forward secrecy using ed25519 to add an additional security layer on top of TLS
Memory-leak-free and high-performance by default thanks to Rust

The program is relatively small, so feel free to have a look at the Github repository, star it, and contribute.

The password sharing tools you see on the market usually involve sending a temporary link to the person you want to share the info with, but the receiver’s email can be hacked, or the link can be leaked. This is insecure by design.

Your regular messaging platform

Sharing sensitive secrets on messaging apps is bad practice due to several inherent security risks:

Messaging apps are primarily designed for quick and casual communication, often lacking robust encryption and security measures required for safeguarding sensitive information.
They may not provide end-to-end encryption, leaving data vulnerable to interception during transmission.
Messaging apps typically store data on servers, making them susceptible to data breaches or unauthorized access. Users often overlook the risks of using such platforms for sensitive information, increasing the likelihood of accidental exposure or social engineering attacks.
Providers might not comply with industry-specific regulations concerning data privacy and protection.

To ensure the confidentiality and integrity of sensitive secrets, it is crucial to adopt specialized and secure sharing solutions that prioritize encryption, access controls, and compliance with data protection standards.

Email

Like messaging platforms, email communication is not inherently secure, and messages can be intercepted or accessed by unauthorized parties during transmission. Emails are often stored on servers, making them susceptible to data breaches or hacking attempts. Recipients’ devices may not have adequate security measures, potentially exposing the secrets to unauthorized access. Phishing attacks can trick users into revealing sensitive information, putting both the sender and receiver at risk. Emails lack features like end-to-end encryption, leaving the content vulnerable to exploitation.

Paper

In a world where remote work is prevalent, sharing secrets via paper isn’t a realistic solution:

If the paper containing sensitive secrets is stolen or lost, the information can easily fall into the wrong hands.
Without encryption, the content is readable to anyone with access to the physical document.
Sharing secrets using pen and paper is limited to physical exchange.

You might find it silly but you probably still have employees or collegues writing down passwords on post-its.

Conclusion

Download the program from our github repository and make sure to join our Discord community. We’ve got some good stuff on the roadmap:

Allow to always listen to specific addresses for an accessible data flow.
QUIC support
AutoNat - scs assumes both peers are behind NATs, firewalls, or proxies but it’s not always the case. Implementing AutoNat will first check if the two peers can communicate directly and thus increase transmission speed.

Onboardbase is building an open and collaborative secret infrastructure, and we think open source will play a key part in our growth. Tag along!