'Android 14 vereist niet langer enter na invoeren juiste pincode'

Android 14 krijgt vermoedelijk de mogelijkheid om het scherm te ontgrendelen na het invoeren van de juiste pincode. Tot nu toe moeten gebruikers altijd op enter drukken na het invoeren van de pincode. De functie is nog niet live.

Android 14 Auto-confirm Pincode

De toggle om de functie te activeren is standaard nog niet zichtbaar, zegt XDA-Developers. Deze zit al wel in de code en is dus zichtbaar te maken. De functie heet 'Auto-confirm Unlock' en werkt volgens de beschrijving alleen met pincodes van zes getallen of meer. Vervolgens ontgrendelt de telefoon automatisch bij het invoeren van de juiste pincode.

De software vermeldt dat het iets minder veilig is dan op enter moeten drukken. Dat komt doordat bij bruteforce-pogingen om de telefoon te ontgrendelen er een knop minder nodig is om in te drukken en een aanvaller dus sneller de mogelijke opties kan proberen. Deze functie zit nog niet standaard in Android, hoewel dit al langer werkt in custom roms en op de Android-telefoons van bepaalde fabrikanten als Samsung. Ook op iOS is het invoeren van enter niet nodig om de telefoon na het invoeren van de juiste pincode te ontgrendelen.

De pincode staat afgelopen tijd weer in de aandacht door gevallen waarbij aanvallers eerst de pincode van een slachtoffer afkijken om vervolgens de telefoon te stelen. Volgens The Wall Street Journal kunnen zij daarna het wachtwoord van een Google- of iCloud-account resetten om slachtoffers buiten te sluiten van hun eigen account. Daarna gebruiken ze de controle over het apparaat om geld van rekeningen af te halen.

Deze week kwam de tweede ontwikkelaarspreview van Android 14 uit. De nieuwe versie van het besturingssysteem is nog in ontwikkeling en niet alle nieuwe functies zitten erin. Google maakt vermoedelijk tijdens zijn ontwikkelaarsconferentie I/O ook nog nieuwe functies bekend. Die conferentie vindt plaats op 10 mei. Android 14 komt aan het einde van de zomer of in het najaar uit.

Reacties (97)

De software vermeldt dat het iets minder veilig is dan op enter moeten drukken. Dat komt doordat bij bruteforce-pogingen om de telefoon te ontgrendelen er een knop minder nodig is om in te drukken en een aanvaller dus sneller de mogelijke opties kan proberen.

Dit klopt maar half, het punt van [enter]/[submit] is dat je een authenticatiepoging doet, bruteforcen kan je vertragen door iedere poging een oplopende interval te geven. Eerste keer fout -> geen interval, tweede keer fout -> 15 seconden wachten, derde keer fout -> 15 minuten wachten, etc.

Met het wegvallen van deze pogingen kan een bruteforcer dus zonder 'echt' authenticatiepogingen te doen gewoon alle pincodes af, dus zonder interval door mislukte pogingen.

Dat is niet helemaal waar volgens mij, want bij de implementaties die ik gezien heb telt het invullen van het benodigde aantal karakters alsnog gewoon als authenticatiepoging met bijbehorende vertragingen.

Ik dus het tegenovergestelde: omdat de lengte van een pincode tussen de 4 en 8(?) karakters kan zijn, is alles daar tussenin valide input waarbij ieder nieuw karakter een poging tot valideren is.

Je zou het wel kunnen inregelen op een manier dat hij alleen valideert als je de lengte van de ingestelde pincode bereikt, maar daarmee trek je een heel nieuw blik met problemen open: als de aanvaller de lengte van de pincode kent valt er een aanzienlijk deel entropie weg.

Dit valt wel mee. iPhones doen dit al jaren. Ik heb een 6-cijferige passcode en als ik mijn iPhone zonder Face ID probeer te unlocken, zie ik al de 6 bolletjes die ingevuld moeten worden. Als ik een 4-cijferige passcode zou kiezen, worden het inderdaad 4 bolletjes, dat wordt je al voorgeschoteld.

