I’d be interested in seeing a third party evaluation of the security of this.

I too would be interested in a obviously professional and in-depth 3rd party review/audit of all of the code, system, and people behind it.

I can likely trust it for everyday website logins, but before any proud geek uses it to store credit card info, we want independent verification… multiple, reliable sources if possible.

Great work you are putting out there. Seriously. I had the same exact idea in my head for the past 1.5 years, but never acted on attempting anything. If you win the trust of people, it will be a big success, not small. Best of luck.

Any third party review is certainly welcome, but there are some problems:

• we cannot afford the relevant amount of money that a security professional will ask; and since we frequently release new versions …

• conflict of interests: will your trust level increase if we pay a 3rd party to analyze Clipperz security?

We opted since the beginning of this venture for complete transparency and community reviews. This is why we provide instructions about how to download our source code.

This is also why we released the core crypto functions under a BSD AGPL license. See our Clipperz Javascript Crypto Library.

What do you think of our approach? Any suggestion?

Thanks, Marco

I think that you are presenting the concern near the best that you can with your resources (although, you may want to spell out your resources, see bullet below). Your ideas are huge leaps in the right direction, but there is always more that you can do.

Here are some thoughts and ideas to provide cheap security peace of mind to potential users:

First, by professional, I did not necessarily mean paid. Eventually, there are going to be open source advocate organizations, security focus groups, conferences, etc, that will see these new online password management projects. I consider some groups, and people like the above to be ‘professional’. Many non-profit groups, conferences, and security web sites, do handle a budget, donations, etc. This is very much professional, and also their public credibility go a long way.

• Angle communications of awareness and invitation to these open-minded security groups, businesses, conferences, individuals, and open-source communities . Dare them to break your code, run a contest! Every geek likes a dare, even if they do not win much.
• Collaborating with google code was ingenious for trust. If there are other opportunities with Google or similar companies, do it. Apple is another up and comer that a lot of security minded people are moving to. Angle the Mac crowd possibly.
• I do not think you have done the best job of spelling out what your business case/implications are for this project. How will you make money, or not, etc? To become completely transparent, you need to make an entire page and comment/forum area about what your business plans for the future are, it goes a lot towards trust. I have not seen many companies display their in-depth business plan to the public, yet I think that it would make sense here.
• Explain and make simpler, a method of comparing or equivalencing the provided source code with the code being constantly served from your site. Yes, you provide the checksums, but that is of the compressed code. How do we know that the compressed code equals the provided source? There should be a solid, proof positive system that users can verify automatically, easily and independently, at any time. Maybe checking check sums can become more integrated in some way? A user wants to KNOW that the code coming up on the public library computer he is on is for sure the same, proven source code. The user may not have time for, understanding of, or ability to run md5 or sha1 commands.
• You could register yourself or become accredited by 3rd party organizations without too much $$. Organizations such as the US Better Business Bureau, http://www.bbbonline.org , TRUSTe http://www.truste.org/ , Common Criteria http://niap.nist.gov/cc-scheme
• Fully comply/follow standards such as this NIST Information Security document. It explains how governments get certified and accredited, how security can best be documented, etc. http://csrc.nist.gov/publications/nistpubs/800-37/SP800-37-final.pdf (appologies if my specific references are too USA-based)

Is the same password used when logging in at clipperz.com as is used when encrypting the data locally?

The short answer is “no”.

The long answer is too long to be tell on a comment, but I will try to point out the main elements:

• we use the SRP protocol to authenticate Clipperz’s users; this protocol works without ever sending the password to the server, neither for registration nor for authentication;
• we don’t even use your straight passphrase for the SRP protocol, just as a second level of protection [1]

If you are interested in more details, please join our discussion group

[1] the full formula is srp_password = sha-d256(passphrase + username); you can find it on the source file src/js/Clipperz/PM/Connection.js, at line 503

simple question - simple YES / NO appreciated! I imagine (not an expert) the answer is YES but only through Brute Force?

Dear Sam, what about posting your question to forums and discussion groups focused on security and cryptography?

Clipperz, as any security system, is not just a collection of crypto algorithms, but it consists of many other components including the users!

