Jump to content
aplayer

Вопрос о шифровании

Recommended Posts

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

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

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

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

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

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

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

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

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

 

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

 

Edited by aplayer

Share this post


Link to post
Share on other sites
6 минут назад, aplayer сказал:

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

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

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

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

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

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

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

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

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

 

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

 

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

Share this post


Link to post
Share on other sites
1 минуту назад, accop сказал:

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

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

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

 

Share this post


Link to post
Share on other sites
1 минуту назад, aplayer сказал:

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

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

 

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

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

Share this post


Link to post
Share on other sites
1 минуту назад, accop сказал:

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
3 минуты назад, aplayer сказал:

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

 

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

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

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

 

Share this post


Link to post
Share on other sites
1 минуту назад, accop сказал:

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

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

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

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

Share this post


Link to post
Share on other sites
1 минуту назад, aplayer сказал:

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

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

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

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

Share this post


Link to post
Share on other sites
1 час назад, aplayer сказал:

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

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

Share this post


Link to post
Share on other sites
4 часа назад, siv1987 сказал:

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites
10 часов назад, aplayer сказал:

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×