Ja, het is minder veilig dan compleet blanco erin gaan, want dan heb je inderdaad wat jij eerder al zei: bij het minimaal toegestane aantal cijfers (4 meestal) probeert hij te authenticeren, dan bij 5 weer, dan bij 6 weer, etc.

Maar... zoals aangehaald heeft de iPhone dus ook die vertragingen erin zitten die uiteindelijk zelfs naar 1 uur en 24 uur gaan en gekoppeld aan de Find My feature zelfs een Security Lockout uiteindelijk triggert, wat betekent dat je alleen met je iCloud e-mail en wachtwoord (en 2FA) erin kan komen weer. Optioneel kan je als gebruiker ook instellen dat je telefoon gewist wordt na 10 foutieve pogingen. Ik heb dat ook aanstaan. Telefoon blijft alsnog aan mijn account gekoppeld, maar verder brute forcen heeft dan zelfs geen zin, behalve de iCloud activation lock proberen te omzeilen.

Android heeft dus ook dat systeem met timed lockouts in ieder geval, waarbij het ook bij een brute force gewoon niet grappig meer is na een paar pogingen. Ik moet alleen toegeven dat ik niet weet wat Android doet na de 24-uurs lock voordat je dus weer een passcode kan proberen in te voeren.

Maar dat de aanvaller de lengte weet is eigenlijk in het geheel niet relevant. Zelfs een zeer eenvoudig te brute forcen 4-cijferige passcode (los van additionele security features) is juist dankzij die security features als een timed lockout gewoon niet meer zomaar te raden.

Anders gezegd: de gelegenheidsdief of zelfs iemand die dondersgoed weet hoe het in elkaar zit, heeft er vrij weinig aan in de praktijk. Je zal dan toch echt moeten uitwijken naar tethered hacks om dit te omzeilen. Niks is onmogelijk, maar laten we realistisch blijven: zelfs de gemiddelde berichtjes van Mark Rutte zijn niet al te boeiend om te onderscheppen, dat is al gebleken. Dus voor 99% van de mensen is dit praktisch gezien zeer veilig en sowieso veilig genoeg.

En binnen de Android wereld zijn er ook al fabrikant eigen implementaties die dit zo hebben als optie, je kunt het zelf aanzetten of niet om zonder enter door te gaan na je pincode. Een voorbeeld is de Samsung OneUI implementatie van Android.

En WindowsPhone had dit ook al. Dan hoefde je ook geen enter te geven.

Het tonen van het aantal benodigde karakters is handig, maar wel een zwak punt. Eigenlijk zou een authentificatiepoging na elk ingevoerd teken moeten gebeuren, nog beter na een vertraging die groter is dan waarmee men de achtereenvolgende tekens invoert.
Bij Android is het laatste teken nu altijd een "enter". Dat voegt voor de veiligheid eigenlijk niets toe. De toegenomen onveiligheid zit alleen in het sneller kunnen invoeren van twee achtereenvolgende pin-codes. In de praktijk zal dat minimaal zijn.

De veiligheid is niet alleen belangrijk voor het eventueel onderscheppen van berichten, maar als men de pin-code heeft kan men het toestel ook leegmaken en gemakkelijker verkopen.

Heb je wel gelezen wat ik schreef? Alles wat je benoemt wordt namelijk al ondervangen middels de genoemde timed lockout en evt. nog extra maatregelen. Het tonen van het aantal benodige karakters is heel feitelijk zwakker, maar praktisch gezien dus in 99% van de gevallen niet. Want je hebt het over een pincode "raden" oftewel brute forcen, dat kan gewoon niet meer anno 2023. En kon al een tijdje niet.

Ja, dat heb ik. Maar het was te lang om goed te bevatten. Vandaar de reactie met een verkorte vorm.

