Giulio and I want to say thanks to those who have sent donations to Clipperz! Donations are a nice way to show your appreciation for our hard work. We would really be happy to build a viable business out of donations and keep Clipperz password manager a free service!

Therefore here is a little incentive: make a donation and automatically enter a drawing to win one of two Clipperz T-shirts! All past donators, no matter how much they donated, are included in the drawing as well.

The 2 winners will be announced October 15. All those who send their donations before October 14 are eligible for the drawing.

Believe it or not, here is how we will pick the winners:

1. Donations are numbered as they come in.
2. A random number is generated using the Clipperz password generator.
3. The first 2 groups of 2 digits will be used to select the winners. As an example consider the screenshot below: the winners are donators number 2 and 29. If a two digit number is higher than the total number of donations, the next two digits will be considered.

UPDATED ENTRY

When we launched our online password manager, we dubbed it the first example of a zero-knowledge web application. We simply meant that Clipperz knows nothing about its users and their data. It was a simplistic and inaccurate definition: the zero-knowledge paradigm needs to be better defined. Our fault.

The original idea aimed to leverage the internet to manage personal information, especially sensitive information. And without disclosing any information to the server providing the service!

The browsers is an ubiquitous and familiar tool and we wanted to use it as a gateway to the online vault containing user’s most precious data. Giulio Cesare was rather skeptical: he has been developing web applications for over six years and he knew how much data is possible to collect about users.

Nonetheless, we focused for months on designing a sound architecture for a new breed of “privacy aware” web applications. The basic idea was to deliver a no trust needed service, where users had the ability to inspect and verify anything running in their browser. We had to drift the attention away from trusting us and let users focus on trusting the application.

It was fun and frustrating at the same time. Privacy and security constraints were popping up everywhere. Despite that we grew convinced that many useful web applications can (and should) be developed applying the following zero-knowledge methodology.

1. Host-proof hosting

In order to avoid storing readable data on the server a zero-knowledge web application should encrypt and decrypt the data inside the browser. A neat idea, not new though. Richard Schwartz, Michael Mahemoff and others introduced the above concept under the name of host-proof hosting in the first half of 2005, few months before we started the Clipperz blog and project. Here is their definition from the AjaxPatterns wiki

Host sensitive data in encrypted form, so that clients can only access and manipulate it by providing a passphrase which is never transmitted to the server. The server is limited to persisting and retrieving whatever encrypted data the browser sends it, and never actually accesses the sensitive data in its plain form. It. All encryption and decryption takes place inside the browser itself.

Eventually Ajax made pure browser-based cryptography a reality. Javascript implementations of crypto functions have been around for years, but Javascript alone can’t remember data between page loads. This causes an annoying issue since it forces the user to re-enter the passphrase each time. On the other hand, an application developed with Ajax techniques tends to not actually do page transitions, hence solving the problem of keeping a persistent key to perform crypto operations.

2. Hide nothing

A zero-knowledge application should be trusted for itself and not because of the reputation of its developers. Therefore full access to the source code of the application is required.

This does not imply that a zero-knowledge application should be free or open source. As an example, Clipperz was originally released under a reference license meant to allow security code reviews while the core crypto libraries were released under a BSD license. [See updates below]

UPDATE 1
Clipperz code is now available under an AGPL license. See the Clipperz Community Edition project. Read more here.

UPDATE 2
The Clipperz Crypto Library, has been renamed Javascript Crypto Library and changed its license from BSD to AGPL. As a consequence it was moved from Google Code to SourceForge. Read more here.

2.1 Code inspection

Developers of zero-knowledge web applications must provide the same exact files that are loaded into the browser when accessing the application.

Usually these files are quite difficult, almost impossible, to work with: spaces and comments have been removed, variables have been renamed. To make life easier to code reviewers, it’s recommended to maintain the source files in their original form and provide instructions on how to derive the compressed and optimized versions. (see Clipperz build environment)

2.2 Code integrity

Performing a code security review it’s a complex matter, and it’s quite likely that most users will rely on reviews performed by others.

However any zero-knowledge web application should provide an easy way to verify that the application downloaded by the browser is the same application built from the code available for inspection.

