The Security & Encryption of Password Pusher

This page outlines the security, encryption methods, and overall philosophy behind Password Pusher’s approach to protecting sensitive information.

The goal of this page is to provide transparency so you can assess if Password Pusher aligns with your organization’s security policies and needs.

Database Encryption

The sensitive data in pushes and requests is stored encrypted in the database using the AES-GCM algorithm with 256-bit keys until push or request expiration where this encrypted data is deleted entirely.

This encryption standard is recognized for its performance and security, providing both encryption and authentication to ensure data integrity.

Further, from a master encryption key, Password Pusher derives a unique encryption key for each field that is encrypted in a push or request.

Tip: If you’re self-hosting, you have the option to configure a custom encryption key for additional control over your data’s security.

For reference, here is some information about the AES-GCM algorithm:

It’s an IETF standard
It is a NIST Recommended Algorithm: 1, 2
See the Galois/Counter Mode page on Wikipedia.

Risk Limitation Strategies

To reduce potential security risks, Password Pusher uses several key strategies:

Unique URLs: Each push or request is accessed through a unique, time and view limited, hard-to-guess URL.
Passphrase Lockdown: Pushes and requests can be further protected by using a pre-shared passphrase. End users cannot view the secret URL until they enter the correct passphrase.
Audit Logs: Access logs are maintained to provide insight into who has viewed each password, giving you visibility and control.
Preemptive Deletion: You and optionally your push recipients can preemptively delete sensitive information manually before its set expiration.
Time-Limited Existence: All shared data automatically expires after a configurable period, minimizing the window of exposure. Risk mitigation is better achieved when pushes and requests have short expiration settings such as 1 view and 1 day duration.
Compartmentalization: As an added measure, I strongly recommend to avoid sending usernames, passwords and login locations together. Instead use separate pushes with different passphrases and additionally utilize good security within your organization such as two-factor authentication and periodic password resets. It’s with all of these steps, security best enforced and followed.
On-Demand, Expiring File Download Links: Access to uploaded files is restricted to on-demand, time-sensitive download links. When a secret URL is viewed, temporary download links are generated on-demand for the attached files. These temporary download links expire within five minutes of generation, after which users must refresh the secret URL page to create new download links. Outside of this process, uploaded files are completely inaccessible.

See the Best Practices document for more tips on how to further mitigate risk.

Secure Transmission (SSL)

All data transmitted between the browser and server is secured using SSL encryption. This is the same technology used by banks and online payment processors to ensure that information is not intercepted in transit.

Limitations in Client-Side Encryption

Password Pusher does not provide custom client-side encryption for sensitive data. This is when the browser uses Javascript to encrypt the data with an encryption key unknown to Password Pusher before sending.

This is often referred to as “perfect secrecy” or “zero-knowledge encryption”.

Note: Transmission of data is always sent over a 128-bit SSL encrypted connection.

If your requirements demand high-grade end-to-end encryption (where only the sender and receiver can decrypt the data), Password Pusher might not meet your organization’s needs.

Alternatively, you can always self-host the OSS version internally at your organization to better meet any security policy requirements.

Note: I’ve investigated client side encryption in the past and may add this in the future but I want to be clear about the current state as some organizations require such high-grade strategies.

File Uploads

Uploaded files that are attached to pushes (or requests) follow a unique security process:

No Database Encryption for Files: Unlike other sensitive data, file uploads are not stored in encrypted form in the database.
Temporary Download Links: Access to uploaded files is restricted to on-demand, time-sensitive download links. When a secret URL is viewed, temporary download links are generated on-demand for the attached files. These temporary download links expire within five minutes of generation, after which users must refresh the secret URL page to create new download links. Outside of this process, uploaded files are completely inaccessible.
Full Deletion Upon Expiration: Once a push or request expires, both the sensitive database entries and all attached files are permanently deleted, ensuring data cannot be accessed or retrieved afterward.

Note: In the past, I have had users request data retrieval after a push has expired. Unfortunately this is not possible for two reasons: 1) upon expiration all sensitive data is unequivocally deleted and cannot be retrieved and 2) it is the policy of the Password Pusher team to never access user pushes or requests.

Transparency and Best Practices

Password Pusher has gotten to where it is today by being transparent, open and responsive to the community which has always provided great feedback and input.

As always, the source code is public, allowing you to review and validate the implementation directly.

To quote from the FAQ:

If you still have concerns regarding trust, safety and security, feel free to review the code, post any questions that you may have and consider running it internally at your organization instead.

As for trust in me, all I can offer is my long history building this project and my public reputation on Github, LinkedIn, Twitter and my blog.