Inderdaad, je zal meestal pas in de problemen komen als Apple mee wil werken aan het unlocken van je telefoon. Dan zijn 1 miljoen combinaties opeens triviaal, maar het is geen realistisch threat model voor de meeste mensen. Al is het dan in principe wel mogelijk dat zulke firmware opeens uit Apple ontsnapt en andere partijen daar ook beschikking toe hebben.

https://arstechnica.com/g...-has-the-desired-key/amp/

Daarbij gaat men er wel van uit dat de aanvaller geen soldeer capriolen uit haalt, en dat de secure enclave / TPM veilig is. Vanuit forensisch oogpunt is het zodra je de boel kunt imagen en geen secure enclave / TPM meer nodig hebt klaar met de pret van softwarematige timeouts (zeker als je ook het aantal characters weet wordt het ineens een heel stuk eenvoudiger). Want op het moment dat de secure enclave / TPM de software niet meer kan valideren en deze erdoorheen komt, dan kun je deze ook aanpassen, al is het maar met een simpele hexedit. Bijvoorbeeld je zou de binary die de timeout doet kunnen decompileren, en dan hier bijvoorbeeld zeggen bij het stukje 'als de code niet klopt, verhoog de timeout met X' veranderen met 'als de code wel klopt, verhoog de timeout met X' en dan ben je er al. Als dat lukt, is het verschil maar 1 byte. Ook kun je het dan in een VM draaien.

En ja, het argument dat je niets te vrezen hebt als je onschuldig bent gaat ook hier op. Want dit soort capriolen zijn helemaal niet interessant om te kijken of Truus met Toos via Signal heeft gebabbeld of wat Henkie zoal op Tor heeft bekeken. Pas wanneer Henkie vermoedens zijn dat Henkie ook daadwerkelijk op Hackforums.org komt, of dat Truus en Toos met creditcards aan het spelen zijn in winkels wordt het interessant. En dan nog, wat is proportioneel. Ik zou er voor kleine criminaliteit geen moeite in steken, het sop is de kool niet waard. Vergeet niet dat er ook altijd het gevaar is dat de onderzoeksmethode lekt.

[Reactie gewijzigd door Jerie op 10 maart 2023 16:26]

Bij lengte < 6 is de return alsnog gewoon nodig, dus dat is makkelijk controleren.
Bij lengte >=6 is elke invoer een validatiepoging dus kan je verwachten dat er bij de eerste 3 invoeren, namelijk tot en met maximaal 8 lang, nog geen vertraging optreedt maar daarna wél.
Wanneer je dan een paar keer een tikfoutje maakt, ben je al snel het haasje (of schildpad )

Eerste regel zo'n beetje bij wachtwoord/creadentials controle is dat je NOOIT info weg geeft over wat er precies fout is bij de invoer ervan; alleen DAT er wat fout is. Nog beter is dat je die gegevens sowieso niet hebt natuurlijk, want dan kun je ze ook niet lekken.

Vandaar ook de timed lockouts, niet alleen om dieven niet zomaar een kans te geven je telefoon te brute forcen of anderzijds snel in te komen, maar ook om jezelf na te laten denken. Serieus: ik heb het mijn nichtje weleens zien doen, wist ze haar code niet meer en begon ze te vloeken en tieren waarom ze op een gegeven moment 5 minuten moest wachten. Dus ik zei: omdat je zelf moet gaan nadenken nu, je hebt al 4/5 pogingen gehad zoiets, dus nog meer willekeurig gokken heeft geen nut. Uur later wist ze hem ineens weer.

Dus je kan het ook zien als een stukje social engineering, maar dan de andere kant op.

Ja, leuk. Helaas heeft dat ook tot gevolg dat men PINs gaat hergebruiken 'want dan kan ik het tenminste onthouden'.