Ideally we envision a solution that is completely browser based and relies on a redundant and distributed network of servers not associated with the application provider. Each third party server hosts the fingerprint of the zero-knowledge web application, i.e. the checksum of its source code.

At the moment, Clipperz is providing a less than ideal solution.

• The whole application is condensed into a single file containing all the resources needed to run the application on the browser: html, css, javascript and also the images (but for IE).

• The Clipperz website hosts both MD5 and SHA1 checksums of the above file along with the instructions on how to compute the checksum on your local machine.

(Any proposal to improve the above scheme is welcome!)

3. Prevent code changes

Zero-knowledge applications are basically huge Javascript programs running in the browser. Therefore it’s of the utmost importance to implement the necessary measures to stop any attempt to modify the code executed by the browser.

3.1 Download before login

The whole source code must be downloaded to the browser before the user signs in.

This is an essential requirements! If additional chunks of source code were downloaded from the server after the login phase, the user wouldn’t have any chance to verify in advance the security of the web application. Therefore not a single line of Javascript code should be moved to the browser after a successful user authentication.

3.2 Avoid code injection

Since Javascript is a very powerful and dynamic language, the borders between data and code are quite blurred.

In order to reassure a user about the fact that the web application he logged in won’t morph into a malicious program, a true zero-knowledge application should adopt the following measures:

• Never, ever, use the “eval” function on data loaded from the server
  The eval function offers great flexibility since it’s able to “run” any string. But if a web application allows to use it to process data provided by the server, then any kind of code could be easily injected, thus hijacking the original application.

• Limit the use of the “document.write” function
  Keep its use to the bare minimum, allowing for closer inspection when it is really necessary to use it.

• Never, ever, load any html content from the server
  Loading ‘htlm’ chuncks from the server is another easy way to subvert the behavior of the application. Just imagine what would happen if the server could push this little ‘html’ snippet: <script src="/hijack.js"/>

  The scary part, is that this token could be hidden anywhere, even attached to a legitimate response. For this reasons, all the html elements used by a zero-knowledge application must be loaded together with the source code before the sign-in phase.

4. Learn nothing

There are countless design decisions that could disclose information to the server. Sometimes data leaks are easy to detect, sometimes very subtle and dangerous. A zero-knowledge application should pay maximum attention to work with as little information as possible. It’s easy to fall for a new fancy feature that can destroy the whole security architecture …

Consider the protocol behind user authentication. The following paragraph clearly explains why a zero-knowledge application should adopt the SRP protocol or an equivalent verifier-based protocol.

While any reasonably secure authentication protocol is expected not to leak any information about the password to eavesdroppers, protocols classified as zero-knowledge do not even leak any information about the password to the legitimate host (except the fact that the party at the other end really does know it). This subset of verifier-based protocols is strong indeed, since the host never stores plaintext-equivalent information and is never given any such information during the course of authentication. (from srp.stanford.edu)

SRP is complex and slower than traditional methods, but it’s perfect to achieve zero-knowledge! Moreover it can be deployed without revealing to the host both the password and the username! (as we do in Clipperz password manager)

As a consequence of the “learn nothing” mantra, every zero-knowledge application should be completely anonymous, or at least it should make it impossible to relate the real name or email of a user to his data.

In the previous post I wrote about our zeal in building zero-knowledge web applications and our pledge to never introduce features that could compromise the integrity of our model.

Now I present a comparative analysis of Clipperz and PassPack with regard to the implementation of one-click logins. The analysis will clearly show the benefits of adopting a rigorous zero-knowledge methodology.

I usually don’t write about competitors, but the ability to log into a website with just one click is a very important and appreciated feature for any password manager and it deserves special attention.

Clipperz introduced “direct logins” in April, while PassPack re-launched the “auto login” feature few days ago.

---

Clipperz “direct login”

Setup and configurations

To create a new “direct login” for a specific website:

1. launch the “Add to Clipperz” bookmarklet from the login page;

2. copy the configuration collected by the bookmarklet to the card containing the login credentials.

No activation required. More detailed information here.

The one-click process

As the name says, it’s just one click on the desired “direct login” link.

