Этот сценарий безопасен?
import java.io.FileReader;
import org.json.simple.JSONObject;
import org.json.simple.parser.*;
public class Example
{
public static void main(String[] args) throws Exception
{
// parsing file "JSONExample.json"
Object obj = new JSONParser().parse(new FileReader("/Users/dell/Documents/JSONExample.json"));
// typecasting obj to JSONObject
JSONObject jo = (JSONObject) obj;
// getting json filds
String firstName = (String) jo.get("Address");
String lastName = (String) jo.get("Area");
String BookingDate = (String) jo.get("BookingDate");
String BookingDetails = (String) jo.get("BookingDetails");
String noOfBoxes = (String) jo.get("noOfBoxes");
String createdAT = (String) jo.get("createdAT");
String ModifiedAT = (String) jo.get("ModifiedAT");
System.out.println(firstName);
System.out.println(lastName);
System.out.println(BookingDate);
System.out.println(BookingDetails);
System.out.println(noOfBoxes);
System.out.println(createdAT);
System.out.println(ModifiedAT);
}
}
result of this file is
Durga Nagar
West aerodrome
1970-01-01
[{"date": "2019-05-14","quantity": "55"},{"date": "2019-05-15","quantity": "58"},{"date": "2019-05-16","quantity": "50"}]
null
2019-03-29 07:48:07
2019-03-29 07:48:07
5 ответов
Лучшая вещь, которую можно сделать для улучшения безопасности, состоит в том, чтобы использовать существующий дизайн и не попытаться изобрести велосипед. Я не говорю, что то, что Вы сделали, обязательно неправильно, но просто что многие люди, намного более умные, чем Вы и я, провели много времени, думая об этой проблеме. Используйте TLS вместо этого.
Целый (частный) key1 не был прерван так или иначе третьим лицом, Ваш сценарий выглядит безопасным.
Я думаю, что видел это где-нибудь в газете на самом деле. В нем Alice дала Bob разблокированное поле (ключевая 1 общественность), затем Bob поместил набор своих собственных полей (ключевые 2 общественности) в нем, блокировки он, и передает его обратно Alice. Alice затем открывает поле (ключевой частный 1), и теперь она может надежно изолировать поля, которые Bob просто дал ей.
Несмотря на аналогию поля, это по существу, что Вы делаете, таким образом, я сказал бы его безопасное.
Я согласовываю, просто использую TLS.
Кроме того, какое значение шаги 5 - 7 обеспечивают? Желание MITM сделать нападение, которое работало бы после шагов 1-4 (например, какой-то DoS путем передачи n транзакций через и затем остановки, вынуждая повторную попытку покинуть запуск) могло сделать так точно также после 5-7. Что они добавляют?
- MarkusQ
Нет, этот протокол не безопасен.
man-in-the-middle может прервать данные, отправленные клиентом, и отправить то, что это хочет к серверу, так как Вы не указали механизма для сервера, чтобы аутентифицировать клиент или проверить целостность сообщений, которые это получает.
Несомненно, Вы могли разбавить свой протокол для решения этих явных проблем, но будут другие. Если бы Вы когда-либо фиксируете их всех, у Вас было бы что-то, что отображается на TLS или SSH, итак, почему не только запускаются там?
@Petoj — проблемой, на которой я фокусировался, была проблема сервера, доверяя сообщениям, которые это получает; Ваше предложение не обеспечивает безопасности там. Однако, если Вы волнуетесь по поводу конфиденциальности, у Вас все еще есть проблема, потому что MITM мог передать сообщения, назад и вперед неизменные, пока он не видит то, что хочет найти, потому что у Вас нет конфиденциальности на клиентских сообщениях.
Ваше предложение, кажется, нацелено на обеспечение целостности сообщений от клиента. Вы разработали протокол до такой степени, когда, клиент не может различать нападение и отказ сети. Вместо того, чтобы пытаться помочь клиенту определить, действовал ли сервер на вмешавшееся сообщение, позвольте серверу проверять целостность сообщения прежде, чем действовать на него.
Я соглашусь с Greg, что Вы изобретаете велосипед. То, что Вы по существу описываете, является некоторой канонической формой ключевого обмена. Кстати, чтобы удостовериться, что это безопасно против атак "человек посередине", необходимо также быть уверены в идентификационных данных сервера, т.е. удостовериться, что клиент может знать с уверенностью, что то, чему это верит для общественности (key1) действительно, является сервером а не man-in-the-middle (например, использование CA или наличие общественности сервера (key1) в безопасном устройстве хранения данных на стороне клиента.)
Кроме того, существуют дополнительные соображения, как которые необходимо знать с системной точки зрения, необходимо быть такими:
- шифрование с асимметричным ключом медленнее, чем шифрование с симметричным ключом, которое является одной из причин, почему существующие решения, такие как TLS будут использовать шифрование с асимметричным ключом только для согласования временного симметричного ключа, который затем используется для шифрования канала.
- если анализ трафика третьим лицом преуспевает в том, чтобы взломать временный симметричный ключ, Вы не скомпрометировали Вас асимметричная пара ключей. Вы поощряетесь пересматривать временный ключ относительно часто поэтому. Возможно, генерация нового
key2в Вашем сценарии смягчил бы этот аспект.