Ligt het er gewoon niet aan wat Android voorschotelt? Wie zegt er dat het proces dat voor het invoerveld zorgt niet gewoon na elk volgende cijfer de authenticatie opnieuw probeert en een ja of nee krijgt die ergens in de RAM van het systeem terug is te vinden? De gebruiker heeft op dat moment alleen maar de permissie om cijfers in te voeren, verder niks. Kijken wat de daadwerkelijke activiteiten van het pin-invoerprogramma zijn vereist een bijzondere setup, waarbij de reeds draaiende Android-onderdelen ingezien kunnen worden door als root de process-space te lezen met een hex-editor oid. Dan moet je het toestel fysiek binnen bereik hebben en op de achtergrond een Android debug-omgeving kunnen draaien naast het pin-scherm.

Vandaar de keuze om vanaf 6 karakters pas toe te staan. Mijn gok zou zijn dat indien je pin 6 is hij telt bij 6,7 en 8 karakters. Maar bij een pin van 8 lang enkel bij 8.

Dus, ik heb een pin van 6 lang en ik toets:
1,2,3,4,5,6 (hier wordt 1 poging geteld), 7 (nog 1 poging geteld), 8 (totaal 3 pogingen)

Dat lijkt me wel heel rigoureus.

Als je dan een keer misklikt naast 6 en hij beide toetsen pakt (in 7-6 volgorde) heb je meteen 2 fouten.

Ik heb op mijn Samsung een 9-cijferige pincode en krijg geen bolletjes te zien waardoor het voor een aanvaller niet duidelijk is hoe lang de pincode zijn moet

Dit is de reden dat ik het eigenlijk op elke telefoon als optie zie om enterloos te werken. Ik hoop dat Google, voor de mensen die wat meer om hun beveiliging geven, daar gewoon een instelling van zal maken.

Op mijn Samsung telefoon, die deze functie al heeft, heb ik een pincode van 5 getallen.
Als ik 5 foute getallen ingeef, zegt die: "Onjuiste code ingevoerd".
Na 4 foute invoeren, zeg die: "je hebt teveel geprobeerd, probeer over 30 seconden opnieuw".

Je kan het vergelijken dat als je de lengte van de pincode hebt bereikt, deze gewoon vanzelf op enter duwt.
Het enige wat je er dus mee kan uitvogelen, is de lengte van de pincode.

Dat komt doordat bij bruteforce-pogingen om de telefoon te ontgrendelen er een knop minder nodig is om in te drukken en een aanvaller dus sneller de mogelijke opties kan proberen.

Dit is kort door de bocht.
De aanvaller weet doorgaans de lengte van de pincode niet. Maar kan door deze features meerdere pincodes testen zonder op Enter te drukken en vermoedelijk ook zonder bij deze pogingen het toestel tijdelijk te locken.

De codes 123456 1234567 12345678 etc kunnen dadelijk dus getest worden zonder tussendoor telkens opnieuw de eerste 6 cijfers in te voeren (en Enter).

De software vermeldt dat het iets minder veilig is dan op enter moeten drukken. Dat komt doordat bij bruteforce-pogingen om de telefoon te ontgrendelen er een knop minder nodig is om in te drukken en een aanvaller dus sneller de mogelijke opties kan proberen

Volgens mij is het vooral minder veilig omdat de lengte van de pincode zo bekend is bij de aanvaller. Bij een druk op Enter is dat niet zo, want dat kun je op elk moment doen. Als de lengte bekend is verkleint dat het aantal opties om te bruteforcen nogal.

er staat hier dat 'auto-enter' alleen maar werkt bij pincodes van 6 of meer karakters

Bovendien staat er: de telefoon ontgrendeld automatisch bij invoeren van juiste code

Dat betekent dus niet dat je de lengte van de code kan achterhalen!

Stel, mijn code is '654321' en iemand toetst in '123456', dan checkt de telefoon de code, want het is een code van minimaal 6 lang, maar die is niet goed, dus er gebeurd niets, je krijgt ook niet een melding 'dit is niet de goede code'. Als iemand dan nog de '7' erna in toetst, checkt de telefoon de code weer, gebeurt er nog niets, want je code klopt niet. Alleen als je '654321' intypt, dan checkt de telefoon je code, want 6 cijfers of meer, en die is goed dus je bent binnen. Op deze manier lek je geen info over de lengte van de code zonder de code te weten!