Under the hood

What happens when a Clipperz user clicks on the “direct login” link for a specific website?

1. A new empty browser window opens.

2. The matching encrypted card is downloaded from the Clipperz server in order to obtain the following data:

   • the structure of the login form as collected by the Clipperz bookmarklet during the setup process;

   • login credentials for the specific website.

3. The decrypted data are used to create a copy of the original login form in the new browser window. Form fields are already filled in with the correct credentials.

4. The form is automatically submitted.

Zero-knowledge analysis

Clipperz cannot log any browsing usage or pattern because:

• the Clipperz server does not play any role when the user setup new “direct logins”;

• no data is transmitted to the Clipperz server when a user click on a “direct login” link.

Furthermore:

• “Referrer obfuscation” to protect user privacy is obtained by simply loading HTML code into a blank browser window.

• The “Add to Clipperz” bookmarklet is a generic tool, the same for every user. When launched it does not send any request to Clipperz (except for the IE version that cannot contain all the Javascript code and has to load it from Clipperz).

Usability

• “Direct logins” can be accessed from any PC and any browser without the need to install any custom bookmarklet.

• To keep the collection of “direct logins” always at hand Clipperz released the Compact version, designed to be opened in the Firefox sidebar.

• If the Clipperz server is down “direct logins” can still be accessed from the offline copy and they will work smoothly.

---

PassPack “auto login”

Setup and configurations

Users need to activate the “auto login” functionality and install the custom “PassPack It!” bookmarklet.

The one-click process

It’s actually a two step procedure:

1. click on the “Go” icon or the “Go there” link of an entry to open the login page in a new browser window;

2. launch the “PassPack It!” bookmarklet within 100 seconds to automatically fill in and submit the form.

Under the hood

When a PassPack user clicks on the “Go” icon of an entry:

[…] the browser makes a mini-encrypted pack and sends it, together with the URL for the website, over HTTPS to the PassPack server.

It’s sensible to imagine that the “mini pack” contains the user credentials for the specific website. The website then opens in a new window, but

[…] not directly though, first it passes (via HTTPS) through the PassPack server which does a little obfuscation […]

Afterward, when the user clicks on the “PassPack It!” bookmarklet, the “mini pack” will be moved back from the PassPack server to the new browser window together with the instructions, retrieved from the PassPack database, on how to fill in this particular website’s login form.

The “mini pack” is then locally decrypted using the “bridgelet key” that is generated during the “auto login” activation and then wired into the bookmarklet. At this point all information required to fill in the login form are available to the browser that can eventually perform the “auto login”.

Zero-knowledge analysis

Privacy issue 1

The PassPack server plays a central role and can potentially log lots of information about the online behavior of its users. They say:

We are not interested in your browsing habits, […] no information on who visits that link is stored.

Well, I’m sure it’s true, but they are explicitly asking their users to simply trust them. They will do no evil with your data, but the fact remain: PassPack could track your login patterns. What PassPack does with data traveling to its server cannot be monitored and verified by its users.

Privacy issue 2

Those taking the extra efforts to teach PassPack how to login to a new website, get a nice reward:

For security purposes, we need to be able to track down anyone who attempts to abuse the system. To help us do so, we store information that may help us identify the account that registered PassPack the site using the teaching process.

So if you are helping PassPack to grow the collection of websites that “auto login” can handle, consider that your username and email will be linked to every website you “teach” them!

Security issues

• PassPack maintains a database with “URLs of recognized websites and their relative structure”. Even if the content of the database can’t be related to specific users, it represents a further leak of information about the encrypted data stored in PassPack accounts.

• The “PassPack It!” bookmarklet contains the user’s “bridgelet key”. This is a critical piece of information since it’s involved in the encryption of the “mini pack” as it travels to and fro the PassPack server.

  Even if no information are provided about how the “mini pack” is built and encrypted (always a bad decision), chances are that the “bridgelet key” could potentially disclose information to an attacker. And it’s available to anybody accessing a computer where the PassPack bookmarklet has been installed.

  Furthermore, the “bridgelet key” does not change if the user deactivates and then re-activates the “auto login” functionality.

Usability

