Apple zet toegang logingegevens Safari open voor externe apps

Apple geeft ontwikkelaars toegang tot logingegevens die opgeslagen zijn in Safari. Deze kunnen in apps gebruikt worden om de logingegevens automatisch in te vullen. Dat moet ervoor zorgen dat het inloggen op apps wordt bespoedigd.

De nieuwe feature werd ontdekt door 9 To 5 Mac. In iOS 8 kunnen gebruikers logingegevens voor applicaties automatisch laten invullen op basis van opgeslagen logingegevens in Safari. Daardoor kunnen gebruikers in apps inloggen met een druk op de knop, zoals ook in de browser mogelijk is.

Om automatisch invullen mogelijk te maken moeten ontwikkelaars hun website en app met elkaar koppelen. Deze koppelingsinformatie moet zowel in de app als in de website worden verwerkt zodat Safari weet dat er een koppeling bestaat, aldus 9 To 5 Mac. Als de gebruiker dan zijn logingegevens voor een website opslaat in Safari, weet de browser dat deze ook in de bijbehorende app automatisch moeten worden ingevuld.

Als de gebruiker geen logingegevens heeft opgeslagen in de browser kan dit vanuit een app alsnog worden gedaan. Daarnaast krijgen applicaties ook de mogelijkheid om de opgeslagen logingegevens aan te passen, bijvoorbeeld als de gebruiker zijn wachtwoord heeft veranderd.

Apple kondigde iOS 8 tijdens zijn WWDC-ontwikkelaarsconferentie aan en liet daarbij onder andere weten met een gezondheidsapp, een vernieuwd notificatiecentrum en een api voor domotica te komen. Een functie waarvan onlangs nog details naar buiten kwamen is een truc om wifi-tracking door bedrijven te voorkomen. De iOS 8-software komt later dit jaar uit voor iOS-apparaten.

Reacties (32)

[Deem]

Ik ben absoluut geen fan van de Keychain of Sleutelhanger.

Bijoorbeeld als je de Sleutelhanger gebruikt op je idevice, dan kan je al je opgeslagen wachtwoorden als platte leesbare text zien onder Instellingen -> iCloud -> Sleutelhanger.

Ik heb zo menig iphone gebruiker laten schrikken door al hun wachtwoorden van hun telefoon had op te lezen...

[Reactie gewijzigd door Deem op 29 juli 2024 17:12]

[Jannis]

De enige plek waar ik mijn Keychain wachtwoorden kan zien is onder de Safari instellingen. En die vereist mijn pincode alvorens ik het wachtwoord kan zien. Onder iCloud -> Keychain enkel een aan/uit switch.

[Chip5y]

Er is wel degelijk een manier om uw paswoorden te zien zonder het keychain paswoord nodig te hebben.
Als je in Safari voor OS X bent ga dan eerst naar Preferences - Advanced en zet 'Show Develop menu in menu bar' aan. Ga dan naar de website waarvan je het wachtwoord wil weten. Je merkt dat jouw wachtwoord gemaskeerd is ingevuld. Cmd-klik op het wachtwoord en klik op 'inspect element' . Waar staat type="password" verander dit naar type="text". En voila jouw paswoord staat nu in plain tekst te lezen. Deze truc is ook mogelijk met iOS maar dan moet deze wel aangesloten zijn op een computer en is net iets complexer.

Dit is de hoofdzakelijke reden waarom Firefox en Chrome geen paswoord gebruiken in het programma zelf bij de opgeslagen paswoorden omdat vanaf dat iemand toegang heeft tot jouw computer (fysiek of remote) dit paswoord compleet nutteloos is en enkel een vals gevoel van veiligheid geeft. Wanneer je synced met iCloud is een paswoord daar natuurlijk wel een extra veiligheid voor als iCloud gehackt wordt, dat daar een extra paswoord gevraagd wordt. Maar eens toegang tot computer is het extra paswoord (en lokale encryptie) in Safari nutteloos.