Bij mijn OnePlus getest: als ik het juiste aantal cijfers ingeef, maar fout, dan komt erop dat de code fout is. Dat doet hij pas vanaf de juiste lengte, niet al vanaf het eerste fout ingetypte cijfer.
//edit
Nevermind, bij OnePlus is het altijd hetzelfde aantal cijfers blijkbaar

[Reactie gewijzigd door Pieeeeeee op 9 maart 2023 12:59]

Op die manier kan je ook weten dat een wachtwoord niet juist is, want anders werd het meteen aanvaard. Zo kan je dus geautomatiseerd allerlei pogingen beginnen typen en blijven typen want je weet dat het vanzelf geaccepteerd wordt indien het juis was. Dit verhoogt de kans op bruteforcen als men geen manier heeft geïmplementeerd om de boel te vertragen na een aantal "mislukte pogingen".

Volgens mij is het vooral minder veilig omdat de lengte van de pincode zo bekend is bij de aanvaller.

Je kan het zodanig implementeren dat je een PIN-code van (bijvoorbeeld) maximaal 20 cijfers hebt, maar dat na elke invoer (na een minimum aantal getallen) getoetst wordt. Zo weet een aanvaller niet hoe lang de PIN is.

Je hebt dan wel dat je het aantal toegestane pogingen moet verhogen voor mensen die traag tikken, wat een beveiligingsprobleem kan zijn.

[Reactie gewijzigd door The Zep Man op 9 maart 2023 11:48]

Dat lijkt me wel belangrijk - hoe lang wacht je om automatisch op "enter" te duwen in de achtergrond?

Te lang en gebruikers denken dat er iets mis is, en ze hadden graag de "Ok" knop terug gehad
Te kort en iedere succesvolle login (paswoord 123456) heeft voorafgaand 5 mislukte pogingen (1,12,123,1234,12345)

Of je laat melding weg van een foutief password en checkt gewoon bij iedere toetsaanslag direct? Dan kan je actie ondernemen als de juiste cijfers er staan, en anders niets doen. Wel een minder mooie oplossing natuurlijk.

Maar dan is het niet meer te checken of je zoveel keer je passcode verkeerd hebt gedaan waardoor bruteforce makkelijker wordt

Je kan natuurlijk prima een fout tellen als je 6 karakters verwacht worden en er 6 ingevoerd zijn die fout is.

Dit inderdaad.

Volgens mij is dat ook de reden dat veel ATM's nog een 'enter' nodig hebben, omdat (vroeger) je ook een pincode kon kiezen van 5 cijfers

Ik heb al mensen gezien die gewoon een pin van 6 cijfers hebben op hun kaarten.

Los daarvan denk vind ik dat je bij een pinautomaat toch liever een enter wilt hebben. Puur omdat je pas geblokkeerd wordt nadat je 3x een foute pincode invoert. Wat bij een mobiel vaak zorgt voor een korte blokkade van een minuut ofzo (verschilt per merk, software en instelling natuurlijk)

Ik heb zelf wel eens meegemaakt dat ik net die laatste cijfer van mijn pincode verkeerd indruk en dan zou ik niet willen dat de software direct mijn pincode accepteert/invoert. Tuurlijk heb ik daarna nog 2 pogingen, maar het is veiliger om de enter knop handmatig in te moeten drukken.

Wat betreft het artikel. Ik vind het top dat ze deze optie aanbieden. Ik persoonlijk zou de instelling aanvinken puur voor gebruikersgemak (scheelt toch weer tientallen enters per dag) tegenover net dat beetje meer veiligheid.

[Reactie gewijzigd door crobo op 9 maart 2023 12:01]

