How to Securely Send Passwords or Other Confidential Information
Do you have to send something confidential to a colleague, friend or associate? Don’t let that information persist indefinitely.
Be careful how and what you transmit as that information can sit around forever and be exploited by others long after you’ve forgotten what you’ve sent.
Historical Methods
When having to send credentials, most think of email immediately and if not that, then one of the many chat systems as a mode of transmission. These systems have inherent security drawbacks that I’ll detail here as some are not immediately evident.
There are so many downsides to email that I’ll just list them in short order:
- Email is inherently insecure and can be intercepted at multiple points of delivery by malicious entitities.
- Emailed passwords are usually sent with context to what they go to which is equivalent to a free tip to any malicious entities.
- The email addresses and headers can give a clue to what the password may go to (such as company or corporation).
- Emailed passwords live in perpetuity (read: forever) in email archives.
- Passwords in email can be retrieved and used months or years later if an email account is eventually compromised.
- After an email is sent, you have zero control on the where, when and how long that email will exist for.
WhatsApp, Facebook Messenger, AIM, ICQ, Signal, Telegram, Slack, Microsoft Teams
Some chat systems are more secure than others but in the end they are all owned by companies and corporations who are bound by law and all types of policies. The trustworthiness in these chat systems go only as far as you can trust those companies.
Some of the drawbacks of transmitting over chat systems:
- A compromised account can access sensitive information posted months or years ago
- Companies and organizations are often required by law to maintain chat logs for some period of time.
- Chat systems leave a local cache on devices that can often be accesses outside of the chat software.
Or the less evident issue is the catch-22: It’s often that the user you want to send information to doesn’t have access to chat until you send him the password.
What Would Be The Best Case Scenario?
So given all of the complexities and drawbacks above, what would be the ideal solution?
The best case scenario for transmitting a secure password would have the following features:
- The location of the password would be secret and known only to you and whom you communicate it to.
- The password would be stored encrypted and if transmitted, over an encrypted line (HTTPS).
- If left untouched, the password would automatically expire and delete itself after a number of views or days has passed.
- The end user can delete the password as acknowledgement once they successfully retrieve it.
- You can see and track who viewed (or attempted to view) the password.
- You could manually delete the password entirely yourself at anytime.
- You could maintain a detailed audit log of events for that password even though the password itself has been deleted.
Password Pusher
To satisfy this best case scenario, I’ve created Password Pusher as an opensource project available on Github.
I run this software at pwpush.com but since it’s opensource and you can easily run your own private internal instance in which I’ll explain how below.
After 10 years of running, maintaining and improving this project, it is the best solution out there by far to communicate passwords securely.
With Password Pusher, the password is stored at a secret URL which then expires after a certain number of views or days (whichever occurs first).
Here are some of the highlights.
Passwords Expire After a Number of Views or Days
If left untouched, the password would automatically expire and delete itself after a number of views or days has passed.
Pushed passwords are stored encrypted in the database and have an expiration of days and views. When either of these triggers first, the password is entirely deleted from the database.
Unbranded Secret URL and Simple Delivery Page
The location of the password would be secret and known only to you and who you communicate it to.
The password would be stored encrypted and if transmitted, over an encrypted line (HTTPS).
Post a password and get a simple unbranded password delivery page at a secret HTTPS URL.
No branding and no outgoing links to confuse end users. Simple instructions indicating best practices for the end user.
User Deletion of Passwords
The end user can delete the password as acknowledgement once they successfully retrieve it.
End users can optionally delete the password themselves once retrieved. Once this is done, the password no longer exists and can never be retrieved again.
Full Audit Log Tracking
You can see and track who viewed (or attempted to view) the password.
You could maintain a detailed audit log of events for that password even though the password itself has been deleted.
For each password posted, you get a full audit log from creation, expiration, deletion and beyond. We even show you failed view attempts and where they came from.
Dashboard to Track Pushed Passwords
Track what you push out with a dashboard that allows you to see what’s active and what has already expired.
Internationalization: All the Languages
Do you need to send something to an international user? Set the target language for your push ahead of time.
Optional 1-click Preliminary Retrieval Step
Want to avoid URL scanners? An optional 1-click preliminary step is available to avoid bots.
Dark Theme
A dark theme is also included too that follows your operating system settings.
Run Your Own Private Instance
Many companies and organizations have security policies which preclude them from using public services such as pwpush.com. As such, Password Pusher is available to run internally at your organization with little to no effort.
docker run -d -p "5100:5100" pglombardo/pwpush-ephemeral:1.10.0
Password Pusher continually provides updated containers available on Docker Hub. There is also documentation on how to run it on a variety of other platforms.
Docker, Kubernetes, Digital Ocean, ECS we support it all and even have user integrations into Slack, ZenDesk, Microsoft Teams, Microsoft Active Directory and more.
There are dozens of private Password Pusher instances running in the wild and I welcome them all.
Summary
Sending passwords is a critical operation that is often overlooked and should be taken seriously. With all of the other things going on in your life, job and workplace, let Password Pusher worry about the details for you. Use tools that were built from the ground up with security in mind.
If you have any issues using Password Pusher or running it internally, please feel free to contact me on Github or through pwpush.com.