[Reactie gewijzigd door Chip5y op 29 juli 2024 17:12]

[Whatts]

Dit is de hoofdzakelijke reden waarom Firefox en Chrome geen paswoord gebruiken in het programma zelf bij de opgeslagen paswoorden

FireFox heeft wel een "master password" optie hiervoor, Chrome niet.

[johnkeates]

Dat "master password" wordt dan ook weer lokaal opgeslagen...

[elmuerte]

Maar niet in plain text or reversible. Master password kwijt = jammer voor je.

[johnkeates]

Je data is niet asymmetrisch gecodeerd wat betekent dat je helemaal de reversed master niet nodig hebt.

[BobJung]

Net deze procedure uitgevoerd op mijn Imac, met laatste updates, maar ik zie het niet.
Was naar een website gegaan met een .................... wachtwoord. cmd klik erop en er gebeurt helemaal niks. Daarnaast moet ik wel zeggen als je eenmaal zover bent in een machine, je op gebruikers niveau bent en het mij logisch is dat je machine toegankelijk is voor je. De keyring kan ik alleen maar benaderen via mijn login pass.
Lijkt mij dat dit ooit mogelijk was , maar nu niet meer.

[Chip5y]

Heb het al even niet meer getest maar zo lang is het nu ook weer niet geleden (een aantal maanden), maar kan altijd aangepast zijn natuurlijk. Heb je zeker Web inspector geactiveerd in de preference menu (show develop menu in menu bar)?
Edit: Ah heb mijn fout gezien, heb cmd klik geschreven terwijl het control klik of met andere woorden dus rechtermuisklik moet zijn. (Domme fout van mij)
Het komt er dus op neer dat je de context menu te zien krijgt (met bijvoorbeeld functies kopiëren en plakken in). selecteer daar inspect element

Als het klikken niet werkt kan je ook eerst Web Inspector activeren vanuit de Develop menu terwijl je op de website bent en dan 'Inspect' knop (met het scope icoon) drukken en op het paswoord klikken.

[Reactie gewijzigd door Chip5y op 29 juli 2024 17:12]

[xoniq]

Kan makkelijker, even een JS snippet aan je bookmarkbar toevoegen, naar die website gaan waar het wachtwoord wordt ingevuld, drukken op die snippet, en je wachtwoord wordt getoond in een 'alert()'-venster.

[comitatus]

Ik ben zelf geen Apple gebruiker maar voor mijn geldt dat alleen de totaal niet belangrijke wachtwoorden/sites de wachtwoorden zijn opgeslagen. Dit gebeurd ook nog is met een masterwachtwoord. Zelf ben ik van mening wanneer de keychain geen onderscheidt kunt maken tussen wel of niet opslaan per site het nutteloos is.

[Verwijderd]

klopt langs geen kanten, dat je het in tekst kan zien is normaal als je ingelogd bent met je account. Anders heeft het natuurlijk weinig zin om een centraal paswoordsysteem te hebben. De paswoorden zelf zijn wel degelijk encrypted opgeslafen.

Je snapt duidelijk niet hoe keychain werkt, dus let op met wat je verkondigd naar andere mensen.

[MadDonkey]

Geen last van. Dat staat namelijk standaard uit :-)

[BoringDay]

Er staat dat het wel gecodeerd wordt (zie tekst bij de instellingen).

[Trommelrem]

Ik vind dit een beetje eng. Kan het niet andersom? Dat de app een authenticatieverzoek indient bij Safari en dat Safari de login doet voor de app?

Ik kan niet wachten op de eerste app in de appstore die alle login's ophaalt en verstuurt naar een botnet

[ZpAz]

Zowel de website als de app moet tegen Apple zeggen: "Hee wij horen bij elkaar". Als dat niet het geval is kunnen ze niet bij elkaars wachtwoord. Bijvoorbeeld enkel youtube.com kan bij het wachtwoord in de youtube app en visa versa.

