Форум PHP программистов > Обратимая шифровка текста.

exotica

4.11.2013 - 23:53

Тогда тебе необходимо, просто жизненно важно отойти от порядкового ИД дающегося в базе, и давать пользователям отдельный Идентификатор... Иначе можешь нарваться на очередные больные грабли. вот есть у тебя 1000 юзеров в базе, а часть из них бац и удалится, или хакнут или еще что, мало ли. останется допустим 870 из 1000. А это значит что у тебя 130 пустых ИД, и при пересчете таблицы, 130 пользователей получат другой primary_key и больше не увидят своей переписки.

Обрати внимание на то что такие данные как ID (primary) или Дата могут быть видоизменены и данные могут быть утеряны

я бы предложил использовать "ключем" хэш строку пароля пользователя, в этом есть свои плюсы:

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

_____________
[FAQ]Регистрации пользователей, сохранение в БД
---------------------------------------------------------------------------
Выходя из ванной, вышел из нее два раза

lop_atin

5.11.2013 - 00:30

Цитата (exotica @ 4.11.2013 - 23:53)

Тогда тебе необходимо, просто жизненно важно отойти от порядкового ИД дающегося в базе, и давать пользователям отдельный Идентификатор... Иначе можешь нарваться на очередные больные грабли. вот есть у тебя 1000 юзеров в базе, а часть из них бац и удалится, или хакнут или еще что, мало ли. останется допустим 870 из 1000. А это значит что у тебя 130 пустых ИД, и при пересчете таблицы, 130 пользователей получат другой primary_key и больше не увидят своей переписки.

Обрати внимание на то что такие данные как ID (primary) или Дата могут быть видоизменены и данные могут быть утеряны

я бы предложил использовать "ключем" хэш строку пароля пользователя, в этом есть свои плюсы:

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

Не, ты не так меня понял, у каждого юзера будет свой id при регистрации выдаваться. (он будет привязан). В БД это AUTO_INCREMENT называется, думаю ты понял меня.

Так что, даже если и удаляться 130 человек, все-равно у других пользователей ихние id останутся.

killer8080

5.11.2013 - 02:08

Цитата (lop_atin @ 4.11.2013 - 20:01)

перед тем как записать сообщение в БД, мы, например, определяем его id, допустим это id будет 123, потом:

$id = 123;
$key = md5(md5($id));
все у нас есть уникальный ключ, для каждого сообщения, и, что мне нравиться больше всего, его не нужно хранить отдельно. Алгоритм получения этого ключа знаю только я.

вот в этом и проблема, это называется безопасность через неясность, а полагаться на неё нельзя. Всё тайное рано или поздно становится явным. Как только алгоритм формирования ключа будет разгадан, вся ваша защита рассыпется как карточный домик

twin

5.11.2013 - 08:43

killer8080

Цитата

Всё тайное рано или поздно становится явным. Как только алгоритм формирования ключа будет разгадан, вся ваша защита рассыпется как карточный домик

OK. Ну так предложи вриант.

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

На сегодняшний день одним из саамых серьёзных и несложных алгоритмов шифрования является rijndael-256. В PHP есть соответствующая реализация.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

user posted image

bposter

5.11.2013 - 09:15

Цитата (exotica @ 4.11.2013 - 19:53)

А это значит что у тебя 130 пустых ИД, и при пересчете таблицы, 130 пользователей получат другой primary_key и больше не увидят своей переписки.

Обрати внимание на то что такие данные как ID (primary) или Дата могут быть видоизменены и данные могут быть утеряны

Даже я знаю что ID не изменим(если счетчик не збросить) толку тогда от него , или вы думаете даннае поле добавляют для красоты?

_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)

bposter

5.11.2013 - 11:30

А если при создании (канала, соединения) создавать id переписки и от него плясать?

_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)

bposter

5.11.2013 - 12:23

