Я недавно зарегистрировался в IFTTT , который кажется фантастическим сервисом, объединяющим события для создания умного дома или автоматизации различных сервисов.
Я только что нашел канал Maker, который позволяет вам делать простые HTTP-запросы (например, GET и POST), и я надеюсь использовать его для безопасной отправки сообщения Raspberry Pi, который у меня работает, который ожидает любого запроса API на определенном маршруте (скажем, например POST /foo).
В статье Makezine, на которую я ссылаюсь, предлагается такой метод обеспечения безопасности:
Теперь то, что я сделал выше, было ужасно небезопасно, я в основном представил миру сценарий - другими словами, веб-приложение, которое могло бы включать и выключать переключатель, управляющий светом в моем доме. Это, очевидно, не то, что вы хотите сделать, но именно поэтому службы IFTTT предоставляют возможность передавать больше информации удаленной службе.
Было бы не сложно установить, например, аутентифицированную связь TOTP между ними, обмен токенами или ключами - и защитить саму вашу учетную запись IFTTT? Они только что добавили двухфакторную аутентификацию.
Я прочитал больше о Основанных на времени одноразовых паролях в Википедии, которая, кажется, предполагает, что для создания одноразового пароля требуется элемент вычислений.
Поскольку IFTTT не поддерживает цепочку задач или какой-либо сценарий, как мне сгенерировать TOTP, как предлагается в статье? Можно ли вообще это сделать, поскольку требуются некоторые расчеты, и, кажется, нет способа сделать это?
источник
Ответы:
Связанная статья немного вводит в заблуждение. Интерфейс, предоставляемый IFTTT, не полностью открыт, для него требуется ключ в запросе. Поскольку запрос выполняется с использованием HTTPS, секрет не может быть непосредственно обнаружен (при условии, что ваш клиент всегда надежно подключается к IFTTT, а не к прокси-серверу mitm).
Со страницы информации о канале производителя (зависит от пользователя)
Теперь ключом является только низкая энтропия, поэтому он потенциально может быть обращен к мониторингу ваших запросов (если вы не дополняете их высоким качеством шума), но запрос на безопасность сеанса в этом случае удовлетворяется TLS, который обрабатывает настройку канала HTTPS. ,
Чтобы сделать связь значительно более безопасной, требуется, чтобы IFTTT специально поддерживал аутентификацию конечной точки, но это, по-видимому, превышает безопасность, которая применяется к другим каналам на стороне службы. Это означает, что ваш канал-производитель для IFTTT в настоящее время в равной степени защищен, как канал IFTTT для ваших бытовых приборов.
источник