• PassPack users need to install their own “PassPack It!” bookmarklet on every PC and every browser they use.

• The “auto login” process relies on the availability of the PassPack server.

• “Auto login” always requires two clicks: one on the “Go” icon and another one on the “PassPack It!” bookmarklet.

• Often login forms are hosted on different web pages, sometimes even on pages with dynamic URLs. If the URL saved by a user in her PassPack entry does not match the URL stored in the PassPack database, it’s quite likely that PassPack needs to be “taught” how to “auto login”.

A true zero-knowledge web application knows nothing about its users and their data. We have been fascinated by this simple idea since 2005 when we started this blog. Since then it became our obsession.

We focused exclusively on exploiting Ajax and browser-based cryptography to build applications that users can wholeheartedly adopt to manage their private data. We started with a password manager, but we have more ambitious plans.

The whole point of writing a zero-knowledge application is to avoid the need for a trust relationship between the web application provider and the users.

It requires a strict discipline. It’s easy to fall for a new fancy feature that leaks some kind of information to the server destroying the whole zero-knowledge architecture. Clipperz won’t do compromises, won’t take shortcuts.

What Clipperz does know about its users

Every time a user loads the Clipperz login page, the following information are logged by Clipperz web server:

• IP address (and therefore the geographic area)
• request date and time
• browser type and operating system

All of the information above can be linked to a specific account, once the user successfully logs in. Furthermore, for each account, Clipperz web application could save the following data:

• date and time of account creation;
• dates and times of every single access to Clipperz;
• the number of cards;
• for each card: dates and times of creation, modifications and access;
• an estimate of the amount of information stored in each card, inferred from the length of the encrypted text (the estimate doesn’t include any details about the number of fields in that card or the presence of a direct login configuration);
• date and times of every downloads of the offline copy.

Actually we are not storing all the data listed above, but this doesn’t make any difference since we could!

65% of Internet users around the world speak a language other than English. As part of the effort to make our password manager accessible to more people in their native languages, we’re announcing the Spanish version of Clipperz.

Big thanks goes to Roberto Pereyra from Gualeguaychú, Argentina, for his translation work and his kindness. Spanish is spoken by more than 400 millions people in the world (including almost 40 millions US citizens), hopefully the new interface will help some of these folks use Clipperz and enjoy a new level of security for their passwords.

As usual, feel free to send in your corrections and suggestions. Users with their browser location set to a Spanish speaking country will automatically display the Spanish version of Clipperz. However, regardless of the browser settings, users can save their favorite language in the “Account > Preferences” section.

And feel free to use as many ñ (eñe) as you like in your passwords: Clipperz supports any foreign alphabet!

(Clipperz password manager is also available in English, Chinese, Japanese, Italian and Portoguese.)

We’ve been busy at Clipperz: 5 updates in about 3 weeks. It’s time to sum up all new features and improvements that have been introduced to make it an even better password manager.

• Faster encryption
  Did you notice it? If you have a good number of cards I’m pretty sure you did. Encrypting and decrypting your data is now at least twice as faster as before. The entire Clipperz application is now nimbler and more pleasant to use. We are still using the very same algorithms, but Giulio was able to dramatically improve performances by tweaking the code line by line. We can proudly claim that our Javascript implementation of AES-256 is the fastest available! And we are also proud to announce that these enhancements are reflected in our Javascript Crypto Library: a new version is available for download here under the usual BSD AGPL license.

• Password generator
  We announced it few days ago and our users quickly sent in many suggestions to improve it. We do listen! Now the password generator is always available under the new tools tab and it displays both the strength and the length of the generated password. Handy when you have to shorten it to, say, exactly 16 characters.

• Offline copy
  We noticed that downloading and running the offline copy was a bit awkward for many users, especially those using a Windows PC. Both XP and Vista sometimes detected dangerous code and refused to unzip the file, or the user was asked for a mysterious password. Now the entire offline version of Clipperz is just one single HTML file, very easy to download, save and run. Read more here.