Je kan dus lang wachten op een app die alle wachtwoorden uitleest en verstuurd naar een botnet.

[Reactie gewijzigd door ZpAz op 29 juli 2024 17:12]

[ACM]

Dan ga je er natuurlijk wel vanuit dat er geen bugs in die authenticatie zitten Want zodra er zoiets wel in blijkt te zitten, dan hoef je juist niet zo lang te wachten tot er apps zijn die dat doorsturen...

[Verwijderd]

En we weten allemaal dat de huidige methodes voor authenticatie allemaal feilloos en foutloos werken.... Oftewel: voor ieder stuk software ga je er van uit dat er geen bugs in zitten. Anders zou je nooit meer wat nieuws gaan maken, want als je alleen maar iets gaat introduceren wat gegarandeerd zonder bugs is kunnen we nu per direct stoppen met ICT.

[ACM]

Volgens mij is de standaardaanname dat in alle niet-triviale software bugs zitten

De meeste bugs maken echter niet zoveel uit in deze context: de software zelf hoeft (voor je gegevensbeveiliging) niet belangrijk te zijn en zelfs in software die wel gericht is op gegevensbeveiliging zijn alsnog lang niet alle bugs daadwerkelijk een gevaar voor die beveiliging.

Maar we moeten ook weer niet te blind aannemen dat fouten in software altijd genegeerd kunnen worden. Juist voor dit soort tools - die heel veel gebruikt zullen worden - zal er flink gezocht worden naar beveiligingsfouten en het is ook best moeilijk om dit soort tools goed en veilig te maken... dus er is zeker een kans dat er iets significants gevonden wordt.

[cyberstalker]

Ik denk dat het niet lang zal duren voordat er mensen gaan proberen om via XSS een website te laten beweren bij een bepaalde app te horen zodat een app deze kan uitlezen en doorsturen naar een centrale server.

[Chaos]

Er is geen reden waarom een app bij honderden websites zou horen of waarom de website waar een app bij hoort zou kunnen veranderen. Je zult dus waarschijnlijk voor elke nieuwe website de app in de store moeten updaten. En zelfs dan zou Apple nog makkelijk een limiet van 1 naamsverandering per 6 maanden oid in kunnen stellen. Bovendien moet de gebruiker de eerste keer ook nog toestemming geven. Dit werkt op OS X ook al jaren zo met inloggegevens in applicaties.

[Chaos]

Websites/apps kunnen alleen aan hun eigen wachtwoord komen natuurlijk. Om via een app een wachtwoord te stelen zou je eerst code moeten toevoegen aan de website. Als je dat kunt kun je net zo goed aan de website kant het wachtwoord stelen, heb je de hele app niet nodig.

Alle wachtwoorden in keychain opslaan lijkt me juist een hele verbetering ten opzichte van app ontwikkelaars die zelf iets in elkaar klussen om het wachtwoord te onthouden.

[South_Styler]

Ik weet zonet nog niet of ik dit erg leuk ga vinden. Ik ben nogal op mijn privacy gericht. Het idee op zich vind ik leuk en het biedt zeker meerwaarde voor de consument. Dus, er is iets voor te zeggen vanuit het perspectief van gebruikerservaring. Altijd al het paradepaardje van Apple.
Echter, vanuit beveiligingsperspectief ben ik hier minder enthousiast over. Het meer openstellen van het OS voor externe apps zal ook de nodige zorgen met zich meebrengen op het gebied van beveiliging. Apple kan hun OS nog zo goed beveiligen, wanneer de externe app dan de zwakste schakel is (zeker met meerdere) dan kunnen alsnog alle gegevens worden ingepikt.
Ik verwelkom de vernieuwingen, maar maak me tegelijkertijd ook zorgen omtrend beveiliging.

[johnkeates]

Je kan het zelf aan/uit zetten, en ook per wachtwoord bepalen of je dat wel wil.

[Verwijderd]

