Reacties voor: Apple stelt deadline voor betere appbeveiliging (https) uit

Apple stelt https voor apps niet per 1 januari 2017 verplicht. De deadline voor App Transport Security (ATS) is uitgesteld.
Gonny van der Zwaag | iCulture.nl -

Reacties: 5 reacties

  1. Ik ondersteun het idee van de verplichting, maar ben blij dat het is uitgesteld!
    Het ligt er namelijk lang niet altijd aan of de developers er klaar voor zijn.
    Als je afhankelijk bent van apparatuur van derden (in mijn geval de Philips Hue Bridge die geen https ondersteund), kun je er zelf helaas weinig aan doen..

  2. @Michiel: Je zou juist verwachten dat fabrikaten zoals Philips met hun Hue lineup dit zouden moeten ondersteunen in deze tijd.

    Wat geeft dit aan? Werkt het zigbee protocol voor de beveiliging van een commando, of kan dus iedereen die de pakketjes kan opvangen zomaar informatie eruit halen of moeten ze dan wel in jouw LAN bevinden om deze te kapen?.

    Kortom het kan van mij niet snel genoeg komen, steeds meer worden dit soort dingen qua hacken toegankelijker en ondanks dat jezelf er van bewust bent ben je gelijk ook afhankelijk van de beveiligingen van derden, dan hoop je maar dat je bij de grotere jongens enigszins ook betaald voor veiligheid.

  3. Slechte zaak, en vreemde vorm van met twee maten meten tov verschillende soorten ‘verouderde’ apps. Laten ze dáár maar een irritante pop-up op geven als een app nog niet is aangepast, ipv op het veel ongevaarlijkere 32-bits zijn van een app 🤔

  4. @Angelus: (Correctie:) standaard staat de bridge niet open van buiten en zul je dus toegang moeten hebben tot het LAN.

    De huidige beveiliging bestaat uit de touch-link: een nieuwe app wil toegang tot jouw bridge, dan moet je binnen 30 seconden fysiek op de ‘touch-link’ knop op de bridge drukken. Klinkt veilig..
    Echter: de app krijgt dan een unieke identificatie (die bij elk commando in de http adres regel moet worden opgenomen 🤔) en daarmee is alles te doen op de bridge.

    Zelf heb ik dit enigszins proberen te tackelen door mijn iOS (client)-app niet met de bridge te laten communiceren, maar met een macOS (server)-app in het netwerk zelf, die vervolgens alle communicatie met de bridge regelt. In dat geval zou dit inderdaad alleen zichtbaar zijn bij het sniffen in de LAN zelf.

    Al sinds Apple vorig jaar met de voorgenomen maatregel kwam, is er met regelmaat aan Philips gevraagd wat ze van plan waren.. Buiten dat “https niet mogelijk is” en “ze in gesprek zijn met Apple over dit besluit” is er eigenlijk niks veranderd.
    Inderdaad jammer dat ze ervoor kiezen om hierover met Apple te gaan praten ipv een veilige, structurele oplossing te bedenken.

  5. @Michiel: bedankt voor je uitleg, hier heb je wat aan 🙂 ik heb zelf dan geen account gemaakt bij philips hue en laat het van buitenaf zijn werk doen doormiddel van me appletv, die figureert dus als hub en heeft dus in LAN zijn unieke verificatie code die dus waarschijnlijk niet beveiligd is.
    Hoewel dit dus door Homekit gebeurd waar naar wat ik heb gelezen een sterke beveiliging heeft, weet ik dus niet of dit aberhaupt veiliger is. Beste beveiliging is om het helemaal uit te zetten, alles wat buiten je LAN plaats vindt.

    Hierdoor ben ik dus laatst ook afgehaakt van slimme thermostaten, hoewel dit een leuke gadget gehalte geeft en mij zeker geld kan laten besparen, vind ik het erger dat ze aan me verwarming lopen te klote dan mijn lichten.

Reacties zijn gesloten voor dit artikel.