Не надеюсь на ответ, но спрошу на всякий случай.

Мне надо зашифровать id пользователя форума ips таким образом чтобы:

1 шифрованный текст был не более 64 символов.

2 шифровался и расшифровывался при помощи пароля

3 id надо обязательно посолить

4 не создавать баз данных типа хэш / id

Надо это для обмена данными между сайтом и платежной системой. Не хочу передавать ей id или ник в открытом виде.

Так вот при использовании стандартных средств php(SSL), шифрованный текст от трехзначного числа получается длиной более 80 символов, а если еще посолить, то там и вовсе заоблачные цифры получаются. Требование платежной системы 64.

Можно конечно хешировать id, но тогда придется создавать базу данных id/соль/хэш, что очень не желательно и не дай бог где нибудь коллизия выплывет.

 

Кто что может посоветовать старику?

 

Edited 2 мая, 20195 yr by aplayer

6 минут назад, aplayer сказал:

Не надеюсь на ответ, но спрошу на всякий случай.

Мне надо зашифровать id пользователя форума ips таким образом чтобы:

1 шифрованный текст был не более 64 символов.

2 шифровался и расшифровывался при помощи пароля

3 id надо обязательно посолить

4 не создавать баз данных типа хэш / id

Надо это для обмена данными между сайтом и платежной системой. Не хочу передавать ей id или ник в открытом виде.

Так вот при использовании стандартных средств php(SSL), шифрованный текст от трехзначного числа получается длиной более 80 символов, а если еще посолить, то там и вовсе заоблачные цифры получаются. Требование платежной системы 64.

Можно конечно хешировать id, но тогда придется создавать базу данных id/соль/хэш, что очень не желательно и не дай бог где нибудь коллизия выплывет.

 

Кто что может посоветовать старику?

 

Может к профилю добавить дополнительное поле, типа второй id с хешем? 

1 минуту назад, accop сказал:

Может к профилю добавить дополнительное поле, типа второй id с хешем?

Нет. Проще тогда отдельную таблицу в бд создать.

Я хочу избежать накопления данных, а еще пароль в отличие от данных можно периодически менять. Данные же надо будет каждый раз накапливать и пересоздавать новые

 

1 минуту назад, aplayer сказал:

Нет. Проще тогда отдельную таблицу в бд создать.

Я хочу избежать накопления данных, а еще пароль в отличие от данных можно периодически менять. Данные же надо будет каждый раз накапливать и пересоздавать новые

 

Не понимаю, а как ты хочешь сделать?

Тогда не заполняй столбец с новым ID+хеш пока не понадобиться или очищай через N время, создавая такой ID только на время передачи данных.

1 минуту назад, accop сказал:

Не понимаю, а как ты хочешь сделать?

Шифрование и расшифровка при помощи пароля.

Вы знаете как работают http-запросы или api платежных систем?

Данные запаролили и отправили в платежку. Платежка возвращает эти же самые данные которые мы ей отправили и дополнительно сообщает, что платеж прошел или не прошел.

Мы данные получаем, с тем же самым паролем расшифровываем и обрабатываем их дальше.

Таким образом платежка не будет знать, какой именно пользователь провел платеж.

При этом не создается никаких баз данных. Все шифруется и расшифровывается налету.

Вот если бы не было ограничений по количеству символов, то было бы все просто замечательно.

3 минуты назад, aplayer сказал:

Данные запаролили и отправили в платежку. Платежка возвращает эти же самые данные которые мы ей отправили и дополнительно сообщает, что платеж прошел или не прошел.

 

40 минут назад, aplayer сказал:

шифровался и расшифровывался при помощи пароля

А если он пароль поменяет, то всё уже платёж не вернётся или потеряется, а вот с id такой штукой бы не было. Или это какой-то другой пароль? 

 

1 минуту назад, accop сказал:

А если он пароль поменяет,

пароль будет только у меня и менять буду только я.

Эти данные являются удостоверяющей меткой. Я ей метку отправляю, а она мне сообщает, что эта метка совершила платеж или не совершила. И ей абсолютно по барабану какие данные я ей присылаю.

Соответсвенно если пользователь платит, то лучше всего отсылать его id в зашифрованном виде.

1 минуту назад, aplayer сказал:

пароль будет только у меня и менять буду только я.

Эти данные являются удостоверяющей меткой. Я ей метку отправляю, а она мне сообщает, что эта метка совершила платеж или не совершила. И ей абсолютно по барабану какие данные я ей присылаю.

Соответсвенно если пользователь платит, то лучше всего отсылать его id в зашифрованном виде.

Тогда просто придумать алгоритм, который будет шифровать id юзера по твоему паролю и всё. 

1 час назад, aplayer сказал:

Мы данные получаем, с тем же самым паролем расшифровываем и обрабатываем их дальше. 

"Платежке" нахрен не сдалось знать какой именно пользователь на каком-то сайте произвел платеж (а может там вообще пользователи как таковые отсутствуют ). Биллингу как и самому форуму обычно достаточно только уникальный ид транзакции, где в базе по нему есть все данные. Это вообще не является обязательным полем для платежной системой.

4 часа назад, siv1987 сказал:

"Платежке" нахрен не сдалось знать какой именно пользователь на каком-то сайте произвел платеж

Это понятно. Но конфиденциальность надо соблюсти. А вдруг пользователь пожалуется что я его ид передаю третьим лицам. 

Да и сама платёжка наверняка будет долго хранить эту метку в своих базах. 

5 часов назад, accop сказал:

Тогда просто придумать алгоритм, который будет шифровать

Детские алгоритмы шифрования взламывали на ура ещё во времена когда компьютеров не существовало. Даже более современные алгоритмы которые лет 5 назад считались устойчивым, сегодня уже сломаны. Вряд ли в мире существует алгоритм шифрования лучше чем те, что имеются в php 7х на библиотеке opеnssl. Но у них с длиной символа не все в порядке. 

Вот я и спрашиваю может кто знает как на openssl библиотеке обратимое зашифровать текст чтобы шифрованный не превышал 64 символа. 

10 часов назад, aplayer сказал:

А вдруг пользователь пожалуется что я его ид передаю третьим лицам. 

Лол. А завтра он пожалуется что его ID видно в ссылке и любое "третье" лицо может его увидеть.

Не занимайтесь фигней, никакой алгоритм шифрования тут не нужен. Ид пользователя не является обязательным параметром для платежной процессора. Беспокоит конфиденциальность - не указывайте. Все данные платежного поручения для форума можно восстановить по ид транзакции.

siv1987 с таким же успехом можно сказать, что https тоже не нужен, он только зря процессор греет. Нам же нечего скрывать, информация и так вся является открытой итп.

А еще я не использую приложение коммерции, там нет необходимого мне функционала. Плюс сколько жалоб на различные баги этого приложения и отказ в работе. Плюс иностранные платежные системы которые не принимают наши сберкарты МИР.

@Respected даю вам 24 часа на скрытие моего ID, иначе я подам в Гаагский суд Пресненского района Москвы за нарушение моих персонально-конфиденциальных данных 

По теме: https://ru.wikipedia.org/wiki/Конфиденциальность#Конфиденциальность_в_России 

По ID ничего, кроме профиля пользователя посмотреть нельзя, ни о каких секретных или тайных данных говорить не приходится. Да и метки эти вряд ли кассы сохраняют, нужны им лишние бесполезные данные