|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
Приветствую! Есть сервис WCF (Consol) и клиенты (WinForms), транспорт вообще никак не защищен, т.к. программа в разработке и первоочередной задачей была производительность, функциональность и надежность. Теперь же пришло время задуматься о защите ... Итак, сервис передает данные трех типов: 1) обычные типы (Integer, String и т.п.) 2) пользовательские классы 3) массивы Byte() (таблицы) Шифровать обычные типы мне не нужно, а вот классы и массивы необходимо. Авторизация на сервере проходит следующим способом: 1) клиент соединяется с сервером 2) вызывает единственно доступную функцию для авторизации и передает в нее логин и пароль 3) сервис сверяет данные по базе и добавляет данного клиента в авторизованный список, после чего клиент может пользоваться другими функциями и процедурами (права проверяются в каждой) У меня есть самописный класс на основе криптофункционала .NET, может шифровать все от файлов до классов. На его основе я хочу организовать шифровку передаваемых данных. Выглядеть это будет так: Авторизация с шифрованием: 1) клиент соединяется с сервером 2) вызывает функцию для авторизации и передает в нее логин и хеш пароля 3) сервис сверяет данные по базе, добавляет данного клиента в авторизованный список, а так же генерирует доп. пароль, шифрует его хешем пароля клиента и отправляет обратно 4) клиент расшифровывает его и соединяет его с хешем своего пароля (хеш пароля клиента & доп. пароль, сервис делает так же) 5) дальнейшее шифрование ведется на основе этих паролей. От сюда вопрос: Данный подход нормальный или это все бред? П.С. Почему не сертификаты? Потому что пользователям этого не надо, тем более пользователи все время временные и запариваться на сертификаты они не будут. При таком подходе придется серилизовать в Byte() и пользовательские классы, это повлияет на производительность или нет? Ведь, как я понял, все равно WCF серилизует классы перед отправкой и шифрует (если это включено) просто в данном случае это будет делаться вручную. В итоге хотелось бы получить достойную защиту данных и производительность. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2012, 12:35 |
|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
__Pavel__, 1. А теперь главный вопрос сегодняшнего вечера, чем не устраивают существующие решения которые из коробки есть в wcf. 2. в схеме: Авторизация с шифрованием: 1) клиент соединяется с сервером 2) вызывает функцию для авторизации и передает в нее логин и хеш пароля 3) сервис сверяет данные по базе, добавляет данного клиента в авторизованный список, а так же генерирует доп. пароль, шифрует его хешем пароля клиента и отправляет обратно 4) клиент расшифровывает его и соединяет его с хешем своего пароля (хеш пароля клиента & доп. пароль, сервис делает так же) 5) дальнейшее шифрование ведется на основе этих паролей. я конечно уже подзабыл криптографию, но помоему такая схема будет уязвима к большей половине известных атак. тогда уж стандартный велосипед делать с окрытым-закрытым ключом. но уж точно не изобретать свой велосипед с хешами-доп-паролями-и-прочей-ересью. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.11.2012, 23:05 |
|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
FsShoman, 1) У меня дуплексный канал, т.е. передача данных идет в обе стороны, следовательно если делать шифрование с закрытым и открытым ключом, то нужно генерить и хранить 2 ключа на сервере и 2 на клиенте... в принципе возможно, но я пока не умею шифровать таким образом, а так у меня уже все готово и протестировано... 2) "будет уязвима к большей половине известных атак" Как? Если ключ ни разу не передастся в открытом виде? А сервер не даст никакой инфы без авторизации? 3) Пользователь на клиенте ничего не должен вводить кроме Логина и Пароля, а администратор должен тупо скинуть ЕХЕ файл на его комп (ну максимум FW Client Profile поставить) без каких либо настроек (все сложности администрирования в топку, максимум простоты!) Ладно попробую пока так, начнутся взломы, буду думать в другом направлении ;) всем спасибо все свободны! П.С. выкладываю скрин (время идет нарастающим итогом) тестов на скорость (по нему видно что таблицы лучше жать ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.11.2012, 00:15 |
|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
Всё зло. Что нужно - шифрование канала (SSL) и аутентификация с авторизацией (роли). Классика - виндовая аутентификация с авторизацией по группам. Или мембершип. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2012, 14:34 |
|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
МСУ, не понятно, ты так веришь в мембершип, от того, что нету опыта с другими средствами или от того, что ты сравнил все средства между собою и мембершип вышел эффективнее? Пойми, Павел, забурлился в тему то, он не ждет советов типа выкинь и поставть это. Ему ж хочется дискусии. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2012, 12:16 |
|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
__Pavel__, самописные решения часто ненадежны, несмотря на то что думает автор. стандарты шифрования более надежны и криптоустойчивы к дырам , обо которых автор самописец еще не все знает. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.11.2012, 15:29 |
|
Ручное шифрование - бред или надежность?
|
|||
---|---|---|---|
#18+
AlexeiKМСУ, не понятно, ты так веришь в мембершип, от того, что нету опыта с другими средствами или от того, что ты сравнил все средства между собою и мембершип вышел эффективнее? Причем тут "вера во что-то". Оба средства - параллельные дефолтные провайдеры из коробки. Можно еще микс заюзать ActiveDirectoryMembershipProvider или трендовый SimpleMembership. Чё хотел-то сказать? AlexeiKПойми, Павел, забурлился в тему то, он не ждет советов типа выкинь и поставть это. Ему ж хочется дискусии. Да мне как-то фиолетово, что хочет Павел. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.11.2012, 00:15 |
|
|
start [/forum/topic.php?fid=19&fpage=13&tid=1397147]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
26ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
2ms |
others: | 11ms |
total: | 123ms |
0 / 0 |