Creditcards kunnen nog steeds 5 en 6 cijferige pincodes hebben. Dus als je een buitenlandse CC wil ondersteunen kan je er maar beter voor zorgen dat je die ook accepteert.

Vroeger hadden pinautomaten (althans in NL) geen enter. Dat is later ingevoerd.

Dat is een ontwerpkeuze. Het zal inderdaad zo geimplementeerd worden verwacht ik, maar dit hoeft natuurlijk niet. Is alleen aan de orde wanneer je op het aantal karakters van de huidige pincode checkt en dan al een melding wil laten zien dat het incorrect is ingevoerd. Je kunt dat ook negeren, wat minder mooi is, maar waar je gewoon een langere pincode kunt typen tot het max aantal karakters dat mogelijk is. Dan nog kun je hem laten unlocken bij de juiste.

Denk dat een andere onveiligheid is dat je oneindig veel kunt typen zonder echte pogingen te doen waar veiligheidsmaatregelen op kunnen worden toegepast.

De lengte is niet bekend. Het wordt alleen automatisch ingevoerd op het moment dat je de juiste pincode invoert. In principe kan het systeem na elk cijfer controleren of de code correct is en dus accepteren. Maar zolang je het fout intypt zal je dus door kunnen blijven typen. Je geeft dus niet de lengte weg van het wachtwoord.

Wat het wel minder veilig maakt, is wanneer de aanvaller een langere code wil proberen, maar na een X aantal cijfers toch de juiste code heeft en het systeem de aanvaller binnen laat. Stel je code is 13579, en de aanvaller wil 135791113 proberen in te voeren. Dan zal het systeem na de invoer van 13579 al doorgaan. In de situatie van een enter, was de aanvaller doorgegaan met typen en dan pas op enter gedrukt en een foutieve code melding gekregen.

Om een beetje context te geven bij "nogal"

Stel dat je op de simpelste manier brute force doet, dus 0-9, daarna 00-99, daarna 000-999, en het is een 5 cijferige pincode, dan moet je 111.110 pogingen doen in de slechtste situatie, waar het juiste antwoord 99999 is.

Als je aan het begin gewoon nullen kan spammen tot de telefoon de code controleert, dan weet je gelijk bij 5 dat het een 5 cijferige code is.
Daar spaar je dan 11.110 gokken mee uit door alles van 0 tot en met 4 cijfers over te slaan

Stel het gaat om een 8 cijferige pincode, zoals bijvoorbeeld iOS standaard heeft, dan zou je 11.111.110 gokken besparen

Ik zou het dus op mijn telefoon in ieder geval niet willen. Eigenlijk alleen als er helemaal niets gebeurt wanneer de code de juiste lengte heeft, maar onjuist is.

[Reactie gewijzigd door youridv1 op 9 maart 2023 11:55]

Stel het gaat om een 8 cijferige pincode, zoals bijvoorbeeld iOS standaard heeft, dan zou je 11.111.110 gokken besparen

Veel simpeler gezegd: er zijn altijd ongeveer 1/10de minder pogingen nodig als de lengte op voorhand gekend is. Heel veel verschil maakt het niet. Voeg één cijfer toe aan je huidige pincode, en het is gecompenseerd.

Gewoom default bv 4 sterren (minimum lengte aanhouden) laten zien, vervolgens aan vullen met elk extra karakter dat word toegevoegd.

Op deze manier is de hoeveelheid sterretjes niet meer gekoppeld aan de gebruiker.

Los van wat er al gezegd is over de lengte en dergelijke: zelfs een 4-cijferige PIN (wat via brute force tegenwoordig zeer makkelijk is te kraken) wordt sowieso gekoppeld aan timed lockouts bij alle moderne telefoons. Dat betekent dat je na pakweg 4-5 pogingen al aankijkt tegen een wachttijd van eerst 1 minuut, dan 5 minuten, dan 1 uur en uiteindelijk 24 uur zelfs. Kortom: brute force is irrelevant in deze hele discussie.