Therefore it would be very interesting to have more people with different skills answer your question. However I doubt it could a yes/no answer.

Thanks, Marco

Thanks for the response Marco although you didnt really answer my question ;) - frankly I am an “average user” thus have no interest in exploring the in-depth nature of cryptography on various forums - most of your users will be like me! I am however interested in using Clipperz and would expect you to have a view on my question rather than tell me to go elswhere since YOU are asking for my passwords.

Asking around, I believe this like really anything can be cracked - probably at present through brute force and wouldnt be worth the effort if someone did manage to get a hold of your severs. This to me seems an acceptable level of risk and is not something you should be afraid of explaining to your users!

All the best Sam

Dear Sam, we are not asking our users to trust us, but to check for themselves or ask the community of security experts.

This is why I did not answer your question, after all every seller praises his wares, so my answer wouldn’t be of any help …

We believe Clipperz is a strong cryptographic system that can greatly enhance the security of its users (otherwise I would never ask your passwords and confidential data).

That said, even if you are an average user you should put more values in a third party evaluation of Clipperz than in any declaration from its developers.

Regards, Marco

I love the Clipperz service.

My questions has to deal with continued availability. If I spend a bunch of time to input data into the system, how can I ensure that the service will be there a year from now? Obviously, I can download a local copy regularly to protect myself.

Here’s the deal. Clipperz doesn’t have contact information for it’s users. This is a real selling point of the service.

As a result, there is no way for Clipperz to send out an email warning users that the service is going away and to instruct people to pull down their data.

One idea might be to allow users to subscribe to some sort of company news list, which is separate and apart from the user list. This might be confusing to people.

We are perfectly aware of this communication issue; this is why we have set up a forum even before starting advertising the service.

We encourage all our users to subscribe to the forum, as it is a nice way to keep up to date with the evolution (and sometimes also shortcomings) of our service.

It is highly patrolled (even if we are only a two guys shop, we really care about our users), and you can see by yourself the rate and responsiveness of our replies.

But we have also other options to keep our users updated.

We are now investigating how to notify our users of relevant updates through the application itself, but we are very careful about it as we really don’t want to weaken the security of the application doing it.

Hope this addresses some of your concerns.

I’m just getting into using Clipperz and find the anonymity and ‘zero-knowledge’ aspect really appealing. However, as I am not technically-minded enough to understand all the cryptograhic aspects of the site can you reassure me on something? When I use Clipperz on my PC at home I understand that all the confidential information is encrypted by my browser. That’s fine. However, how secure is this when I using, say, a PC in an Internet Cafe or my local Public Library? In such situations it is not ‘my’ browser…

Hoping you can put my mind at rest! btw- I prefer your site to PassPack!

Dear Paul,
thanks for your kind words!

When accessing Clipperz from a public PC, I would recommend the following measures:

1. Avoid using any installed browser by bringing with you Portable Firefox, launch it from your USB drive or iPod.

2. Sign in to Clipperz using a one-time passphrase and not your regular passphrase. (this long-awaited feature will be released next week!)

And, if the untrusted PC does not have an Internet connection, move to the USB drive also your offline copy.

best regards,
Marco

i understand that the reason for not opening code is the great opportunity to make some money and obviously need for some payoff for all the resources and work which you put into the development…

is there any other reason which you found for not publishing all the code under gpl?

Sorry, but I can not understand who could benefit from our code being released under GPL licence.

Could you share some interesting cases that are not achievable with the current license, but would be possible using a GPL licence?

by manipulating the DOM, it was easy to override the locking (by simply removing the elements off the page). The “Nuke anything” extension for firefox makes this a 5 second job.

The current implementation of the locking feature is very “thin”, security wise.

This is one of the reasons we have not implemented yet an auto-lock in the main interface (the compact version, if used in a sidebar, is somewhat more secure, as the browsers plug-ins can not access its content as easily; nothing rock solid, but a little more secure).

We are aware of this weakness, and we are planning for a much more solid solution in a future release of the application.

PS: thanks for the pointer to the interesting Firefox plug-in.

