Чи надійний мій дизайн? [зачинено]

У мене є досвід системного проектування та програмування, але не інтернет-безпеки. Чи може хто-небудь допомогти визначити, чи є наступний дизайн достатньо безпечним?

Система складається з двох частин:

По-перше, веб-сайт / сервер (забезпечений за допомогою SSL), який відображає карту та розбиває пробіл про місцезнаходження користувача. Друзі & amp; родичі, які надали користувачеві пароль, можуть увійти і побачити, де знаходяться користувачі та де вони були (наприклад, за останні 24 години).

По-друге, телефонна програма, яка передає дані GPS на сервер. Основний розгляд останнього полягає в тому, щоб зберегти повідомлення про місцезнаходження як можна коротше, щоб мінімізувати час автономної роботи та допуск даних користувача. Тому я дійсно не хочу використовувати SSL для відправки повідомлень з телефону (це додасть великі накладні витрати в іншому невеликому повідомленні - можливо, надсилається кожну хвилину). Він також додає складності та розміру програми.

Моїм запропонованим рішенням є наступне:

1. При реєстрації (через веб-сайт) система створює хеш для користувача, який ґрунтується на імені користувача та паролі, який зберігається в базі даних як "ідентифікатор користувача" (це буде інший хеш, який використовується для зберігання пароля) . Можливо, SHA512, хоча це може бути не дуже довго.

2. Під час встановлення програми на свій телефон користувачі вводять ім'я користувача & amp; пароль. Додаток потім використовує той самий алгоритм хешування, і надсилає хеш-значення на сервер через кінцеву точку, яка не є SSL. Якщо розпізнано, сервер відповідає OK і додаток зберігає хеш як ідентифікатор користувача.

3. Під час запуску програми кожен раз, коли відзначається нове місце розташування, він надсилається разом із міткою часу та ідентифікатором користувача на сервер (знову ж таки не SSL). Сервер зберігає дані відповідно до правильного ідентифікатора користувача.

4. Сервер буде працювати на двох окремих веб-службах, один SLL і один не, обидва розмовляють з тією ж базою даних.

Там, ймовірно, дефект десь, будь ласка, дайте мені знати, якщо так! Безпека, звичайно, є те, що той, хто не отримав пароль, не повинен бачити місцезнаходження користувача. Заздалегідь спасибі.

Як зауважив @Eugen, з обох точок зору є недолік:

• Ми можемо ідентифікувати хеш і спостерігати за користувачем
• Ми можемо використовувати хеш для уособлення користувача

Крім того, корисне навантаження - " чітко ", який, ймовірно, не придатний для даних про місцезнаходження користувача ...

Можна подивитися на засолювання хешованих даних за допомогою мітки часу, яка, принаймні, створить новий хеш для кожного звіту, але це збільшить навантаження на сервер для аутентифікації хешу (потрібно спробувати кожного користувача, можливо, з діапазоном міток часу) ).

Підписання - це хороший спосіб обійти це - це може бути добре Веб-маркери JSON для ідей, хоча це дійсно призначено для перевірки автентичності даних сеансу і т.д.

SSL дійсно додає накладні витрати при встановленні з'єднання, але чи ви насправді це кількісно визначили? Ви впевнені, що це проблема? Крім того, з точки зору збільшення складності в App, не так багато. Оскільки ви повідомляєте про місце розташування один раз на хвилину, чи не могли б ви подивитись на активність сеансу SSL між звітами, усуваючи накладні витрати під час встановлення з'єднання?

Пам'ятайте також, що SSL не єдиний спосіб шифрування корисного навантаження. Можна шифрувати за допомогою іншого асиметричного шифрування (виконати ні використовувати симетричне шифрування) ... з асиметричним шифруванням будь-хто може шифрувати дані для певної мети (за допомогою відкритого ключа), але тільки ціль може розшифрувати її (використовуючи закритий ключ). Подивіться на GPG для популярної відправною точкою - це також додасть додаткові накладні витрати, але не буде дійсно прийнятним передавати такі дані в чистому вигляді.

Ваш дизайн дійсно має дефект конфіденційності: після того, як зловмисник зрозумів значення хешу для користувача, він може видати себе за користувача, тобто надіслати неправильні дані про місцезнаходження на сервер.

Це пов'язано з тим, що ваш хеш є статичним - колись відомим, завжди відомим.

Існує спосіб цього: на клієнті об'єднати дані корисного навантаження та поточну мітку часу, а потім скористатися хешем, щоб підписати це. Надішліть тимчасову мітку (ясно) із запитом, і сервер відхилить явно неправильні часові мітки.

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

Що, звичайно, залишається, як ризик конфіденційності, це те, що дані GPS відкриті для всіх, хто слухає - це може бути або не бути прийнятним для вас.