Het is altijd een afweging: gebruikersgemak tegenover veiligheid.
Ik gebruik sleutelhanger niet, om veiligheids redenen. Dat het opgeslagen word in de cloud vind ik niet zo'n goed idee.

[Crazy D]

Als het niet online staat, is het voordeel t.o.v. een lokale password manager (of desnoods een txt met daarin je wachtwoorden) natuurlijk volledig weg. En juist omdat je overal tegenwoordig moet inloggen, en juist omdat er ook nog eens continue wordt geroepen dat je niet overal met dezelfde gebruikersnamen en vooral niet met dezelfde wachtwoorden moet inloggen, heb je tegenwoordig al snel een wachtwoordje of 9876543 nodig. En zodra je vanaf meerdere plekken naast je pc weleens internet, heb je op al die devices uiteindelijk toch een wachtwoord nodig.

Het idee wat Apple hier toont vind ik wel als een goed plan klinken, zolang de koppeling tussen app en website 1 op 1 is en het niet mogelijk is om een app aan meerdere sites te koppelen (andersom kan wel nuttig zijn).

Of vind je het geen goed idee dat het in de Apple cloud wordt opgeslagen? (en gebruik je wel een andere online password manager).

Maar gelukkig hoef je het niet te gebruiken als je dat niet wilt

[Verwijderd]

Ik,vind mijn wachtwoorden in de cloud geen goed idee nee.
Ik gebruik minikeepass op mijn iPhone, die heb ik altijd bij me.
https://itunes.apple.com/...password/id451661808?mt=8

[mutley69]

Inderdaad, het gevaar op identiteitsdiefstal wordt met de dag groter - ik ben ruzie aan't maken met m'n bank omtrend wat gekoppeld mag worden met m'n bankrekening. Ik wil dat ze verhinderen dat er een smartphone, tablet of gsm-nummer kan aan gekoppeld worden.
We zijn nu rustig alle opties aan't overwegen - de privacycommissie is voorlopig uitgesloten (er staan een bepaalde zin op een document - die me daartoe heeft laten besluiten, eens iets geëncrypteerd wordt - trekt de privacycomissie er zich niet veel meer van aan).
Je hebt natuurlijk nog het gegeven dat er iets gemaakt is in uw naam zonder uw goedkeuring. Je kan wel weigeren van 't te gebruiken - het is er - en het feit dat je het niet raadpleegt kan misschien ooit tegen u gebruikt worden. Die gedachtengang vind ik gewoon onrustwekkend, en absoluut onaanvaardbaar voor een rechtstaat.

[BoringDay]

Die regels worden gewoon door de ontwikkelaars bepaald op basis van juridische vereisten en eisen v.d. bank. Jij als klant zal daar geen invloed op hebben want het kan ook niet uit om dat per klant nog eens apart te gaan vast leggen. Hooguit zullen ze wat met je mee praten om je gerust te stellen maar daar houdt het dan ook echt op.

[Verwijderd]

Eindelijk, maar dan ook weer niet. Ik als bescheiden app programmeur/ontwikkelaar met een aantal app's in de App store, vond(en vind) dat het hele "Schöpfer" gedoe vrij irritant.is/was. Zeker in de "final subject" versie.. Ik denk dat er meer ontwikkelaars zullen zijn die deze "omweg" ervaring (en zeker in het iOS7 verhaal) niet zal missen. Helaas is de b8 net hetzelfde gebleven. De kans is dan ook heel klein dat er nog iets zal wijzigen ivm de subject codering. Het ideale iOS is en blijft nog altijd de 4 versies.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 17:12]

[Deido]

Eens komt een dag dat Apple's klant gegevens en wellicht zelfs data openbaar worden gesteld en misbruikt. Volgens mij is de vraag alleen wanneer.

[page404]

Geldt dat niet voor elk bedrijf? Sterker nog, bij veel grote bedrijven is het al gebeurd, en bij Apple nog niet. Dus volgens mij hebben ze een prima trackrecord