When I download index.html to my computer, I must enter passphrase in order to access the data. Therefore, this passphrase must be checked against something. And this “something” must be included in the index.html, which is downloaded from the server.

How does server know what to check, if it never receives the passphrase?

Sorry if this is obvious, but I’m really stuck :)

Thanks, Aleksey.

Aleksey,

first let me fix a wrong assumption you wrote in your comment:

this “something” must be included in the index.html

This is not correct. The index.html file is a static file, and it is the same for everybody. No personal information is stored in it; this is not the case for the offline version, but I don’t think this is relevant for the moment.

Your credentials are compared with some data stored on the server, but thanks to the SRP protocol we can achieve this without sending the passphrase itself to the server. Only derivate values are transmitted; if you like some algebra, look here.

A bit of questions: - Does Clipperz allow me to delete my account later? - If yes, will Clipperz delete every information in my account?

Sorry if these are already covered, I am just a bit concerned to even try Clipperz if I don’t have the answers to these questions. Thanks.

You need to go to “account” -> “delete your account”.

We ask for your username and passphrase (just to be sure that is not somebody else trying to delete your account left open on your computer) and we will delete everything from our online DB, access history included.

The only data left will be the one on the backups.

I see. Thanks for the answer. :)

Am I right, that if you want to, you could change your JS and your checksums and you get all the passwords from every user enters its registration data?

The short answer is YES; we could change the JS in order to collect all our users’ username and passphrase.

What we are hoping is going to happen, is that as soon as the checksum changes, someone will compare the current version of the application with the previous one (we have all the code of all the different versions of the application readily downloadable) and check that the changed code will do no harm to the security of the whole system.

Keeping all the version always available also allow anybody to check if in the past we have tried to do scary things.

We perfectly understand that not everybody will be able to perform an accurate assessment of the code; but it will be enough for just a single person to find a problem, for the whole project to be immediately dismantled.

I don’t know if this is a sound enough answer to your question, but we have no other definitive answer right now.

I’m currently a Passpack user and I guess I chose Passpack over Clipperz partly because of the double data security - one password to get the data and another to unpack it. I’m starting to wonder if this really improves security (much) … Could you please comment on this?

Off-topic: I assume Clipperz isn’t supporting HTTP Basic Auth yet - at least that is the biggest drawback for me when using Passpack. Do you have any plans to do so or any ideas on how to do it?

@ Hans Frederik

I cannot comment on Passpack’s implementation because the source code is not available, at least not in an intelligible form. The authentication protocol where the first password is used is not known to me. Similarly I have no info about the key derivation algorithm that processes the second password.

I can only say that remembering one long and strong password is easier then remembering two long and strong passwords. :-)

HTTP Basic Auth is definitely supported by Clipperz! You can easily have a 1-click login to any web site that uses HTTP Auth. There is a dedicated tool to quickly create such a link.

Marco

I am trying to understand the implementation of clipperz. From what I have read so far, it looks like the data stored in clipperz is encrypted with a key derived from passphrase.

It leads me to conclude that the data will be communicated over open channel in the same form as long as I do not change the passphrase. I believe for communication based on symmetric encryption, the encryption key should be created for each session.

Please correct me if I have made wrong assumption. I think clipperz is a cool idea.

The index card is encrypted with a password derived from the passphrase, correct.

Data are transmitted through an SSL connection, but in any case you are correct that the data will always be the same as long as the passphrase is not changed (or any data is updated, as in this case also the index card is completely updated).

We could use the SRL shared secret key (derived independently from the two parts during the authentication phase) to further encrypt the exchanged data, but this would make the whole process much slower (at least on the client side).

Is zero-knowledge a type of anonymization?? what is the difference betwwen it and anonimity??

Thanks..

Hi,

you can read more about the zero-knowledge architecture here: Anatomy of a zero-knowledge web application.

Ok.. where to begin… this might be a little harsh..

This website uses a lot of techniques that are not approved by me.

For one, the hash algorithm “Double SHA-256”. Why not use HMAC-SHA256? It requires the same computation power as what they are doing and is much stronger.. also their documentation of their hash algorithm states that there is some weakness in the SHA-2 family which exists for SHA-1 not SHA-2.. do they know what they are talking about?