Не знал что Skype обос****ся, хотел скачать исходники но там болалайка, в url видно что файлы в 2010 году залили эт че скайп тогда ломанули?

_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)

bposter

5.11.2013 - 12:25

Я так понимаю можно написать свой кодировщик и он будет уникальным и соответственно не приступным.

_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)

redreem

5.11.2013 - 12:43

bposter

ага. тока сначала разработай матаппарат под этот супершифровальщик

и докажи (хотябы себе) что он достаточно устойчив к взлому

killer8080

5.11.2013 - 12:45

Цитата (twin @ 5.11.2013 - 07:43)

killer8080
Цитата Всё тайное рано или поздно становится явным. Как только алгоритм формирования ключа будет разгадан, вся ваша защита рассыпется как карточный домикOK. Ну так предложи вриант.

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

идеальной защиты не существует, но само собой хранить ключи вместе с шифрованными данными глупо. Шифрование/дешифрование, генерация и хранение ключей должно быть на клиентской стороне. Естественно юзеру придется самому заботится о их сохранности. В случае утечки закрытого ключа скомпрометирован будет только этот пользователь, если ключи, или алгоритм их формирования хранить на сервере, в случае уязвимости на последнем, под удар попадают сразу все пользователи.
Как вариант браузерной реализации, существует OpenPGP.js

lop_atin

5.11.2013 - 16:38

Цитата (MiksIr @ 5.11.2013 - 11:49)

Цитата (twin @ 5.11.2013 - 08:43)

killer8080

Цитата

Всё тайное рано или поздно становится явным. Как только алгоритм формирования ключа будет разгадан, вся ваша защита рассыпется как карточный домик

OK. Ну так предложи вриант.

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

На сегодняшний день одним из саамых серьёзных и несложных алгоритмов шифрования является rijndael-256. В PHP есть соответствующая реализация.

Это же банально - ключи должны быть у собеседников на их стороне, а не на сервере. Иначе будет так http://habrahabr.ru/post/98546/
В остальном - шифровать базу оставляя алгоритм в коде - это как ставить металлическую дверь забыв закрыть окно на втором этаже.

То есть мой метод по твоей логике не подходит?
* Я про то, чтобы брать id собеседника и из него делать ключ.

bposter

5.11.2013 - 16:44

Цитата (redreem @ 5.11.2013 - 08:43)

bposter

ага. тока сначала разработай матаппарат под этот супершифровальщик

и докажи (хотябы себе) что он достаточно устойчив к взлому

Москва тоже не за один день построена, понятное дело если надо быстро то берем готовое решение

_____________
Вязание xe4.ru спицами.
Сайт для тестов (подопытный №543)

Aeq

5.11.2013 - 20:36

Цитата (killer8080 @ 5.11.2013 - 02:08)

Цитата (lop_atin @ 4.11.2013 - 20:01)

перед тем как записать сообщение в БД, мы, например, определяем его id, допустим это id будет 123, потом:

$id = 123;
$key = md5(md5($id));
все у нас есть уникальный ключ, для каждого сообщения, и, что мне нравиться больше всего, его не нужно хранить отдельно. Алгоритм получения этого ключа знаю только я.

вот в этом и проблема, это называется безопасность через неясность, а полагаться на неё нельзя. Всё тайное рано или поздно становится явным. Как только алгоритм формирования ключа будет разгадан, вся ваша защита рассыпется как карточный домик

сокрытие какого-то такого доп.алгоритма или соли в коде равносильно сокрытию секретного ключа собственно. Современные алгоритмы специально рассчитаны на то что алгоритм зашифровки типа всем известен и секретность сводится к секретности ключа.

Aeq

5.11.2013 - 20:43

ну то есть я собственно к тому, что написать в коде $key = md5(md5(mega_secret_function($id))) настолько же безопасно или не безопасно как захардкодить $key = 'jfhgasdfhkg', если конечно взломщику известны ID