Most web service providers require or recommend the user select a password that is a mix of upper and lower case characters, decimal digits, and special characters, but do not disclose what special characters are allowed until after the user selects a password, confirms the password, and goes through a "password strength" check.

As a result, the user may select the strong, but memorable, password "sPo0kyh@l|0w3En" only to discover that the "@" or "|" (vertical pipe) symbols, both of which are used, are not allowed. The password is therefore not a conforming password.

After the web service provider reports this to the user, the user is forced to select another password and hope the special characters used are allowed. If the web service provider discloses the allowed special character set, it is more likely to do so after the user has selected a password containing special characters that are not allowed.

This is a worst practice, but it is very common. For example, at the time of account creation:

Google:

• does not disclose the special characters that are allowed. Google recommends: "Use at least 8 characters. Don’t use a password from another site, or something too obvious like your pet’s name." (see Create a new Google Account (Google)).
• does not disclose the special characters that are allowed, even on a page titled "Choosing a smart password", which recommends: "Use a password with a mix of letters, numbers, and symbols" (see Choosing a smart password (Google)).

Monster:

• does not disclose the special characters that are allowed. Monster requires: "8 - 20 characters (use at least 1 letter, and 1 number or symbol)" (see Become a Member (Monster)).

Facebook:

• does not disclose the special characters that are allowed, even in response to the questions: "What is the minimum password strength? How can I make my password strong?" Facebook recommends: "When creating a new password, be sure that it is at least 6 characters in length and that you use a complex string of numbers, letters, and punctuation marks." (see Creating an Account (Facebook)).

Because most web service providers do not disclose what special characters are allowed before the user selects a password, users of Encryptor may have to experiment to determine the allowed special character set when using Encryptor to generate a password.

Users of Encryptor may not be able to determine the allowed special character set unless they first generate a password containing a special character that is not allowed. Also, users of Encryptor may generate a password which does not contain a special character that is not allowed using a special character set which includes characters that are not allowed.

In the latter case, users of Encryptor should be aware that changing the special character set saved with the encryptor may change the ciphertext. If the ciphertext is being used as a password, users of Encryptor should be particularly careful when changing the special character set while using Encryptor to change the existing password. Encryptor fully supports "undo" operations, but undo history is not saved when the user quits. As a result, users of Encryptor should create a new encryptor using the revised special character set to avoid deleting ciphertext generated using the existing special character set, and which will be needed to change the existing password.

The features of Encryptor which are tested before any release is considered to be validated are:

1. The results reported by Encryptor to the user shall be correct.

   Encryptor's primary feature is performing operations on parsable string tokens to transform a plaintext string into a ciphertext string conforming to known requirements in accordance with a known encryption algorithm.

   All encryption algorithms used by Encryptor are pencil-and-paper methods which may be validated by hand. In general, they are suitable for encrypting small amounts of plaintext, such as a password, but should not be confused with modern cryptographic methods.

   Several encryption algorithms used by Encryptor were once considered indecipherable, and Encryptor will encrypt plaintext using a one-time pad as the key. However, the security of a one-time pad requires it never be used again, which defeats the purpose of storing it and would require that a password, for example, be changed every time it is used.

   Before every release, Allen evaluates Encryptor's ability to transform plaintext into ciphertext using standard test cases (see Encryptor - Validation - Standard test cases). The standard test cases have been manually validated, that is, validated by hand using pencil and paper.

   The reproducible bug bounty is: Manually encrypted ciphertext shall equal the ciphertext in field "Ciphertext" for every standard test case before the results reported by Encryptor to the user will be considered to be correct and the release considered validated.

   The standard test cases described are available as an XML document for download (see Encryptor - Downloads - Standard test cases). Import (⌘I) that document into Encryptor to validate Encryptor. The manually encrypted ciphertext is given in field "Comment".

2. Private data shall be cleared on "Save", "Save as...", or "Quit" when requested by the user.

   Before every release, Allen confirms that private data is cleared on "Save", "Save as...", or "Quit" when requested by the user. Encryptor's file save and quit behavior is described in the following document: Encryptor - Support - File save and quit behavior.

   The reproducible bug bounty is: Private data shall be cleared on "Save", "Save as...", or "Quit" when requested by the user in accordance with the behavior described in the document above.

3. Encryptor's user interface shall be resized appropriately when the user resizes the window.

   Before every release, Allen confirms that Encryptor's user interface is resized appropriately when the user resizes the window.

   The reproducible bug bounty is: Encryptor's user interface shall be resized appropriately when the user resizes the window.