The question comes up ‘do they know what they are talking about?’ even more on their ‘When 128 bits are not enough to protect your passwords’ blog post. They talk about AES-256 only providing 128 bits of security. WHAT? umm excuse me but there is no published attack on AES that will reduce its complexity from AES-256 to 128 bits. And if there was, it wouldn’t have the name ‘Advanced Encryption Standard’ And im sorry but CTR mode is the worst choice for this application, no it doesn’t theoretically decrease the security of the website, CBC would be a better choice, and just as easy to use.

The SRP is total bullshit. All you have to do is use a secure key derrivation algorithm to create the key from the password. This could be accomplished safely with something as simple as a SHA-256 hash. SRP is just used so they can add a bullet point to this page to make it sound better, and to make their software bloated. For the key derrivation in my soon to be released open source password manager i XOR togeather the halfs of a Whirlpool HMAC and a SHA-512 hmac to create a 256 bit key.

The random number generator that they use, why not just use AES or some hash function?

I don’t even want to read the ECC and SSSS documents. My advice for your new public key feature: use standard RSA public key crypto

My background: I am 16 years old, very paranoid, and have programmed my own password manager in PHP and mysql. Cryptography is my passion, and i do agree that this website is secure, but their documentation lacks a certain knowledge of cryptographic functions..

This is the perfect way to wrap up this comment (copy pasted from this page):

Anon: Is the same password used when logging in at clipperz.com as is used when encrypting the data locally?

Reply from Giulio Cesare:

The short answer is “no”.

The long answer is too long to be tell on a comment, but I will try to point out the main elements:

…

My response on my website would be:

Yes, your passwords are encrypted on the server with a 256 bit key derived from your password. They are then sent over a TLS encrypted connection to your browser, If you do not trust the server you can use the option of encrypting your passwords with JavaScript, or you can download the source code and host your own.

I’m not trying to advertise my website (That is why i have not included a URL in the comment) I’m just expressing my opinion

~FireXware

To more clearly explain my point of why I don’t trust it. It is too complicated for what it needs to be. It’s using all of these advanced features that do not provide any more security then the simple way of doing them. The enemy of security is complexity.

In response to:

Anon: Is the same password used when logging in at clipperz.com as is used when encrypting the data locally?

I really have no idea what they are doing, but if it requires more space then a comment to explain it is too complicated. All that needs to be done is for the JavaScript to HMAC the password with the server’s HMAC key, send that to the server for authentication, and derive the key from an HMAC of the password with a different key. In fact to prove how simple this would be, here is the source code in PHP:

//a more secure way to create a key from a password, 
//uses HMAC-SHA512 and HMAC-WHIRLPOOL xored into a 256 bit key returned in hex
//this type of hash is not needed for authentication as SHA256 is strong enough
public static function makeKey($password, $hmacKey)
{
    //W - the respective byte of the whirlpool hmac
    //S - the respective byte of the SHA512 hmac
    //each line is an XOR
    //|WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW|
    //|WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW|
    //|SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS|
    //|SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS|

    $whirlpool = hash_hmac('whirlpool', $password, $hmacKey, true);
    $sha512 = hash_hmac('SHA512', $password, $hmacKey, true);
    $key = '12345678901234567890123456789012'; //32 character key
    for($i = 0; $i < 32; $i++)
    {
        $key[$i] = chr( ord($whirlpool[$i]) ^ ord($whirlpool[$i+32]) ^ ord($sha512[$i]) ^ ord($sha512[$i+32]));
    }
    return bin2hex($key);
}

After reading your documentation on everything else. My advice: keep it simple, have the Javascript delete any passwords in plaintext from memory, that way the password is required no matter what to decrypt the ciphertext again… It’s nothing complicated and that would allow the NSA to have access to the memory of the browser and they wouldn’t be able to decrypt it without brute forcing the password. This would break the OTP feature so why not just re-authenticate? If you need authentication without fully re-authenticating, just HMAC the password and check against the HMAC of the password they provide when they unlock it. Sorry for telling you how to code your own software lol no offence :P