Java script encryption (long question)

Question

Information Security

Or flash. Or Silverlight. Or something else, but on the client side. It happens?

Prelude:
The whole question is: there are 10,000 stores. For practical purposes, they want to exchange information about purchases, on the subject of “do you have a buyer like that?”. There is a single center that will conduct comparisons. But none of the participants in the network will trust either the center or each other. No one wants to hand over specific data about their customers. Then the thought arises: each store separately calculates the hash for all fields (customer name, card number, address ...) and merges them into one single center, from where it is informed that someone else has the same on the network. This, in theory, solves the problem of trust.

Act:
It is possible to calculate the hash on the server side, this will remove the problem, but the implementation of such a mechanism requires the intervention of programmers. And out of 10,000 participating stores, the vast majority do not have such an opportunity, or it seems to them too crap. They would like to have something like a Google Analytics checkout code, which is relatively easy to embed, but which would still not transfer the buyer's data in clear form to the center, because they still do not trust the center.
Here it seems to me that, in principle, this can be done (we do not take into account the cumbersomeness of the script so far). In total, the first part of the question, asked for the sake of form: do I understand correctly, is it possible?

The hard part:
How to be with authorization? If all-all-all hashing is done on the client side, then how to make it so that an outside attacker could not push fake data into the system on behalf of one of the stores? At the same time, without touching (or minimizing) the executable scripts on the server side of the store.

Household explanation: here you have a store on Yahoo Store. Yaha does not allow you to touch their servers. Java script can be entered in the checkout page. But no more. And you have to live somehow.

Answer 1

You can implement some hashing algorithm (md5, sha1, etc ). But: if the script has access to all the information that needs to be encrypted, then without analyzing the script it will not be possible to tell if it sends all this in clear text. In addition, in order to provide the script with information about the user's name, card number and address, all this will still have to be retrieved from somewhere in the database on the server. And this is work with the server part.
Read . Perhaps it would be better if all the user definition logic lies with you, and the client only needs to connect the script.

Answer 2

Imagine how everything will be simplified if there is a server that everyone will trust.
And so "dead souls" can be sent in batches to the center.

Answer 3

Hashes, md5 and sha1: pajhome.org.uk/crypt/md5/
Symmetric 3DES: www.tero.co.uk/des/test.php
Asymmetric RSA: www.ohdave.com/rsa/
that's all for the soul .
ps. I didn’t understand your idea (what do you want, why merge the data, who needs it, who can be trusted and who can’t?), but from the means, I think this is completely everything that may be needed.

Answer 4

Оценивая пространство номеров выпущенных банковских карт в 26 бит, фамилий — в 13 бит, имен — в 13 бит (добуквенно с карты, чтобы не было проблемы опечаток)) получаем около 52 бит. Учитывая, что для проверки соль должна быть единой для всей системы, выявляется угроза построения радужных таблиц для вашей системы.
Если же добавлять адрес, возникает множество проблем с опечатками.
Возможно, добавление expiration date и дня рождения покупателя (трудно ввести эти показатели ошибочно) перекинет множество значений за вычислимый предел, но все таки опасные значения будут очень близко («на грани»).
Угрозу вброса фальшивых данных от магазина-участника системы или от стороннего злоумышленника не вижу — при пространстве хеш-функции в 128-256 бит у него не хватит возможностей «навбрасывать» до реальной коллизии.

Answer 5

It would be possible with the help of javascript to calculate the hash for the required fields, and send it to the center, which will analyze and compare these hashes.
In order for an attacker to “not be able to shove false data into the system on behalf of one of the stores,” it would be possible to sign the hashes sent with the store’s private key. But if you do it all with javascript, then the key will have to be stored in a place accessible from the javascript, which means that any of the buyers with FireBug can get the private key for signing.

Answer 6

In order for an attacker to “not be able to push false data into the system on behalf of one of the stores”, it is better to use client certificates - it is convenient for the user and no development is needed - access restriction works at the browser and web server levels.

Answer 7

The hard part:
How to deal with authorization? If all-all-all hashing is done on the client side, then how to make it so that an outside attacker could not push fake data into the system on behalf of one of the stores? At the same time, without touching (or minimizing) the executable scripts on the server side of the store.

This is not the hard part. This is the main reason not to do such a stupid thing.
The code on the client is open with all the ensuing consequences.

Answer 8

It's not about collision. If the script is visible in its entirety, then the villain takes it and places it on his server with high traffic. Only now it does not feed it with variables from the checkout page, but generates data. Now, when visiting a page with such a mine, the script enters the visitor's browser, calculates the hash and sends it to the center. Quietly calmly loaded a bunch of left records in the center.