Passpack online password store

Wilbertnl,

do you confirm that also the zip file downloaded with FireFox is corrupted?

 

I downloaded the Clipperz_20070426.zip today and it seems alright.
Don't pull your hair: also Internet Explorer downloads a correct zip file, today.



Windows zipfolder wants a password when I try to extract, but I can drill into the file without problems.
Also winRAR 3.51 opens it fine.

 

I am "lucky", as I have very few hair to pull! ;-)

I think the Windows zipfolder tool gets triggered by the UTF-8 charset used on the index.html file, and thinks it is password protected. Using WinZip we never had this issue.

Now that you can see your own data as stored by Clipperz, I would really appreciate any comments!

BTW: the application is still the same as yesterday; it is even the same exact instance running since the 26th of April. I really can not understand how your previous files could be corrupted. :-(

Did you change some of the data stored in your Clipperz account (thus changing the content of the ZIP file too) between the different tries, or your data have always been the same?

 

Here is the code of my card.
Anyone cares to crack my password?
ErikAlbert perhaps?

Code:

_clipperz_dump_data_ = {
	users:{
		'catchAllUser': {
			__masterkey_test_value__: 'masterkey',
			s: '112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00',
			v: '112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00'
		},
		'7ab6b2432ab631cee510303d9318c08cdab0d49e9907f44adda7244f5ca8740a': {
			s: '856987c59338e27f22f63d3b8ac66c275759478888029d6d6c9e9373fb7d4421',
			v: '6cf4c61044256240d3ada0b91ecc05e105d4e8f45b345264de026c8aee676932',
			version: '0.2',
			maxNumberOfRecords: '100',
			userDetails: 'ClQRceL0kMBJPHL74ySJoj8TpIZuPtu42nyvyOS8oHKiv5OWlyNFnyNyR7q0+CtDZTzdcehKBBHqK0Ob3f2d6X/rbxyjCDbriCoePxPXDDs2hNUdV5zgzUTAKrN34c+70Q+Md2thaAsiF+NM2lloaCTxdvvIQvPAHRTqzDNtxsqm8Q/B3A2SR5p6aizKh+3jP/gqQPjggqmFQHRVNDM+BuGzNl2QLWNv+CLg0YWzYoPYBMNNKVhTXv30IYzDOrBhfVISdDmi+/vU4DMlP2WNTHdjUZRNbOGeBkgW2EYsTQr6aoc4a0VIR2y5+qYYztCCodDehy3StpLad6sim9454MVyB3Epe9wzvX6+yobrp+0u1fUGy7hnmtGRWPaqyd0gU7LPsgGj5CBgInFws/f2EMKbP7H+DCyq6A==',
			statistics: 'FkDPrPMCqw7SdlZz2f1rC1wqtP6iREBW9pBHygjzQ019vkJkPgbi74JzDqQzkoBFfyg=',
			records: {
				'c8a614aa8bc21255aed7ddfa658fde81464e35793b8c4c003f56abbaf0eb056b': {
					data: 'dzP+K6PjNNN1wcVXyqmW3wbzD/70ndBGCXdfe8VAnJwj8jpPzJO0zVS5u5tbtwiZLpxkmJ5PYus1qIjhZ/Qlimb7ovc7r3N8x/6LgVifThvPIZN0w26I2Da9JQVz2U8+3Z743cM4S02Z4Ux9Oqbu0os8rHMLFjAw5lQQGk57YPY61/D3GSEfV/cA/zvpplYpmsUk6Mjgxy/rVV0=',
					version: '0.2',
					creationDate: 'Tue May 01 19:48:57 CEST 2007',
					updateDate: 'Thu May 03 16:01:29 CEST 2007',
					accessDate: 'Thu May 03 16:01:29 CEST 2007',
					currentVersion: '23b61526c47a8fc75a4b071c4522b231952809d34da6490a49f12795df015f12',
					versions: {
						'232e28b1a96d0538f881af39be8d962ba193563984dc569af6443d9ce0f19915': {
							header: '####',
							data: 'vQoUw4zO5htQp6lHIFyMq7XTM3JLgXnqR4RFmS+bfYEOOv6spioK6dzw0FZUancH/rPDcxYE7EgLRup4AZydG2SuhlqDuCzZPtZe8bWvVw8ApPDa2X/2iH3WD5lhteqeBvpb1ToeA5VQKNg9PGYuGXRnlLpCisbq5JtRFWlO01ww/FTvQD35g0zPHtdsabUxivKdn6hqKFwADX1uRZ/DPuCaSi1L7jYG6Oz/mM7kPDFlXqe30hidEocQB+2r2pCSOkyEtyvc8VOHkFCQS9WOlwO1kr3sq5kw1uYA2uSrQTJa/dhtY+upGRNOXCo67ccHqJyEvpDEXopM19au2EXKoBiLqa2k4eJFhzELo9fvdwCPxBYiSnZgVBgcu00FX729WqxIiKDD0vMn/DvPUw47Kwv7LDL+8i+MlSZbw1bv6q2eZuqm/2CtJuiyEUneou/NFF7y',
							version: '0.2',
							creationDate: 'Tue May 01 19:48:57 CEST 2007',
							updateDate: 'Tue May 01 19:48:57 CEST 2007',
							accessDate: 'Thu May 03 15:54:36 CEST 2007'
						},
						'23b61526c47a8fc75a4b071c4522b231952809d34da6490a49f12795df015f12': {
							header: '####',
							data: 'xaSJ6jbCKSg2v3Ulifx0xMeSvEeZWRa6pHkfb2UJXJkZcpRKK5TZ11CxzD3nteF0Bz2O47b5a73nwLMmi9DzjtrPG2xg8UYKIpmgxj1W3NYKTqBgdpDHDvUR77Xz+QN+1lavzK2gfbFpAkd/ZhIUi/c3SjRwfVs4uVNPc07uptgL7n6nMLy0DDzuhHaMZhT34e3Esa2RkhXDjZCaZbBNidIOYq/aig3b62g9Y+mYo5nKV6EJ7wwGvOaWBhOaOKED4BiU9L2we0FbRVEHRtjq3tByg2iqd9pYraQZ/s8XzUCsULfXowpQZb644kinMmM5TMGY4InQCiXxjoy8QKxoefLJWj2RB9WMhdfaIIH+2d2EXh1Ec6yNcV9wMgbegfebT1WSFVpic95oB1sv55wWK2Wn9LeojIh+HD7yPs/bfx3xk1EAOYfkjabOC550U8jqbev5IA==',
							version: '0.2',
							creationDate: 'Thu May 03 16:01:29 CEST 2007',
							updateDate: 'Thu May 03 16:01:29 CEST 2007',
							accessDate: 'Thu May 03 16:01:29 CEST 2007'
						}
					}
				}
			}
		}
	}
}

Clipperz.PM.Proxy.defaultProxy = new Clipperz.PM.Proxy.Offline();

 

Wilbert, I hope you don't mind if I support anyone interested in cracking your passwords answering any request on how data are structured, encoded, processed, etc... by Clipperz.

I will be happy to provide any information that could be derived looking at the code, only but with a much bigger effort.

 

Wilbernt,

looking at the data you have posted, it is evident that you have updated some of the values of the single card you have stored in Clipperz. [1]

If you have update the card to store a fake password before publishing the data to the forum, be warned that also the old value has been published.

If you fear that the data could be cracked, and the original value is relevant for you, take the appropriate action.

[1] Clipperz at the moment stores on the server all the different versions of a card detail, even if this feature is not available through the user interface, yet. When completed, each user will be able to scroll through the different versions of her own cards.

 

To take a closer look at the local version of clipperz I unplugged the computer from the internet.

Then I loaded the local page in the browser.
It looks and functions the same as the online version.





The browser whines about the script, though:

Well, I notice that it's raining today...

I have not made any changes since I created the account and the single card that would explain a succesful download today.
I did make a change after downloading the correct zip files.

Not at all!

You caught me.
I changed the password before publishing the code (but after downloading the correct zip file).
My password will only work with the Wilders Security Forums, any other site that requires a login has a unique password. And my bank accounts also have a different login names.

 

The application is just the same, online and offline. You can see it by yourself trying to download the index.html file from the online version and comparing it to the index.html file found into the downloaded ZIP: the only difference is that the downloaded version has an include statement to load the data of the dump/dump.js script.

At the end of the dump/dump.js script there is also a statement to switch the Proxy instance to use. The proxy is the lower layer of communication used by the application, and there are two subclass of the abstract proxy class: DWRProxy and OfflineProxy.
The first collects (and updates) the data online using the DWR library, while the second simply passes the data found on the dump/dump.js script to the upper layers of the application.

This happens when the browser takes too long to process a script. Encrypting and decrypting data could be very heavy on Javascript, but it should not happen with a single card (with more cards it is much more frequent).
If your computer was heavily loaded (also by other tasks), this warning could spring more often.

This is somehow refreshing, but still very puzzling.

:-D

 

Now that you have added your Wilders Security Forums account to Clipperz, you should really try to configure a direct login [1] for it, and feel the convenience of connecting and getting authenticated to the forums with a single click.

The first time you configure a Direct login the procedure may look a little bit convoluted, but simply because it requires some uncommon tasks to be performed. In the end it is really very simple. though.


[1]: http://www.clipperz.com/support/step_by_step/direct_login

 

I installed the bookmarklet, and went to the login page:



I added the direct login:



But the test result is this:



What do you think?

 

Is it possible that in the card you still have the faked password you have changed before uplading the data to the forum?

The bookmarklet reads the field values pre-populated by the browser, but uses them only when creating a new card; when adding a direct login configuration to an existing card, the field values are left untouched.

There are some sites where our Direct login does not work, but this forum is not one of them, as I am using a direct login myself to access it without any issue.

Update: thinking better at it, I have run my bookmarklet on the front page of the forums, not on the login page like you have done. This should not make any difference, but if the problem was not the wrong password, I will investigate it further later on.

Update 2: I had to go home, but could not resist. I have tried to run the bookmarklet from the same page you have used (looking at the url of the picture my best guest was that you hit the reply button to a post without being logged in), created a new direct login configuration, and it worked painless.
This just to confirm that the page where you have ran the bookmarklet should not be an issue.

 

You are right on that, I corrected the password in the card and now the direct login is working and smiling!
Edit: It also works from the updated download.

 

Here the annotated structure of the data posted by Wilbertnl, in order to support anyone interested in trying to break it.

Code:

_clipperz_dump_data_ = {
	users:{
		'catchAllUser': {
			__masterkey_test_value__: 'masterkey',
			s: '112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00',
			v: '112233445566778899aabbccddeeff00112233445566778899aabbccddeeff00'
		},
[1]		'7ab6b2432ab631cee510303d9318c08cdab0d49e9907f44adda7244f5ca8740a': {
[2]			s: '856987c59338e27f22f63d3b8ac66c275759478888029d6d6c9e9373fb7d4421',
[3]			v: '6cf4c61044256240d3ada0b91ecc05e105d4e8f45b345264de026c8aee676932',
[12]			version: '0.2',
			maxNumberOfRecords: '100',
[4]			userDetails: 'ClQRceL0kMBJPHL74ySJoj8TpIZuPtu42nyvyOS8oHKiv5OWlyNFnyNyR7q0+CtDZTzdcehKBBHqK0Ob3f2d6X/rbxyjCDbriCoePxPXDDs2hNUdV5zgzUTAKrN34c+70Q+Md2thaAsiF+NM2lloaCTxdvvIQvPAHRTqzDNtxsqm8Q/B3A2SR5p6aizKh+3jP/gqQPjggqmFQHRVNDM+BuGzNl2QLWNv+CLg0YWzYoPYBMNNKVhTXv30IYzDOrBhfVISdDmi+/vU4DMlP2WNTHdjUZRNbOGeBkgW2EYsTQr6aoc4a0VIR2y5+qYYztCCodDehy3StpLad6sim9454MVyB3Epe9wzvX6+yobrp+0u1fUGy7hnmtGRWPaqyd0gU7LPsgGj5CBgInFws/f2EMKbP7H+DCyq6A==',
[5]			statistics: 'FkDPrPMCqw7SdlZz2f1rC1wqtP6iREBW9pBHygjzQ019vkJkPgbi74JzDqQzkoBFfyg=',
			records: {
[6]				'c8a614aa8bc21255aed7ddfa658fde81464e35793b8c4c003f56abbaf0eb056b': {
[7]					data: 'dzP+K6PjNNN1wcVXyqmW3wbzD/70ndBGCXdfe8VAnJwj8jpPzJO0zVS5u5tbtwiZLpxkmJ5PYus1qIjhZ/Qlimb7ovc7r3N8x/6LgVifThvPIZN0w26I2Da9JQVz2U8+3Z743cM4S02Z4Ux9Oqbu0os8rHMLFjAw5lQQGk57YPY61/D3GSEfV/cA/zvpplYpmsUk6Mjgxy/rVV0=',
					version: '0.2',
					creationDate: 'Tue May 01 19:48:57 CEST 2007',
					updateDate: 'Thu May 03 16:01:29 CEST 2007',
					accessDate: 'Thu May 03 16:01:29 CEST 2007',
[8]					currentVersion: '23b61526c47a8fc75a4b071c4522b231952809d34da6490a49f12795df015f12',
					versions: {
[9]						'232e28b1a96d0538f881af39be8d962ba193563984dc569af6443d9ce0f19915': {
							header: '####',
							data: 'vQoUw4zO5htQp6lHIFyMq7XTM3JLgXnqR4RFmS+bfYEOOv6spioK6dzw0FZUancH/rPDcxYE7EgLRup4AZydG2SuhlqDuCzZPtZe8bWvVw8ApPDa2X/2iH3WD5lhteqeBvpb1ToeA5VQKNg9PGYuGXRnlLpCisbq5JtRFWlO01ww/FTvQD35g0zPHtdsabUxivKdn6hqKFwADX1uRZ/DPuCaSi1L7jYG6Oz/mM7kPDFlXqe30hidEocQB+2r2pCSOkyEtyvc8VOHkFCQS9WOlwO1kr3sq5kw1uYA2uSrQTJa/dhtY+upGRNOXCo67ccHqJyEvpDEXopM19au2EXKoBiLqa2k4eJFhzELo9fvdwCPxBYiSnZgVBgcu00FX729WqxIiKDD0vMn/DvPUw47Kwv7LDL+8i+MlSZbw1bv6q2eZuqm/2CtJuiyEUneou/NFF7y',
							version: '0.2',
							creationDate: 'Tue May 01 19:48:57 CEST 2007',
							updateDate: 'Tue May 01 19:48:57 CEST 2007',
							accessDate: 'Thu May 03 15:54:36 CEST 2007'
						},
[10]						'23b61526c47a8fc75a4b071c4522b231952809d34da6490a49f12795df015f12': {
							header: '####',
[11]							data: 'xaSJ6jbCKSg2v3Ulifx0xMeSvEeZWRa6pHkfb2UJXJkZcpRKK5TZ11CxzD3nteF0Bz2O47b5a73nwLMmi9DzjtrPG2xg8UYKIpmgxj1W3NYKTqBgdpDHDvUR77Xz+QN+1lavzK2gfbFpAkd/ZhIUi/c3SjRwfVs4uVNPc07uptgL7n6nMLy0DDzuhHaMZhT34e3Esa2RkhXDjZCaZbBNidIOYq/aig3b62g9Y+mYo5nKV6EJ7wwGvOaWBhOaOKED4BiU9L2we0FbRVEHRtjq3tByg2iqd9pYraQZ/s8XzUCsULfXowpQZb644kinMmM5TMGY4InQCiXxjoy8QKxoefLJWj2RB9WMhdfaIIH+2d2EXh1Ec6yNcV9wMgbegfebT1WSFVpic95oB1sv55wWK2Wn9LeojIh+HD7yPs/bfx3xk1EAOYfkjabOC550U8jqbev5IA==',
							version: '0.2',
							creationDate: 'Thu May 03 16:01:29 CEST 2007',
							updateDate: 'Thu May 03 16:01:29 CEST 2007',
							accessDate: 'Thu May 03 16:01:29 CEST 2007'
						}
					}
				}
			}
		}
	}
}

[1] This is the 'C' (aka 'username') parameter of the SRP protocol. In order to achieve complete anonymity, Clipperz computes this value as sha-d256(username + passphrase). Here, username and passphrase are concatenated as strings, and converted to a byte array using the UTF-8 encoding. The resulting byte array is processed twice with the sha256 function (aka sha-d256), and the result is encoded in a hex string.

[2] This is the random seed required by SRP encoded as an hex string.

[3] This is the checksum value derived by the SRP password. In order to grant some added safety in case the SRP protocol could be broken, instead of using the plain Clipperz passphrase as SPR password (used to compute the derived value 'v'), Clipperz compute the SRP password as sha-d256(passphrase + username).

[4] This is the core of the all data: the "index card". This is the meta-record containing all the keys of the other cards/records ("card" is the UI name, while in the code the same entities are called "records"). The meta-records contains the references (32-byte random values) of each record created; and for each record it contains the name of the record (label), the "key" used to encrypt the record content (a 32-byte random value) and the notes (this value will be soon moved to the record itself, in order to reduce the ammount of data to decrypt upfront, when logging in.
Other than the record index, also the direct login index is stored here (but wilbertnl had no direct login configured) and the user preferences (at the moment only the choosed language value is stored here, but I think it could be quite safe to suppose it empty in this sample data).

The json representation of the meta-record data are encripted using the AES256 algorithm, using the passphrase as key. The result is encoded in base64.
To be extra-detailed, the key used by AES is the "normalized" key computed as sha-d256(passphrase); both the passphrase and the meta-record serialized data are encoded as UTF-8.
The AES algorithm is used in CRT mode, and the first 128-bits are the representation of the random nonce value used to bootstrap the processing.

The content of the meta-record looks like this:

Code:

{"records":{"c8a614aa8bc21255aed7ddfa658fde81464e35793b8c4c003f56abbaf0eb056b":{"label":"Wilders Security Forum", "key":"__________a_32_byte_random_value_encoded_as_hex_string__________", "notes":""}}, "directLogins":{}, "preferences":{}}

[5] This is basically a place holder at the moment, no relevant information are stored here. The clear text of this field is the empty object JSON representation ("{}") and it is processed just like the "userDetails" field detailed in point [4].

[6] This is the key of the first (and here also only) record; this is the same value also used inside the meta-card as reference to the record.

[7] This are the basic data of the record. The value (and definitions) of the fields are stored in the "versions" in order to keep track of all the changes made to the the card data (this feature is not yet available in the UI, but the versioned data are already stored on the server).

In this case, the clear-text content of this value looks like this:

Code:

{"currentVersionKey":"__________a_32_byte_random_value_encoded_as_hex_string__________", "directLogins":{}}

The currentVersionKey is the key used to encrypt the data of the current version, whose reference is stored (in clear) in the field [8].

The serialized data are processed just the index card [4], but using the record own key found in the index card itself.

[8] The reference of the record's current version reference

[9] The reference of the version; this is not the current one as its value does not match the value [8]

[10] The reference of the record's current version.

[11] The version data is processed just like the other encripted values, only using its own encrypting key, stored in the record detail [7].
The clear text of the version data looks like this:

Code:

{"fields":{"__________a_32_byte_random_value_encoded_as_hex_string__________":{"label":"User Name", "value":"wilbertnl", "type":"TXT", "hidden":false}, "__________a_32_byte_random_value_encoded_as_hex_string__________":{"label":"Password", "value":"________", "type":"PWD", "hidden":true}}}

The two 32-byte random values are the references to the two fields; these values are not used at the moment, but the are quite handy when defining the bindings between the direct login form fields, and the card fields.

Looking carefully at this data, I have came to a sad realization. The version data (for all versions other than the very first one) should had have a reference to the previous version together with the key of the previous version. I don't know why, but this data are not stored, and thus the key to the previous versions are lost. The code to compute this data is there, but missing any option to really use the outcome, this bug surveyed longer than expected.

[12] Connection protocol version to use to authenticate this user. All the other version values are a reference to the encripting algorithm used to process the data.

I understand that this is not an easy reading, but if you are willing to read through it and need some more help in understanding this data, just let me know.