PrivaSphere offers a solution to securely transmit information via the internet and to assure delivery to the trusted recipient. Keep your client infrastructure secure (i.e. computer hardware, operating system, browser..) Otherwise your security effort may not yield the desired results.
Even if you are i) sure that the machine is free of "malware", ii) close the browser entirely after retrieving private contents and iii) know how to ensure your private contents are not cached or otherwise stored on such a machine, we advise you NOT to use PrivaSphere services from public workstations!

If you have doubts whether your environment is contaminated with a key-logger or alike or if you do not 100% control your environment otherwise, to protect your PrivaSphere Password, use a 2+-factor login mechanism such as SwissID or client certificates.


See also:

Key Contact: Your hardware provider, operating system provider, browser provider, connectivity provider, and other relevant public sources must remain your primary/immediate choice when addressing client side security and privacy issues ...

List of possible dangers to your client (not exhaustive):

  • Browser Caching: Your browser may cache the documents it up- and downloads on your permanent storage. This is particularly exposing you if
    • your (browser's) temporary directory are on a server/shared drive
    • you share your machine - e.g. you have multiple login's on your PC
    • you access your permanent storage over a LAN that is open - e.g. a wireless LAN without at least WEP.
    • you use a public terminal - e.g. in an internet cafe
    • you use a desktop search tool such as Google's. There, you can at least turn off the indexing of the https received pages.
  • Remote Screen Reading: Now we get into a field that appears more remote. But if there are determined intruders, especially if they are equipped with military-grade intelligence tools, it is after all not that esoteric: Your screen can be read from a distance (even through windows) if your client is not tempest-proof.
  • Local Encryption: It is advisable to encrypt information you downloaded on your local disk as well. Among many solutions, Windows Privacy Tray appears to be an interesting one - open source oriented... VeraCrypt ist another one.
  • Remember Me Cookies: If done properly, such cookies that only remember your login, but not your password nor any other profiling information are not particularly detrimental to your privacy. The unfortunate thing, however, is that most browsers are not supporting you particularly well in separating good (i.e. typically session cookies and cookies that do not store sensitive information) from bad cookies. Most browsers on the other hand do support efficient login with their built-in password managers Mozilla/Firefox family, MSIE, etc. that provide acceptable privacy protection.
    PrivaSphere Services therefore have been architected not to require cookies. You can safely block any cookies that might come from us. We do this for our users not have to configure their browser in a way that in other contexts may become privacy-threatening.
    We suggest to use DoNotTrack (see and  
  • Remembering your passwords: Best is if you remember by a good password storage app such as passwordSafe on ( has a nicer user interface, but is not open source ...) SecureSafe Password Store.
    It is also important to be aware that when configuring " Send and receive from your mail program", your mail program is another place from where a determined attacker potentially could retrieve your PrivaSphere password. Therefore, only store your password in such programs if you are sure that no unauthorized persons will have access to corresponding account profiles you configure.
  • Protection against viruses and spam: While PrivaSphere has already provided basic mechanisms against unsollicited eMail (a.k.a. SPAM) such as the option to block certain senders or to require a " Human In the Loop Test" in your " Secure Contact Me" and it offers some server-side virus protection , it remains your responsibility to ensure the integrity of your machine in view of received eMail and attachments as well as downloads you get.
    • An approach that can be effective and is very hands-off for yourself (at the cost of an extra plaintext relay of your unprotected traffic) are outsourced services such as Cleanmail aka
    • If you have MSIE, turn off "open files on content, not on extension". Sure, some of your legitimate counterparts may not get the filename extension (and the MIME type) right, but in the vast majority, nowadays, this is mainly misused by attackers attempting e.g. exploit cross-site-scripting. (Tools - Internet Options - Security Tab - Custom Level)
  • JavaScript, ActiveX, Plugins, applets and other macros: PrivaSphere Services have been architected not to require such browser-side functionality that is a likely attack-point for all kinds of "malware" (see for example "cross-site scripting" in chapter 'Common Problems' in the OWASP Guide). You can safely disable these features and still enjoy our full service line. Unfortunately, quite some other sites are not crafted in such a security aware way and require you to have these enabled. In this case, it makes sense to only temporarily activate these features if you really need to work with such a site.
  • “Harden” your mail program: In particular, if you read messages encrypted with S/MIME or PGP (, turn off automated html-loading (external images, styles, javaScripts, “objects”, etc.) and possibly also “message preview” (you probably will be able to delete many messages prior to seeing the potentially malicious content already based on subject and “from”). To be even more secure, you might want to decrypt your encrypted messages on the command-line with e.g. openssl or gnupg.
  • Walk-By Impersonators: Without appropriate precautions taken, somebody walking by your computer, there are various risks of impersonation:
    • Logoff omitted: with in the session auto-time-out period (normally 30’)  a walk-by user could sit at your browser and use the back-button or if the browser even has been closed, the URL-history might still contain a valid jsession id. Therefore, always logoff, use a password-protected screen-saver when walking off your desk (and additionally auto-activate it after e.g. 5 idle-minutes just in case)
    • After client certificate based authentication, even if you logoff, a re-login might not prompt for the private key password since often, the private key is cached in the browser. Therefore, if walking off your desk, unplug your keystore device (USB Reader, Smart Card, etc.), or if the keys are in your operating system, close the browser to ensure it no longer caches the private key needed for login.
    • So, wiping the browser-URL-history may be useful if shortly after you, next person is to use the same account.
    • Other advice: Wipe your cache regularly, prevent https pages from being stored.
  • Protocol Switcher: In order to see your passwords in the clear, one attack is to trick you into accessing the secure site without https. To minimize this risk, PrivaSphere has activated “HTTP Strict Transport Security” ( Choosing a browser that supports this extension will likely protect you against this attack for 30 days after leaving your home base.
  • Certificate Authority subversion: Unfortunately, illegitimate persons issuing false SSL certificates from within a up to now legitimate Root CA is no longer unheard of.
    Having your browser ( ) or a plugin (e.g. ) doing “certificate pinning” will trigger your attention if a site all of a sudden changes the issuer or re-issues” SSL certificates significantly before their expiration.
  • "Use of weak ciphers": The PrivaSphere Servers support a wide range of ciphers to be able to provide basic security to users from a wide range of technological equipment. Configure you browser such that it supports the most secure ciphers available within this choice - see:
    see also: Good ciphers used by PrivaSphere Secure Messaging

  • Maintenance recommendations
    If protecting the contents on your local machine is a concern to you, we suggest you
    - regularly have your browser wipe the history, cookies and cache
    - protect the browser's password/form-filler with a good password
    - wipe the system's %TEMP% directories - often your local anti-virus-product offers button to easily do this.

    - update your client software (browser, mail, pdf, etc.): Older versions of the clients might be incapable of supporting ciphers with forward secrecy or the TLS versions > 1.0 that are considered more resistant to the BEAST attack on TLS, see:

see also:



Do not enter your PrivaSphere password into a fake site. PrivaSphere does not ask you for your password except on the (main or message) login screen.

If you are in doubt, check first:

The lock near the Link in your browser is closed. Communication with PrivaSphere Secure Messaging is always SSL protected (https):

If you click on the lock, you must see a root certificate of a well known certificate authority and the privasphere website certificate depending on it:

Most phishing attempts try to fool you into entering your account password or MUC in a wrong place.

Typically you receive an html-formatted mail pretending to bring you to a site to which it does not actually bring you.

The attackers try to deceive you about the site address. For example a capitalized "I" is put in place of a non-capitalized "L".

Also by phone, we never ask for your password ever, only for your security question. Do not tell your password to anybody. PrivaSphere support does not ever need to know your password and will only ask you for your personal security question you have chosen upon registration.

The fingerprints of PrivaSphere's site certificate (valid until 29.10.2015 are):

SHA1 Fingerprint=0C:3A:D7:A3:BD:80:F8:54:BD:B4:76:76:20:B0:86:2C:5E:77:EF:37

The fingerprints of PrivaSphere's mail server certificate (valid until 9. ‎April ‎2017 are):


SHA1 Fingerprint=BE:76:89:66:11:BE:CD:D2:9D:D3:5A:B6:8B:71:96:C3:0A:85:F0:AD

and PrivaSphere's signing certificate (valid until Feb 28, 2015 are):

SHA1: ‎04 2e 8f 65 96 f1 b4 5e 14 fb 61 ec 42 18 bf f2 f2 74 f8 bd

If still in doubt whether you are on the legitimate PrivaSphere site, then contact a PrivaSphere representative for additional assistance.


See also:

PrivaSphere Secure Messaging aspires to offer state-of-the-art  ciphers for SSL/TLS encryption of the web site and for POP/SMTP.

Unfortunately Microsoft Windows (with Internet Explorer and Outlook) does not take  automatically the strongest offered encryption offered by the servers – it normally takes a medium encryption by default.

Windows Vista and higher does support 256-bit AES, but it publishes 128-bit first in the list and thus this is what is used by most applications in a Windows environment that rely on Windows’ built-in SSL libraries (i.e. Internet Explorer, Outlook, etc.).

You can remove ciphers that you do not want and change the order of their presentation by using the “group policy editor”.  For example, to make 256-bit AES the default choice, rather than 128-bit AES or RC4, follow these instructions:

For Windows Vista or newer:

  • Open your group policy editor by entering gpedit.msc at a command prompt (Power Shell – run as  as administrator).
  • Choose Computer Configuration | Administrative Templates | Network | SSL Configuration Settings.
    There’s only one item here: SSL Cipher Suite Order. Open it.

  • Select Enabled
  • Now here’s where you need to tread carefully. You’ll see that the list is the same as above, but rather than formatted nicely with carriage returns, they’re simply separated with commas. The first item in the list is:
    And the second item is:
    Cursor your way through the list. Change that first 128 to 256. Then cursor forward a bit more and change the 256 to 128. 
    (If you can’t edit or type — copy the value, paste it into Notepad, edit it there, then paste it back in the field).
  • If you want to get rid of RC4, so that your computer uses AES instead of RC4, and you know that your browsers are safe from The Beast, remove the RC4 items in the list as well.
    E.g. TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128_MD5, and SSL_CK_RC4_128_WITH_MD5
  • Feel free to change other orders, too, but keep your changes within algorithm types.
  • OK your way out, close the group policy editor, and reboot.

PrivaSphere tested successfully the following entries – it worked for Internet Explorer 10 and Outlook 2013 on Windows 8:

(paste this string into the editing field without returns nor blanks).

Probably you will not be able to use some web pages which offer only weak ciphers. But is it worth to visit them? If yes, you have either to enter the weak cypher here or to switch this setting off (temporarily).

Normally, MD5, DES, anything below 128 Bit key length and due to the BEAST attack often also RC4 are considered “deprecated”. Try to favor ciphers that offer “forward secrecy”.

Furthermore, also activating TLSv1.2 in the Internet Explorer is recommended:

  • Step 1: Click on ‘Extras’ – ‘Options’ – ‘Advanced’
  • Step 2: Check the box “Use TLS 1.2”

for 'Forward secracy' see also (in German):

To test your browsers SSL settings use the following link:


Unfortunately, some “Home” versions of Windows7, do not offer gpedit.msc . Even downloading it would not show the above “SSL Configuration Settings” or

Any hints how to configure the ciphers in those windows versions is appreciated.

If a non-Microsoft client software sees warnings or is blocked, please contact us - if you know the solution and have some corresponding screenshots - please contact us too


See also: