Self Destruct Messaging Implementations

Passwordstate includes a Self Destruct Messaging portal as part of the core software.  Self Destruct Messaging typically allows you to send emails or messages within an application, containing content considered to be highly confidential, to be viewed for a specified period of time.

In the case of Passwordstate’s Self Destruct Messages, the content that you share is stored only within the Self Destruct Messaging portal.  Access to be able to send Self Destruct Messages relating to a Password Record is permissions based and you can control both the ‘Time to Live’ and number of times the data or Password Record can be viewed.

How are Self Destruct Messages Sent

In this example we’ll use a scenario where we want to temporarily share a password record with a contractor that doesn’t normally have access to Passwordstate.  The Self Destruct Messaging portal we are using is the embedded implementation, meaning it is automatically included as part of your Passwordstate website and can be access by appending /selfdestruct to your Passwordstate URL.  The version of Passwordstate used in this example is V9 Build 9300.

To share the Password Record with the contractor we simply, click on the Action Menu next to the record and select Send Self Destruct Message;

This brings up the Self Destruct Message Screen where we can compose our message.  We specify the period of time the message is alive for and the number of times it can be viewed.  Both these fields are drop down lists where you can select from predefined options.  Once complete click Next;

Next, we enter the contractor’s email address, change the subject line as appropriate and click Next,

In this case we’re using Passphrase Protection, so we’ll need to set the Passphrase and advise the contractor what that is (in a separate email) and then click Send Message,

The contractor now receives the following email,

To access the details of the Password Record, the contractor will need to click on the URL, noting the ‘Time to Live’ for the Self Destruct Message is 30 min from the email being sent.  This will bring up the Self Destruct Message portal screen requiring authentication using the Passphrase separately emailed to them and then clicking Next,

The Self Destruct Message is then displayed (I’ve redacted the details in the image below),

The person that sent the Self Destruct Message will receive an email confirming when the message has been viewed by the recipient.

Self Destruct Messaging Implementations

The example used above is based on the embedded implementation, which is part of your existing Passwordstate instance.  The Self Destruct Messages under this model can only be used where you can also access your Passwordstate website.  This means that if your Passwordstate instance isn’t internet facing then you’ll also not be able to share Self Destruct Messages over the internet.

You can however implement the Self Destruct Message portal a couple of other ways.

  • The first, using a Push\Pull implementation.  This works by sending messages from your core Passwordstate website to a Microsoft SQLite database.  When the customer accesses the Self Destruct website, it reads the Self Destruct Message directly from that SQLite database and the message is deleted when they are finished with it.  This implementation doesn’t require any open ports to your Passwordstate website, or your Passwordstate database and requires no management of the SQLite database.  It enables the hosting of your Self Destruct Messaging website in a DMZ.  To configure this option, you’ll need to specify the URL for the site and generate an Encryption Key.  Instructions are located under the Administration Tab->System Settings->self destruct messages->Push\Pull Deployment Self Destruct Install Guide button.
  • The Second, is via your AppServer hosted within your DMZ.  This implementation requires you to connect to the AppServer to read the Self Destruct Messages.  This method doesn’t use the SQLite DB. Instead, it uses connectivity back to the Passwordstate database, hosted on your internal network. A port, typically the SQL port 1433 needs to be open.  If you are already using the AppServer as internet facing, in order to sync with your Mobile Apps on Smartphones, it makes sense to use this.  However, you should perform an internal risk assessment to ensure the solution meets your requirements.

There are multiple implementations available for the Self Destruct Messaging Portal and you are encouraged to select the model that best suits your organizational requirements. 

As always, if you’ve got any feedback you’d like to share please send it to