Niedawno zarejestrowałem się w IFTTT , co wydaje się fantastyczną usługą do łączenia wydarzeń w celu stworzenia inteligentnego domu lub zautomatyzowania różnych usług.
Właśnie znalazłem kanał Maker, który pozwala na składanie prostych żądań HTTP (np. GET i POST), i mam nadzieję, że użyję tego, aby bezpiecznie wysłać wiadomość do uruchomionego przeze mnie Raspberry Pi, który czeka na każde żądanie API na określonej trasie (powiedzmy na przykład POST /foo).
Artykuł Makezine, który podłączyłem , sugeruje tę metodę bezpieczeństwa:
Teraz to, co zrobiłem powyżej, było strasznie niepewne. Zasadniczo pokazałem światu skrypt - innymi słowy aplikację internetową - która może włączać i wyłączać przełącznik kontrolujący światło w moim domu. Oczywiście nie jest to coś, co chcesz zrobić, ale właśnie dlatego usługi IFTTT umożliwiają przekazywanie większej ilości informacji do usługi zdalnej.
Nie byłoby trudno skonfigurować na przykład uwierzytelnione łącze TOTP między nimi, wymianę tokena lub klucza - i chronić własne konto IFTTT? Właśnie dodali uwierzytelnianie dwuskładnikowe.
Przeczytałem więcej na temat jednorazowych haseł opartych na czasie na Wikipedii, co wydaje się sugerować, że w celu wygenerowania hasła jednorazowego istnieje element obliczeniowy.
Ponieważ IFTTT nie obsługuje tworzenia łańcuchów zadań ani skryptów, jak wygenerować TOTP zgodnie z sugestią zawartą w tym artykule? Czy jest to w ogóle możliwe, ponieważ niektóre obliczenia są wymagane i wydaje się, że nie ma na to sposobu?
źródło
Odpowiedzi:
Powiązany artykuł jest trochę mylący. Interfejs udostępniony przez IFTTT nie jest całkowicie otwarty, wymaga klucza w żądaniu. Ponieważ żądanie jest przesyłane przy użyciu protokołu HTTPS, nie można bezpośrednio zaobserwować tajnego klucza (pod warunkiem, że klient zawsze niezawodnie łączy się z IFTTT, a nie z serwerem proxy mitm).
Ze strony informacyjnej kanału producenta (specyficzne dla użytkownika)
Teraz kluczem jest tylko niska entropia, więc potencjalnie można go odwrócić od monitorowania twoich żądań (chyba że wypełnisz je hałasem wysokiej jakości), ale żądanie zabezpieczenia na sesję jest w tym przypadku spełnione przez TLS, który obsługuje konfigurację kanału HTTPS .
Aby komunikacja była znacznie bardziej bezpieczna, wymagałoby to od IFTTT szczególnego wspierania uwierzytelniania punktu końcowego, ale wydaje się, że przekracza to zabezpieczenia stosowane w przypadku innych łączy po stronie usługi. Oznacza to, że Twój kanał producenta do IFTTT jest obecnie równie bezpieczny, jak kanał IFTTT do urządzeń domowych.
źródło