4. Later versions of Encryptor shall import encryptors exported by previous versions of Encryptor.

   Before every release, Allen confirms that Encryptor imports encryptors exported by previous versions of Encryptor.

   The reproducible bug bounty is: Later versions of Encryptor shall import encryptors exported by previous versions of Encryptor.

   Note that Encryptor will both Export (⌘E) encryptors as an XML file ("exported XML file") and Save (⌘S) a document as an XML file ("saved XML file")1. Later versions of Encryptor will open a saved XML file, but saved XML files are incompatible with exported XML files, and cannot be imported. Likewise, exported XML files are incompatible with saved XML files, and cannot be opened.

5. Encryptor shall export valid XML.

   Before every release, Allen confirms that Encryptor exports valid XML using the World Wide Web Consortium (W3C) Markup Validation Service[1]. This is consistent with Allen's commitment to data portability (see Allen Analytical - About - Allen Analytical's commitment to data portability).

   The reproducible bug bounty is: Encryptor shall export valid XML.

The following features are not eligible for Allen's Reproducible Bug Bounty:

• Printing errors.

  Printing errors are not eligible for Allen's Reproducible Bug Bounty.

  Validation of Encryptor's print behavior is described in the following document: Encryptor - Validation - Printing.

  Briefly, the problem is:

  ...validation of Encryptor's print behavior is based on 38 columns per page by 48 rows calculated using the default line height of 1.5 and default font point size of 10 points, and the printable area of letter size paper when printing to a Samsung ML-1450. Changing the paper size or printing to a different printer affects the size of the printable area of the page, and the maximum number of columns or rows which may be printed.

  Although Allen is unable to test all possible print configurations, please report printing errors.

References:

Endnotes.

It is important to maintain a distinction between the document and the file throughout the discussion that follows because the contents of the document and the contents of the file may not be the same:

• The phrase "the document" refers to the "scratch pad" in memory. The document may or may not have been loaded from, or saved to, persistent storage such as a hard drive or flash drive, and the contents of the document may have changed since the document was last saved.
• The phrase "the file" refers to the file saved to persistent storage. The file is a record of the contents of the document when the document was last saved.

Encryptor's file save and quit behavior is based on the contents of the document, not the contents of the file. In every case where the file is not modified, the file contains private data if the document contained private data when it was last saved, i.e., private data WAS NOT cleared before saving.

If the user selects:

• Quit (⌘Q)
  • If the document has not been saved:
    • If the document has been edited:

      Present the "Don't save", "Cancel", or "Save" dialogue to the user. If the user selects:

      • Don't save

        Quit normally.

      • Cancel

        Cancel the Quit.

      • Save

        Save as described in "Save (⌘S)", below.

    • Otherwise, the document has not been edited.

      Quit normally.

  • Otherwise, the document has previously been saved.
    • If the document has been edited since it was last saved:

      Present the "Don't save", "Cancel", or "Save" dialogue to the user. If the user selects:

      • Don't save

        Quit normally. The file is not modified, and may contain private data.

      • Cancel

        Cancel the Quit.

      • Save

        Save as described in "Save (⌘S)", below.

    • Otherwise, the document has not been edited since it was last saved.
      • If the document contains private data:

        Present the "Clear private data...?" dialogue to the user. If the user selects:

        • Quit

          Quit without clearing private data. The file is not modified, and contains private data.

        • Cancel

          Cancel the Quit. The file is not modified, and contains private data.

      • Otherwise, the document contains no private data.

        Quit normally. The file is not modified, and does not contain private data.

• Save (⌘S)1
  • If the document has not been saved:
    • If the document contains private data:

      Present the "Clear private data...?" dialogue to the user. If the user selects:

      • Save

        Save the document without clearing private data. A file is created, and the file contains private data.

      • Cancel

        Cancel the Save, allowing the user to clear private data and then Save. A file is not created.

    • Otherwise, the document contains no private data.

      Save normally. A file is created, and the file does not contain private data.

  • Otherwise, the document has previously been saved.
    • If the document contains private data:

      Present the "Clear private data...?" dialogue. If the user selects:

      • Save

        Save without clearing private data. The file is modified, and contains private data.

      • Cancel

        Cancel the Save, allowing the user to clear private data and then Save. The file is not modified.

    • Otherwise, the document contains no private data.

      Save normally. The file is modified, and does not contain private data.

Endnotes.

