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.
Why you need secure sharing
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.
To share a secret, both the sender and receiver need to have scs installed and follow these steps:
- 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/184.108.40.206/tcp/4001/p2p/12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4kx6nXTN/p2p-circuit/p2p/12D3KooWA768LzHMatxkjD1f9DrYW375GZJr6MHPCNEdDtHeTNRt"
- 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
scs send -n dante -c config.yml
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.
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: - 220.127.116.11 whitelists: - 18.104.22.168
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.
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.
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.
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.
Sharing alternatives and pros & cons
Other password sharing tools
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.
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.
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.
- Allow to always listen to specific addresses for an accessible data flow.
- QUIC support
- AutoNat -
scsassumes both peers are behind NATs, firewalls, or proxies but it’s not always the case. Implementing
AutoNatwill 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!
Subscribe to our newsletter
The latest news, articles, features and resources of Onboardbase, sent to your inbox weekly