• New bookmarklet
  The code of the new bookmarklet now includes the images needed to display the pop-over window. Previously they were loaded from our server. Not a big deal, but it was the only spot in our immaculate zero-knowledge conduct: we could learn something about the web services accessed by our users from the referrer log on our web server. You can keep using the old version, but it’s recommended to upgrade for an even better privacy. The new bookmarklet is available under the “tools” tab.

• Unscramble passwords
  Right below every password field there is now a new unscramble link. Click on it to reveal the password. It’s available both in “view” and “edit” mode. However if you need to just copy the password somewhere, the easiest way it’s still to click on the stars and then press Ctrl-C.

  

Once you start using Clipperz to protect your passwords and sensitive data, being offline could give you a sense of uneasiness, a weird feeling of being disconnected by your most precious bits of information. This is why we included the offline copy feature from the very first release.

Users have been dumping their encrypted data from Clipperz servers to a local hard disk in order to create a read-only portable version of Clipperz password manager to be used when no Internet connection is available. Many of them got into the habit of moving the offline version to a USB drive that they can take with them anywhere.

Today we are announcing a new Clipperz release that includes, among many other improvements, an easier way to download and run your offline copy. The downloaded file is no longer a ZIP file but a standard HTML file. Forget about uncompress it and then locate the index.html file. Just one single HTML file.

And just one click to open your offline version of Clipperz in any browser: it is as secure as the live application since they both share the same code and security architecture. Detailed instructions here.

A long-awaited feature requested by many users it’s now available: a strong random password generator. Generating long, high-quality random passwords is not simple. Now, when you need to create a new password, click on the new button that you find on the right of any password field. The small pop-up window below will appear, select the pools of characters to be used in the new password and click OK. That’s all.

It’s a very simple tool designed to securely generate password with an estimated entropy of at least 128 bits. Therefore password length will range from 19 to 26 characters, depending on how large is the pool of allowed characters.

Unfortunately some web sites have password policies that limits the length to fewer characters. In those cases simply delete a portion of the generated password to achieve the desired length. The password strength indicator will change accordingly: from the original bright green to less reassuring colors.

Please note that the entire source of randomness in this tool is Fortuna, the same cryptographically-strong pseudo random number generator used throughout Clipperz.

Memorable and pronounceable passwords are nice, but strong and long random passwords are secure! The use of these maximum-entropy passwords minimizes (essentially zeroes) the likelihood of successful “dictionary attacks”.

Today we launched a new version of Clipperz that, among other small improvements, includes a Chinese-language interface. We hope to make our password manager and digital vault more enjoyable and familiar to about one billion native speakers of this fascinating language.

I would like to thank Xiaoting Zhu for his translation work and his kindness. As usual, feel free to send in your corrections and suggestions.

Users with their browser location set to China will automatically display the Chinese version of Clipperz. However, regardless of the browser settings, users can save their favorite language in the “Account > Preferences” section.

(Clipperz password manager is also available in English, Japanese, Italian and Portoguese.)

Dan Smith, the Tamarin module owner, was kind enough to share with Clipperz the first official benchmarks of Tamarin vs. SpiderMonkey! These numbers are a very good indicator of the benefits that Tamarin could bring to Mozilla-based products. Dan says:

“Performance will be greatly improved over current JavaScript implementations, especially for typed code. Tamarin does much better than SpiderMonkey in nearly all tests except some of the numeric tests where it is doing extra type conversions. But future optimizations will certainly address these situations too.”

The benchmarks are based on the Computer Language Shootout tests.

Clipperz is an online password manager built on the concept of browser-based cryptography. Therefore we are very keen to learn how Tamarin could make the browser a better number crunching tool.

All crypto primitives (AES, SHA2, ECC, …) are algorithms mostly busy handling “byte arrays” and performing operations at byte/word level. Unfortunately the introduction of “typed code” will not bring significant benefits to this area.

The real twist would be the native support of byte arrays and efficient byte operations. That would be a blessing! However typed code is a first step in the right direction to enjoy dense and efficient arrays.

On the other hand the remarkable improvements already obtained with “nested loops”, “list handling” and “method call” will significantly speed-up crypto algorithms.

Now we have only to wait for Mozilla 2, better known as Firefox 4. Thanks to Dan and the Tamarin team members for their work!