The design goals of Encryptor include: "The user will retain control of their data." and "Encryptor will encourage multi-layered security, or 'defense in depth'."

Conforming passwords or other authentication tokens generated using Encryptor are indistinguishable from random text. As a result, the same memorable parsable tokens may be used to generate different conforming passwords for multiple web service providers without exposing the parsable tokens to discovery.

Although most web service providers store your password or other authentication tokens as a hash, or salted hash, which makes recovery difficult, some do not. In addition, transmitting your password or other authentication tokens over a non-secure connection exposes them to every web server between your computer and the web service provider.

Encryptor cannot solve these problems. Indeed, no action on your part can guarantee disclosure of the password or other authentication tokens you generate using Encryptor is prevented.

However, if inadvertent disclosure is a concern, for example because others have access to an unprotected file recording authentication details, several strategies may be helpful:

1. Filesystem or whole disk encryption.

   Allen recommends users of Encryptor use the features of the filesystem or operating system to secure saved documents using filesystem or whole disk encryption, for example: FileVault or a third-party utility such as TrueCrypt to encrypt a hard drive, or Disk Utility to create an encrypted partition. By default, saved documents created using Encryptor have a "eosx" extension, but users may elect to save XML or SQL documents created using Encryptor as "xml" or "sql" files.

2. Use a personal encryption algorithm which allows you to use memorable parsable tokens to generate conforming passwords or other authentication tokens and mark those parsable tokens as private data.

   Encryptor provides a way to mark parsable tokens as private data. Private data is handled specially by Encryptor (see Encryptor - Features - Private data).

   See Encryptor - Tutorial (T02) - Generating a conforming password for an example.

3. Modify the ciphertext generated by Encryptor as part of your personal encryption algorithm.

   For example:

   • Append or prepend a token known only to you to the ciphertext generated by Encryptor.

     For example, append or prepend "_d0G" or "2S!n" to the ciphertext generated by Encryptor. Adjust the token as necessary to satisfy the plaintext alphabet characteristics established by the web service provider. If the plaintext alphabet contains upper and lower case characters and decimal digits but no special characters, use "d0G" or "2Sn". If the plaintext alphabet contains upper and lower case characters and special characters, but no decimal digits, use "_dG" or "S!n".

   • Alter the ciphertext generated by Encryptor.

     For example, Encryptor generated the conforming password (see Encryptor - Tutorial (T07) - Encrypting plaintext):

     1TWaevTW

     However, both:

     11TTWWaaeevvTTWW
     111TTTWWWaaaeeevvvTTTWWW

     are also conforming passwords.

Throughout this document, the words "selected encryptor(s)" are used to describe controls which affect multiple encryptors. The words "selected encryptor" are used to describe controls which affect the first selected encryptor, even when more than one encryptor is selected.

Encryptor's user interface includes a number of elements and controls:

1. Search field.

   Enter a search term. Encryptor filters the list of encryptors as you type so that only encryptors with an account name, domain, or comment containing the search term are displayed.

2. List of encryptors.

   The list of encryptors created by the user.

   • Enter an account name in field "Name".

     The default account name is "username".

   • Enter a domain in field "Domain".

     If no encryptor is selected, the default domain is "domain".

     If an encryptor is selected, the new encryptor will have the same domain as the domain of the selected encryptor. This is useful when creating several accounts at a time, for example, if you are an administrator creating passwords for users of your site.

   • Enter a comment in field "Comment".

     Comments are not required, but useful to store the names of businesses, for example, which cannot be readily determined by examining the domain.

   Fields "Added" and "Modified" display the date the encryptor was created and the date the encryptor was last modified, respectively. These fields are not editable.

3. New Encryptor button.

   Click the New Encryptor button to create a new encryptor, or select "File > New Encryptor" (⇧⌘N).

4. Delete Encryptor button.

   Click the Delete Encryptor button to delete the selected encryptor(s), or select "File > Delete Encryptor" (⌘D).

5. Clear Private Data button.

   Click the Clear Private Data button to clear private data (see Encryptor - Features - Private data).

6. Encryptor Preferences button.

   Click the Encryptor Preferences button to change the preferences for the selected encryptor.

7. Confirm Ciphertext button.

   Click the Confirm Ciphertext button to open the confirmation dialogue window.