Neemt niet weg dat het sowieso een goed idee is om een 6-cijferige code aan te maken, want dat maakt het toch in alle andere scenario's waaronder zelfs sociale engineering en ook stiekem meekijken gewoon net iets moeilijker om je code te achterhalen.

Dit bestaat toch allang op Samsung/Android? Ik hoef bij mijn Galaxy iig geen Enter te drukken na het invoeren van mijn PIN.

Dat is ook gewoon een instelling die ik aan/uit kan zetten.

[Reactie gewijzigd door XelaRetak op 9 maart 2023 12:09]

Dat is omdat "Samsung/Android" iets anders is dan een kale Android installatie. Samsung, en de meeste andere fabrikanten, geven je niet de standaardversie maar een aangepaste versie met extra functies.

Niet erg interesant nieuw dus. Hoeveel % gebruikt nou echt stock Android, dat zal niet veel zijn.

Dat zeg je verkeerd: niet alle fabrikanten hebben dit geïmplementeerd. Daarnaast is het ook zo dat het gewoon een goed idee is dat Android dit een standaard feature maakt, want dan kan Google hier eenheid in aanbrengen en hoeft niet iedere fabrikant zijn eigen variant erop na te houden. Is ook weer 1 feature minder die fabrikanten zelf in een nieuwe major OS versie moeten testen en dus telt dit in het grotere geheel op bij de stap naar steeds snellere OS releases van fabrikanten. Want dit is nu net dé reden waarom het maanden duurt voordat fabrikant A-Z hun Android versie ook naar de laatste major versie updaten. Ik kreeg op mijn Xiaomi vorige maand Android 13, terwijl Google het al in augustus vorig jaar uitgebracht heeft.

De Pixel is (qua instellingen) stock en wint markt. Daarnaast zie je de functies die in stock Android komen dus wel terug in Android van alle fabrikanten, zoals MooDyBLueS ook al zegt. Dat betekent dat naast jouw Samsung straks ook 10 andere merken dit hebben, die geen stock Android draaien, maar deze functie ook nog niet custom hadden ingebouwd.

Geen idee hoe het kan, maar op mijn A52S kan dit allang.

Dat komt omdat een kale onbewerkte Android niet echt iets is wat de doorsnee persoon gebruikt. Die gebruiken een variant van Android, bewerkt en uitgebreid door de fabrikant. In jouw geval Samsung, die heeft dit inderdaad al langer geimplementeerd. Nu dus ook een functie in de standaardversie.

Staat gewoon uitgelegd in het artikel 'hoe het kan' dat jij dat al wel hebt!

Omdat je een ROM gebruikt van een fabrikant die dit zelf geïmplementeerd heeft. Ik weet sowieso dat Samsung en Xiaomi dit al jaren hebben. Samsung heb ik gehad, Xiaomi heb ik nu.

In de USA wordt steeds vaker melding gemaakt van het (in de kroeg of OV) afkijken van de ontgrendel-pincode, het daarna stelen van de smartphone (vooral iPhones) en vervolgens het plunderen van bankrekeningen, afsluiten van leningen etc. op naam van de legitieme eigenaar, het kapen van iCloud en andere accounts (door toegang tot e-mail en SMS).

Tenzij je The Wall Street Journal al een tijd niet bezocht hebt zit dit m.i. uitstekende artikel + video helaas achter een pay-wall, maar ik kon het nogmaals bekijken door de browsergeschiedenis te wissen én via 4G (i.p.v. WiFi) de pagina te openen.

Bank wordt lastig of ze moeten ook de pincode van mijn bank app afkijken. Maar wellicht hebben andere banken een app waar dat dan niet hoeft.

Kwalijker is dat in iOS alle wachtwoorden in de Keychain wel te lezen zijn meer je passcode. Daar zou een extra check van je iCloud wachtwoord of een separate code helpen.

Gelukkig gebruik ik gezichtsherkenning dus in het OV hoef ik mijn code niet in te tikken

