http://mivo.truxoft.com
MIVO!
miva beyond limits

• Sends order information by PGP encrypted notification e-mail instead of plain insecure SMTP
• Optionally sends payment details (e.g. CC#) in the PGP encrypted notification
• Optionally removes the payment data (eventually containing unencrypted CC numbers) from the payment database.
• Optionally sends detailed user data including the IP address, host, agent, language, etc.
• Optionally sends HTML formatted e-mail (aligned columns)
• NEW: Full featured and highly customizable HTML formatted and encrypted e-mail may be sent in cooperation with the MmHTML module
• Works with both PGP and GPG (GNU Privacy Guard) of diferrent versions
• Supports Miva Merchant 2, 3 and 4 on Unix platforms
• Both English and German localizations available (others may be done on request)
• Does not require OpenUI. Works with both OUI and MMUI.
• Adds the order ID number into the subject of the e-mail for better tracking

1. Screenshots
2. MmPGP fulfillment module
3. Compatibility
4. System Requirements
5. MmPGP Installation
6. Buy the module
7. Support
8. Known Limitations and Bugs
9. FAQ
10. Troubleshooting
11. Security notes
12. Wish List
13. Change Log
14. Useful links
15. User Comments

top

Merchant and store owners often ask for having not only the order information e-mailed to them, but also the payment data including the credit card number. Often they are not aware that sending such data over the net with plain unencrypted SMTP is very dangerous. Laws protecting personal data and privacy make such delivery even illegal in some countries. Data flow containing unencrypted information may be checked for known patterns of CC numbers with an automated program on any part of the route from the server with Miva Merchant to the owner's PC.

Additionally, storing CC data or sending them via e-mail unencryoted is direct violation of VISA policies (and policies of other CC institutions or your payment gateway) and may be prosecuted or be reason for terminating your merchant account. The following basic requirements are taken directly from VISA CISP (Cardholder Information Security Program):

1. Install and maintain a working network firewall to protect data accessible via the Internet.
2. Keep security patches up-to-date.
3. Encrypt stored data accessible from the Internet.
4. Encrypt data sent across public networks.
5. Use and regularly update anti-virus software.
6. Restrict access to data on a "need-to-know" basis.
7. Assign a unique ID to each person with access to data.
8. Do not use vendor-supplied defaults for system passwords and other security parameters.
9. Track access to data by unique user ID.
10. Test security systems and processes regularly.
11. Maintain a policy that addresses information security for employees and contractors.
12. Restrict physical access to cardholder information.

MmPGP module sends the order and payment information to the owner in a secure way, asymmetrically encrypted with his public PGP key. Please read the art0038.htm for more details about PGP in relation to Miva.

Most payment modules store the payment data, optionally including also CC numbers and/or other sensitive information unsecured and unencoded to a database on your server. It is not only very dangerous, but may be even illegal in some countries (I believe Germany is one of them). The current standard of server security protection is very low at the majority of host providers and for a hacker it is usually a question of minutes to break into any account. Also different versions of Miva engines, Miva Merchant, and especially third party Miva modules and scripts, very often open your system to very easy exploits. If you have such insecure Miva programs on your server, an experienced Miva programmer can download any of your databases within seconds. The consequences of exposed payment data may be fatal for your business.

Before purchasing the module, please be sure to check the compatibility list and to have properly installed and configured a PGP (Pretty Good Privacy) or GnuPG (GNU Privacy Guard) on your server. See also the PGP International site with links to PGP freeware for various OS.

I also strongly recommend reading the art0038.htm article and downloading the MvPGP Library (free for personal use) on your server to check the compatibility. Copy the MvPGP anywhere to your public Miva script directory and call it from a browser (e.g. http://yourdomain.com/mvmpgp.mv) to verify it it works. MmPGP and MvPGP are built on the same basis and therefore systems where MvPGP test runs without problems, should not have any difficulties when installing the MmPGP.

top

MmPGP was succesfully tested with following server-side encryption software:

• PGP 2.6.x
• PGP 5.x
• GnuPG v1.0.x

• Miva Empresa 3.7x, 3.9x

• Miva Merchant 2.2x (MMUI, OUI)
• Miva Merchant 3.x (MMUI, OUI)
• Miva Merchant 4.x, 4.1x (MMUI, OUI)

NOTE: the CC number may be sent encrypted by MmPGP only at those payment modules that enable storing the CC# locally (see the payment module proprieties in the Merchant Admin). Otherwise the payment module has to be customized (currently not included with MmPGP).

• COD 2.25, 3.01, 4.0
• Credit Card Payment With Simple Validation 2.25, 3.01, 4.0
• untested but compatible: Anacom Payment Services
• untested but compatible: Authorize.Net Payment Services
• untested but compatible: CyberCash Payment Services
• untested but compatible: CyberSource ICSv2 Payment Services
• untested but compatible: Cardservice/LinkPoint Payment Gateway
• untested but compatible: Verisign Payflow Link
• untested but compatible: Verisign Payflow Pro (PaymentNet)

• Linux, FreeBSD and should rund on other Unix clones too. Shell access is necessary.

Recommended e-mail client: MS Outlook with Network Associates PGP Mail. Current versions of Outlook Express (v6.0) and Eudora (v5.1) support PGP encrypted plain-text, but their support of HTML formatted messages is just limited (especially at OE).

top

• Miva Empresa 3.7 or higher on a Unix server (Windows platforms are currently not supported)
• Private cgi-bin directory accessible and writable by Miva. Cgi-bin directory should be visible in the folder structure when you log into your server with FTP or sFTP.
• Working shell accesible by Miva. If you have no Telnet or SSH access to your server, then it is probable that you have also no shell - ask you hosting provider to verify it.
• Installed and working PGP or GnuPG on your server
• Secret key-pair generated - do not use same key or pass phrase as on your local system! Keep on mind that a web server is not a safe place for storing secret keys. You may even remove the private key after generating the key-pair; MmPGP does not need it.
• Keyring in the PGP/GnuPG home directory containing recipients' public keys. Import the public key of the target user (store owner) to the key ring.
• Signed public keys: sign any key you have imported.
• The private PGP/GPG directory (typically .pgp or .gnupg) must be in the private folder of the same user that is used to access documents from the web (In Apache it is the directive User in the VirtualServer section of the httpd.conf that determines it).

top

Installation instructions for Cybrmall hosted websites may be found here

1. Check if your system matches the compatibility list and system requirements
2. Download and run the free MvPGP script to verify the compatibility to your configuration
3. Purchase the MmPGP module
4. Log into the Miva Merchant Admin and go to Modules/Add Module
5. Upload the mmpgp.mv (click on the Upload File icon button) and add it (the Add button on the same screen)
6. Select the Order Fulfillment Configuration in the menu of the store where you want to use the PGP notification.
7. Check the PGP Email Merchant Notification and click the Update button
8. If your system is compatible and MmPGP can find all necessary files and directories automatically, the module performs all installation steps seamlessly. In the opposite case, the MmPGP will prompt you for the location of one or more directories or files, showing detailed information about the requested item. If you are unsure about the right location, please contact your system administrator.
9. Click on the  PGP Email Merchant Notification  tab, verify and modify parameters if needed:

From: Customer's Email Address

in contrary to the original Miva Merchant notification module, this feature should work with most mail servers properly (even those restricting relaying by default).

From: Other

Store owner's address by default and any other address possible as well

To

E-mail addresses of all public keys from your server PGP/GPG keyring will be listed here. Choose the one you want to use for the notification. If there is just a red error message, you need to import the target key to the server's keyring.

CC

one ore multipe comma separeted CC addresses. The recipients will received the notification encrypted with the same public key as the original.

Subject

Subject of the notification e-mail

Send payment info

If checked, the payment info provided by the payment module (usually containing also the CC#) will be attached to the notificatio e-mail.

User tracking

If checked, additional user data will be sent (IP address, host, agent,...).

Remove payment data

If checked, after sending the notification successfully, MmPGP deletes the payment record from the payment module database and packs it to remove the sensitive information from the server. If you are installing MmPGP on a Merchant with a huge order database, I recommend removing the old payment data from the payment database manually to avoid their exposure and also to avoid delays during packing the database. Please note that the payment record would not be removed if the notification was not sent because of an SMTP error. In such a case you should remove the record manually.

Header

Text that will be send at the top of each e-mail notification.


Parameters for advanced users:

PGP call to

Normally the name of the current domain will be used to call the shell script passing the data to PGP/GPG. The data from Miva to PGP are unprotected in this moment, but in usual cases it is no problem because both Miva and PGP are located on the same machine and the data is not exposed. However, in some special cases (for example at server clusters), Miva and PGP may physically reside on different systems. The data should still flow through a secure internal network. Using localhost instead of the domain name may avoid accidental sending of the data through an external network. It is not an universal solution and it may not work on some non-standard nsystems at all. Please consult your system administrator if you are unsure about your configuration.

PGP Type

If you have more types or versions of encryption software on your server and you want to use another one than that installed automatically by MmPGP, you have to set up the type, the PGP directory and the PGP binary name manually.

OS Shell binary

The name of the Unix shell binary. On many systems it is located at /bin/sh. You have access to it only if you have a full shell account. Usually it means that you can access your server with Telnet or SSH. The path to the shell binary is absolute (from machine's root)

cgi-bin directory

In addition to the shell, you have to be allowed to install own CGI programs. If you have a full shell account, than you have quite probably also a private cgi-bin directory. The path of the cgi-bin directory should be relative to the Miva script directory.

PGP user home dir

the location of your private server's PGP configuration files and key keyrings. Typically it is in ~/.pgp (PGP), resp. ~/.gnupg (GnuPG) (usually equivalent to /home/username/.pgp, resp. /home/username/.gnupg). The path may be absolute (from machine's root) or relative to the user home dir.

PGP binary file name

the name of the encryption binary. Typically pgp for PGP and gpg for GnuPG. If the encryption program cannot be accesses directly with typing the name on the Telnet prompt, you may need to enter the full path (absolute or relative to the user home dir) - test it in Telnet in case of problems.

10. Click the Update button to save the changes (even if you made no changes at all!)
11. Make a test order to verify if the PGP notification works well.

top

We offer a  limited free suport  within 30 days after the date of the purchase for modules bought directly at  truXoft Co. or at affiliated resellers as written above. The support is limited to platforms from our compatibility list below and does not include any help with installation or configuration of payment modules, or other general Miva Merchant problems. We also do not offer any free support of PGP or GnuPG. Please use the support of the vendors of your encryption software, your hosting provider support, or PGP oriented user groups.

We can also provide paid support for PGP/GPG installation, configuration and other issues not included in the limited free support, at rates of $100 US/hour (each started hour charged as full). Setting up a PGP/GPG account on a server with properly installed PGP would typically take 1 hour. Installing of GnuPG (freeware under GNU license) or PGP (if you have a valid license), would typically take 1-3 hours on servers without specific problems.

top

• MmPGP does not work on Windows server platforms (NT Empresa, Mia). PS: All client platforms with PGP or GPG are supported.
• Fixed in MvPGP Lib v 0.124: With some versions of local-side PGP interfaces, in the notification after the decryption, the dollar sign and few other special characters may appear prepended with a backslash. It may slightly distort the column aligning.
• Some messages in the installation are not yet localized to German - currently available in English only

top

What is PGP and GPG?

Encryption programs. See more at the  art0038.htm

What is ~/ ?

In Unix ~/ stands for the user home directory. It means the directory where all your files are located - it may contain folders keeping your web documents, miva data directory and many other files. Usually and correctly it should not be accessible from the web by a browser. Typically, on many systems it is equivalent to /home/yourloginname/

How to initialize an already installed PGP or GnuPG?

Please refer to the PGP/GPG vendor's documentation for details. Often the following two steps would be enough to initialize a properly installed PGP or GnuPG if MvPGP/MmPGP is unable to do it for you:

1. Create a .pgp (for PGP) or .gnupg (for GNU Privacy Guard) directory in the server home directory (typically /home/username/.pgp or /home/username/.gnupg)
2. Generate a secret keypair - in a Telnet session type:
   pgp -kg (PGP), resp.
   gpg --gen-key (GnuPG) and follow the prompts.

How do I import my public keys into the server's key ring?

Preferably use the MvPGP/MmPGP interface for doing so. You can do it from the shell too:

1. On your local machine export your public key (not the private one!) to a file.
2. Upload the file to your ~/.pgp (resp. the ~/.gnupg) directory on the server.
3. Type pgp -ka "the key file name" (PGP),
   resp. gpg --import "the key file name" (GnuPG)
4. Type pgp -ks "key's e-mail address" (PGP),
   resp. gpg --sign-key "key's e-mail address" (GnuPG) to sign the imported key.

Why the imported keys do not appear in MvPGP/MmPGP?

See also the troubleshoting section below. There are several possible reasons:

• If you successfully imported the key manually in a shell session (Telnet or SSH), then, most probably, your server uses other user ID (and therefore also other PGP/GPG configuration and keyrings) for cgi scripts than your own uid used in a shell sessions.
• If you attemped to import a key with the MvPGP/MmPGP interface, then the PGP home directory is not properly set. It must be either inside of the original user home directory of the uid used by the web server when calling cgi scripts or it must be a subdirectory of the mvpgp (resp. mmpgp) directory in your own Miva data directory.
• The key was not a valid public key or is not compatible with the PGP/GnuPG version on your server. Check also the paragraph "Unsupported packet format..." below.
• You imported the key from a public server, but it was down, or you did not use the 8 bytes long hexadecimal user ID from the key's properties

Why I am getting: "gpg: Warning: using insecure memory!" (GnuPGP)?

It means that GPG uses a portion of operating memory possibly vulnerable against attacks from people having access to the machine (not visitors from the web). Although it is not a too serious threat, you or your system administrator should change the GPG binary permissions as follows: chmod +s /usr/local/bin/gnupg

Why I am getting: "Unsupported packet format - you need a newer version of PGP for this file" (PGP 2.6.x)?

On your local PC (with the target keys), create and export a key with RSA Legacy algorithm (resp. RSA if no RSA Legacy available) instead of DH/DSS.

top

In case of troubles, before contacting the support, please be sure to:

1. read the FAQ
2. check the changelog and update the module to the latest version
3. read known limitation and bugs

Fixing Installation Problems

There is only a blank page in the MmPGP Admin screen in Order Fulfillment Confiuration

Please install the MvPGP library manually: save the source of the library to a file named mvpgp.mv, create a directory /mvpgp/ in your public directory (Miva Script directory) and upload the mvpgp.mv file there through FTP. Then run the script through your browser to install the library - call http://yourdomain.com/mvpvg/mvpgp.mv.

'Cgi-bin directory not found!' (MER-PGP-00008)

During the installation process, MvPGP/MmPGP needs to be able to create scripts in the currently active cgi-bin directory. It means that this directory must be accessible from either the Mva Script or the Miva Data directory root. If the installtion routine does not find the paths to the cgi-bin automatically, you need to enter the path, relative to either the Miva Data or the Miva Script directory, manually.

It does not make any sense to create a new cgi-bin directory (otherwise MvPGP/MmPGP would create it itself, of course). Only that cgi-bin directory that is assigned as ScriptAlias in the Apache configuration file (or equivalent on other web servers), may be used.

If the cgi-bin is parallel to both Miva Data and Miva Script directories (and nowhere overlapping with any of them), there are still other possibilities to install MvPGP/MmPGP. Try one or more of the following instructions:

1. Create a symbolic link manually within your Miva Data or Script directory, linked to the original cgi-bin. In the same time, you have to change the Miva configuration to accept symbolic links (securityoption=15 - disabled by default). After completing the installation you should remove the symbolic link and reset the Miva configuration to the original state, so everything would be as safe as before again.
2. Temporarily change the ScriptAlias directive for your domain in the httpd.conf to point to a temporary cgi-bin directory within your Miva Script directory. After completing the installation sucesfully, copy the mvpgp.cgi (resp. the mmpgp.cgi) to the original cgi-bin directory, reset the httpd.conf to the orginal state and remove the temporary cgi-bin.
3. If you are using GnuPG on the server side, you may download the mvpgp.cgi shell script and install it in your cgi-bin. Set its permissions to 755 and run the mvpgp.mv installation directly from your browser in this way: http://yourdomain.com/mvpgp/mvpgp.mv?MVP_Cybrhost=1

'Miva Data Directory not found!'

One of possible reasons of this error message is a different user ID (uid) used for the Miva engine (usually the account owner's uid) and another one for the web server (often 'nobody' or 'www' with Apache without cgi wrapper like suexec). Another reason may be use of other than the default name for your Miva Data directory. The most secure way, is entering the full (absolute) path to your Miva Data directory. If you are unsure about the correct path, log in with Telnet, go to your Miva Data directory (e.g. 'cd htsdata' or 'cd mivadata'; on some systems the Mivadata may be identical with the user root dir) and type pwd to see the full path. Here are few examples:
/home/accountName/htsdata/   (e.g. at CI Host)
/home/sites/site156/mivadata/   (e.g. at Cybrmall)

'No public keys!'

Most evident reason is that you have not imported any target public keys into your key ring. If you did it already (whether manually in Telnet/SSH or through the MvPGP/MmPGP interface), then a different user ID (uid) for CGI scripts and for Miva scripts could be the reason. Web servers (like Apache) sometimes use a special uid for calling documents and CGI scripts - often 'nobody' or 'www'. When there are respective user directories (e.g. /home/nobody), MvPGP/MmPGP should be able to work with the default '~/.gnupg' (resp. '~/.pgp'), but if there is no such directory on the system, you have to enter it manually. If the default dir does not work, a directory within the MvPGP/MmPGP subdirectory in the Miva Data dir should be used (see the paragraph above for ways to find out the path on your system):
/home/accountName/htsdata/mvpgp/.pgp/   (e.g. at CI Host)
/home/sites/site156/mivadata/mvpgp/.pgp/   (e.g. at Cybrmall)
(replace the mvpgp with mmpgp when installing a Merchant PGP module instead of the plain MvPGP library)

Enter the new location for the PGP/GPG home directory and try to import a key through the MvPGP/MmPGP interface. NOTE: MvPGP/MmPGP always tries to create the directory with the web server's uid and you may not be able to delete it from within a Telnet/SSH session, unless you have root access to the server. The directory may be removed with a cgi script in your cgi-bin called from a browser:

#!/bin/sh
echo "Content-Type: text/plain"
echo ""
rm -Rf /home/sites/site156/mivadata/mvpgp/.pgp/
exit 0

top

When using the MvPGP library or the MmPGP module, you should be aware of certain facts regarding the security.

You should disable access to the mvpgp.mv script to avoid access to it by by unauthorized visitors. Normally it is enough to disable both, the configuration listing and the test with selecting the 'hide' checkboxes on the mvpgp.mv page. You may additionally restrict the access to the file from the web totally in the Apache's .htaccess configuration file in this way:

<Files "mvpgp.mv">
 Order Deny,Allow
 Deny from all
</Files>

Because of the location of the PGP/GnuPG configuration and key ring files on a public server, you should not trust the encrypted e-mail comming from the server. Anybody being able to break into your server, would be able to send e-mail using your PGP/GPG configuration and your secret keys. MvPGP/MmPGP in the recent version does not install any secret keys and if you do it manually, you should never use the same passphrases as you use for your usual encryption. Keep on mind that if somebody gained access to your private keys on the server, theoretically he might be able do crack then using brute force. There is no risk, if the secret key is used just on that server and never used for signing or exporting trusts to other keys. MvPGP/MmPGP does not use the secrete keys at all, so you may remove them from the keyring, or use just a dummy secret keys. MvPGP/MmPGP encrypts messages with the addressee's public keys only and do not sign them with the server's secret key.

MvPGP/MmPGP on systems with GnuPG uses the option --always-trust for any imported keys. This was made to simplify the automated installation procedure, but if you prefer signing all imported keys manually, please edit the mvpgp.cgi (resp. the mmpgp.cgi) in your cgi-bin directory and remove any instance of the --always-trust option. It brings you more security, because every new key must be then signed using the server's passphrase manually from the shell (SSH/Telnet).

top

• MmPGP for Miva Empresa NT

top

top

top