8. Cipher type button.

   Click the Cipher type button to change the cipher type for the selected encryptor(s). Select one of the following cipher types:

   1. None.
   2. Keyword substitution.
   3. Vigenère.
   4. Autokey.
   5. Running key.

   The default cipher type is "Vigenère".

   Changing the cipher type updates the user interface:

   • Cipher type "None".

     Fields "Keyword", "Key", and "Ciphertext" are disabled.

   • Cipher type "Keyword substitution".

     Field "Key" is disabled.

   This does not prevent the user from storing data in these fields. First, select a cipher type that uses a keyword and key, and generates ciphertext: "Vigenère", "Autokey", or "Running key". Enter the keyword and key, then change the cipher type to "None" or "Keyword substitution". Encryptor will retain the keyword and key entered.

9. Field "Keyword".

   Enter the keyword for the selected encryptor(s). The keyword is a parsable token (see Encryptor - About - Parsable tokens).

   Field "Keyword" is disabled for cipher type "None".

10. Remember Keyword button.

    Click the Remember Keyword button to mark the keyword as private data (see Encryptor - Features - Private data):

    • Click the Remember Keyword button to reveal the "Locked" icon and lock the keyword(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.
    • Click the Remember Keyword button to reveal the "Unlocked" icon and unlock the keyword(s) for the selected encryptor(s), marking the keyword(s) as private data.
11. Rotate Keyword Left button.

    Click the Rotate Keyword Left button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the keyword to the left.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Keyword Left button is enabled if the keyword is marked as private data, and disabled otherwise.

12. Rotate Keyword Right button.

    Click the Rotate Keyword Right button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the keyword to the right.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Keyword Right button is enabled if the keyword is marked as private data, and disabled otherwise.

13. Field "Unique, valid keyword".

    This field displays the unique, valid keyword (see Encryptor - About - Intermediate variables). The unique, valid keyword cannot be changed by entering a value in this field, but only by changing the keyword.

14. Field "Key".

    Enter the key for the selected encryptor(s). The key is a parsable token (see Encryptor - About - Parsable tokens).

    Field "Key" is disabled for cipher types "None" and "Keyword substitution".

15. Remember Key button.

    Click the Remember Key button to mark the key as private data (see Encryptor - Features - Private data):

    • Click the Remember Key button to reveal the "Locked" icon and lock the key(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.
    • Click the Remember Key button to reveal the "Unlocked" icon and unlock the key(s) for the selected encryptor(s), marking the key(s) as private data.
16. Rotate Key Left button.

    Click the Rotate Key Left button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the key to the left.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Key Left button is enabled if the key is marked as private data, and disabled otherwise.

17. Rotate Key Right button.

    Click the Rotate Key Right button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the key to the right.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Key Right button is enabled if the key is marked as private data, and disabled otherwise.

18. Field "Valid key".

    This field displays the valid key (see Encryptor - About - Intermediate variables). The valid key cannot be changed by entering a value in this field, but only by changing the key.

19. Field "Plaintext".

    Enter the plaintext for the selected encryptor(s). The plaintext is a parsable token (see Encryptor - About - Parsable tokens).

20. Remember Plaintext button.

    Click the Remember Plaintext button to mark the plaintext as private data (see Encryptor - Features - Private data):

    • Click the Remember Plaintext button to reveal the "Locked" icon and lock the plaintext(s) for the selected encryptor(s). Encryptor stores all locked parsable tokens, i.e., parsable tokens NOT marked as private data, when saving or quitting.
    • Click the Remember Plaintext button to reveal the "Unlocked" icon and unlock the plaintext(s) for the selected encryptor(s), marking the plaintext(s) as private data.
21. Rotate Plaintext Left button.

    Click the Rotate Plaintext Left button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the plaintext to the left.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Plaintext Left button is enabled if the plaintext is marked as private data, and disabled otherwise.

22. Rotate Plaintext Right button.

    Click the Rotate Plaintext Right button to attempt to find a match for the complexity requirements for the selected encryptor by rotating the plaintext to the right.

    This is an advanced feature (see Encryptor - Advanced Features). The Rotate Plaintext Right button is enabled if the plaintext is marked as private data, and disabled otherwise.

23. Field "Valid plaintext".

    This field displays the valid plaintext (see Encryptor - About - Intermediate variables). The valid plaintext cannot be changed by entering a value in this field, but only by changing the plaintext.

24. Field "Ciphertext".

    This field displays the ciphertext generated by Encryptor.

    Field "Ciphertext" is disabled for cipher type "None".

25. Use Keychain button.

    Click the Use Keychain button to allow Encryptor to create, modify, or delete keychain item(s) for the selected encryptor(s) (see Encryptor - Features - Mac OS X Keychain integration).

26. Synchronize Keychain Item button.

    Click the Synchronize Keychain Item button to create a keychain item for the selected encryptor or change the password for an existing keychain item.

    The Synchronize Keychain Item button is disabled when the keychain is not in use for the selected encryptor, or when the keychain is in use and the password for the selected encryptor matches the password for the keychain item.

    The icon on the Synchronize Keychain Item button is an "Add" icon if there is no keychain item for the selected encryptor, and changes from an "Add" icon to a "Refresh" icon if there is a keychain item for the selected encryptor.

    When the user makes a change which changes the ciphertext for the selected encryptor, for example a change to the plaintext alphabet characteristics or a parsable token, the Synchronize Keychain Item button is enabled. Clicking the Synchronize Keychain Item button will prompt the user to change the password for the keychain item.

27. Delete Keychain Item button.

    Click the Delete Keychain Item button to delete the keychain item for the selected encryptor.

    The Delete Keychain Item button is disabled when there is no keychain item for the selected encryptor, and enabled when there is a keychain item for the selected encryptor.

28. Complexity requirements.

    Encryptor provides visual feedback to the user to allow the user to easily confirm the plaintext (for cipher type "None") or ciphertext (for all other cipher types) satisfies the complexity requirements specified by the user via application and encryptor preferences (see Encryptor - About - Complexity requirements).

29. Status.

    Encryptor reports various status messages here. For example, Encryptor reports "Created a keychain item for..." when it creates a keychain item, or "Found a match for this [parsable token]" when it finds a match for the complexity requirements for the selected encryptor by rotating the parsable token.

Allowed character set

The combination of upper and lower case characters, decimal digits, and special characters allowed by the web service provider. Conforming passwords include only characters from the allowed character set.

Cipher type

The cipher type.

Complexity requirements

The complexity requirements established by the web service provider, such as: "must be at least eight characters", "must have at least one capital letter", and "must not contain more than three consecutive identical characters". Conforming passwords satisfy the complexity requirements.

Conforming password

A password which meets the minimum requirements established by a web service provider.

Key column

The first column of the tabula.

Personal encryption algorithm

The purpose of Encryptor is to allow users to combine something they have, i.e., a document recording their choices, with something they know, i.e., their personal encryption algorithm.

Encryptor records the details of password generation which are outside your control as a convenience to you and uses parsable tokens which you specify to encipher plaintext. This is something you have.

Encryptor supports the development and use of a personal encryption algorithm known only to you. Your personal encryption algorithm is the method by which the details of password generation which are outside your control and parsable tokens you specify are combined to generate a conforming password. This is something you know.

Tabula

The tabula recta (literally "square table").

The tabula recta is a latin square, specifically, a special case of a reduced latin square.

The tabula recta is generated from the ciphertext alphabet. The first row of the tabula is identical to the ciphertext alphabet. Each succeeding row of the tabula is shifted one character to the left from the preceding row. The number of rows and columns in the tabula recta is identical to the number of characters in the plaintext or ciphertext alphabet.

Valid

When referring to the intermediate variables unique, valid keyword, valid key, and valid plaintext (see Encryptor - About - Intermediate variables), valid characters are those in the plaintext alphabet.

Web service provider

A provider of services which require the use of the Internet or other private network. The term "web service provider" is used because "Internet Service Provider" (ISP) has a widely-used and established meaning.

URL

Uniform Resource Locator[1].

References:

This list is a list of published references which are cited in the documentation for Encryptor.

This list is not a comprehensive list of all references cited in the documentation for Encryptor. Allen does not consider documentation to which access is controlled exclusively by the originator to be published because this documentation is ephemeral and may be revised at any time. Frequently, the web service provider or other originator revises references without notifying the user that there has been a change, documenting what has changed, or following document control practices which were standard long before the advent of the Internet.

This does not mean that references accessible via the Internet, or only via the Internet, are unreliable. On the contrary, many of them are definitive. However, there is a qualitative difference between a Request for Comments (RFC) published by the Internet Engineering Task Force (IETF) as a technical document which defines a standard, and the user-level self-help available from Google or Facebook. The IETF states[1]: "Published RFCs never change."

Neither Google nor Facebook make, or indeed can make, such a claim about their user-level self-help, which changes frequently and without notice. As a result, the most reliable record of these requirements is a screen capture. In general, Allen considers the screen capture reliable and and the document to which the screen capture refers to be ephemeral. As a result, Allen considers the screen capture to be published, but not the document to which the screen capture refers.

References: