Viewpoints

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 http://www.mozilla.org/en-US/dnt/ and http://de.wikipedia.org/wiki/Do_Not_Track)  
• Remembering your passwords: Best is if you remember by a good password storage app such as passwordSafe on sourceforge.net (http://www.bagus-software.de/ 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 spamfree.ch.
  • 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 (https://efail.de), 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” (https://www.owasp.org/index.php/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 (http://blog.chromium.org/2011/06/new-chromium-security-features-june.html ) or a plugin (e.g. https://addons.mozilla.org/de/firefox/addon/certificate-patrol/ ) 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:
  http://www.quora.com/Internet-Security/Is-it-possible-to-force-browsers-like-Chrome-and-Firefox-to-prefer-a-stronger-cipher-for-SSL-first
  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: https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-bhttps://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls

see also:

• Client Side Security

• Encrypted download as PDF or ZIP

• Security and Encryption

• Good ciphers used by PrivaSphere Secure Messaging

• Heise: Zukunftssicher verschlüsseln mit Perfect Forward Secrecy