Password Pusher exists as a better alternative to emailing passwords.

Emailing passwords is inherently insecure. The greatest risks include:

• Emailed passwords are usually sent with context to what they go to or can potentially be derived from email username, domain etc…
• Email is inherently insecure and can be intercepted at multiple points by malicious entities.
• Emailed passwords live in perpetuity (read: forever) in email archives.
• Passwords in email can be retrieved and used later on if an email account is stolen, cracked etc..

The same risks persist when sending passwords via SMS, WhatsApp, Telegram, Chat etc… The data can and is often perpetual and out of your control.

By using Password Pusher, you bypass all of this.

For each password posted to Password Pusher, a unique URL is generated that only you will know. Additionally, passwords expire after a predefined set of views are hit or time passed. Once expired, passwords are unequivocally deleted.

If that sounds interesting to you, try it out or see the other frequently asked questions below.

And rightfully so. All good security begins with healthy skepticism of all involved components.

Password Pusher exists as a better alternative to emailing passwords. It avoids having passwords exist in email archives in perpetuity. It does not exist as a end-all security solution.

Password Pusher is opensource so the source can be publicly reviewed and can alternatively be run internally in your organization.

Passwords are unequivocally deleted from the database once they expire. Additionally, random URL tokens are generated on the fly and passwords are posted without context for their use.

A note for those with an interest in extreme security: there is no way I can reliably prove that the opensource code is the same that runs on pwpush.com (this is true for all sites in reality). The only thing I can provide in this respect is my public reputation on Github, LinkedIn, Twitter and my blog. If this is a concern for you, feel free to review the code, post any questions that you may have and consider running it internally at your organization instead.

Absolutely. Password Pusher has a number of applications and command line utilities (CLI) that interface with pwpush.com or privately run instances. Push passwords from the CLI, Slack, Alfred App and more.

See our Tools and Applications page for more details.

Yes. Using the previously mentioned tools, many users and organizations integrate Password Pusher into their security policies and processes.

The Tools page outlines the resources available to automate the secure distribution of passwords.

There are no limits currently and I have no intention of adding any. To minimally assure site stability, Password Pusher is configured with a rate limiter by default.

Yes. We provide Docker containers and installation instructions for a wide variety of platforms and services.

hint: docker run -p 5100:5100 pglombardo/pwpush-ephemeral:latest

The source code is released under the GNU General Public License v3.0 and that pretty much defines any and all limitations. There are quite a few rebranded and redesigned clone sites of Password Pusher and I welcome them all.

Some organizations are bound by security policies that prohibit the use of public services for sensitive information such as passwords. There are even organizations that require all tools to be on private intranets without access to the outside world.

It's for these reasons that we provide the ability (and encourage) users and organizations to run private instances when needed.

Running an private instance of Password Pusher for your company or organization gives you the peace of mind that you know exactly what code is running. You can configure and run it as you like.

On the other hand, if your instance gets hacked, malicious entities now have a targeted dictionary of passwords to brute force accounts in your organization. Note that this would be limited to pushes which haven't yet hit their expiration limits.

In this respect, the public instance at pwpush.com is may be superior that it contains only passwords without identifying information mixed among users from around the globe.

The user should carefully weigh the pros and cons and decide which route is best for them. We happily support both strategies.

Absolutely. If you need any resources such as statistics, graphics or anything else, don't hesitate to contact me: pglombardo at pwpush.com.

Very likely. I love to hear all ideas and feedback. If you have any, please submit them to the Github repository and I will respond as soon as possible.

I don’t. This is just a project that I work on in my spare time built for the community. Monthly costs are $34/month for Heroku hosting and any time/effort that I’ve put in or will put in developing the tool is voluntary/donated.

I’ve thought about moving the site to a Digital Ocean droplet but Heroku just makes it so easy. No configuring Apache/nginx, deploy scripts, monitoring services etc…

2021 Update: The traffic has grown to an amount where 1 Heroku dyno no longer is sufficient. 2x professional dynos and the postgres add-on now has the project up to $59/month. Longer term I need to find a way to lower costs - maybe an eventual migrate to Digital Ocean which has much better performance…