[Reactie gewijzigd door mjl op 9 maart 2023 14:12]

Door mjl:

Bank wordt lastig of ze moeten ook de pincode van mijn bank app afkijken. Maar wellicht hebben andere banken een app waar dat dan niet hoeft.

De vraag is wat er gebeurt als "jij" (de identiteitsfraudeur) aangeeft dat je jouw pincode vergeten bent. Met toegang tot telefoonnummer, e-mail en vaak in foto's op de telefoon gevonden identificerende gegevens (zoals een foto van een paspoort) kunnen identiteitsfraudeurs vaak onverwacht grote schade aanrichten.

Door mjl:

Kwalijker is dat in iOS alle wachtwoorden in de Keychain wel te lezen zijn meer je passcode. Daar zou een extra check van je iCloud wachtwoord of een separate code helpen.

Eens. Het eeuwige probleem is dat de meeste mensen overal dezelfde pincodes en/of wachtwoorden voor gebruiken, en dat de pincode vaak de postcode of een gevoortedatum is.

Door mjl:

Gelukkig gebruik ik gezichtsherkenning dus in het OV hoef ik mijn code niet in te tikken

Vingerafdruk- en gezichtsscanners zijn veel minder dan 100% betrouwbaar, maar een afgekeken pincode lijkt mij 100% onbetrouwbaar. Het zijn vaak lastige afwegingen die erg van de bezigheden (en dus risico's) van een persoon af kunnen hangen.

Zelf gebruik ik mijn pink op de vingerafdrukscanner en ben regelmatig aan het schelden als ik weer eens mijn (lange) wachtwoord moet invoeren, want dat komt altijd op een onhandig moment (maar het zorgt er wel voor dat ik dat lange wachtwoord kan onthouden).

Inderdaad met een telefoon heb je al heel snel persoonlijke ID gevoelige data, echter direct je rekening leeg trekken via de bankapp gaat met bijv de Rabo app en de ICS app van visa niet zomaar lukken omdat daar een andere code op zit (zolang je die dus niet hetzelfde ingesteld hebt).

Ik zou me meer zorgen maken over mijn creditcard pasje dat in mijn telefoon hoesje zit.

Ik mopper ook regelmatig in mezelf als ik het wachtwoord van KeePass weer moet invullen als gezichtsherkenning het niet wil doen denk dat we er redelijk hetzelfde in staan

Net ook even getest, KeePass vraagt om het wachtwoord van je KeePass file en niet om je pincode als faceid niet lukt.

De wachtwoorden in je iPhone Keychain kan je wel uitlezen met de pincode van je telefoon.

Dit soort berichten zetten je wel weer goed aan het denken over de risico’s rond het beheren van je ‘secrets’ informatie.

[Reactie gewijzigd door mjl op 9 maart 2023 15:43]

Vrijwel elke fabrikant op google na gebruikt deze optie al. Vind het persoonlijk ook fijner, als ik eens per 3 dagen gevraagd wordt om de code in te vullen ipv mijn vingerafdruk.

Zo zeg. Hoefde op m'n Windows 10 mobile telefoon vroeger ook niet. Oude tijden herleven!

TIL dat dit geen standaard feature is. Ik ben precies al jaren niks anders gewoon. (Samsung)

Tegenwoordig ben ik het meer gewend om niets in te hoeven toetsen (nou ja, 1 keer per dag dan), gezichtsherkenning werkt best aardig.

Voor mij geldt hetzelfde. Ben primair een iPhone gebruiker, maar heb daarnaast ook een Samsung gehad en nu een Xiaomi, bij beide hoef ik niks te bevestigen na mijn juist PIN. Altijd gedacht dat het gewoon onderdeel van Android was, niet dus.

Op mobiel laat de crop van de afbeelding de bovenste rij wegvallen, waardoor de focus op de onderste, niet gerelateerde, optie komt te liggen. Best verwarrend.