Hoe werkt 2fa op oude Apple software?

[Heedless]

Als je een heel oud iOS apparaat hebt, zoals een eerste iPad, dan heeft die geen ondersteuning voor 2fa: je kan alleen je wachtwoord invullen in bijv. de appstore, maar geen 2fa code.

Apple heeft daar wat op gevonden: na het invullen van je wachtwoord krijg je de 2fa code op een ander apparaat. Vervolgens vul je je wachtwoord nogmaals in op het oude apparaat, maar deze keer met de code er meteen achteraan.

Maar hoe werkt dat?

Wachtwoorden in plaintext opslaan is al jaren not-done. Vaak maken ze er bij het aanmaken van een wachtwoord een hash van die de database in gaat. Bij het inloggen maken ze weer een hash van wat je invult en vergelijken dat met de versie in de database.

Maar als je het wachtwoord invult en die 2fa code er aan plakt, dan krijg je toch een heel andere hash?
Het lijkt mij niet dat de oude iOS het wachtwoord en de 2fa code los verstuurt; daarvoor had de broncode aangepast moeten worden en dan hadden ze er net zo goed gewoon een 2fa veld bij kunnen bouwen lijkt mij.

Of zou je ingevulde wachtwoord in plaintext naar de server gaan, die vervolgens de laatste 6 tekens er af haalt om te vergelijken met de 2fa code? Lijkt mij ook niet heel netjes.

Iemand enig idee (of een goede gok) van hoe dit zou kunnen werken?

-> Tekstje hier over bij MacWorld

[RobIII]

Stel:

code:

wachtwoord = "appelflap"
hash(wachtwoord) = 295f73d44297a4a2de973bdd300b8270
2facode = 123456

result = hash(hash(wachtwoord) + 2facode) = 6f1bbc554ab9976c05e505774c8f73a5

Je hebt geen wachtwoord nodig, je kunt gewoon kijken of de hash die de gebruiker stuurt (6f...) gelijk is aan de hash + 2facode (die je beide hebt server-side).

(Technisch gezien zul je, potentieel, een aantal 2FA codes moeten doorrekenen vanwege mogelijke tijdverschillen tussen client en server, maar dat is een ander verhaal; het zullen er hooguit een hand (of twee) vol zijn).

[ Voor 26% gewijzigd door RobIII op 21-06-2022 16:47 ]

[DataGhost]

RobIII schreef op dinsdag 21 juni 2022 @ 16:45:
Stel:

code:

wachtwoord = "appelflap"
hash(wachtwoord) = 295f73d44297a4a2de973bdd300b8270
2facode = 123456

result = hash(hash(wachtwoord) + 2facode) = 6f1bbc554ab9976c05e505774c8f73a5

Je hebt geen wachtwoord nodig, je kunt gewoon kijken of de hash die de gebruiker stuurt (6f...) gelijk is aan de hash + 2facode (die je beide hebt server-side).

(Technisch gezien zul je, potentieel, een aantal 2FA codes moeten doorrekenen vanwege mogelijke tijdverschillen tussen client en server, maar dat is een ander verhaal; het zullen er hooguit een hand (of twee) vol zijn).

Dat werkt natuurlijk niet als het oude device hier niet van op de hoogte is en hash(wachtwoord + 2facode) doorstuurt. Ik denk dat het alleen maar kan als het wachtwoord plaintext (via TLS wel) doorgestuurd wordt en het hashen ter controle pas op de server gebeurt.

[RobIII]

DataGhost schreef op dinsdag 21 juni 2022 @ 16:50:
[...]

Dat werkt natuurlijk niet als het oude device hier niet van op de hoogte is

Goeiemorgen. Je hebt helemaal gelijk. My bad. Is 't al weekend?

[--MeAngry--]

Lijkt me sterk dat het wachtwoord al gehashed naar de server wordt gestuurd. Dat is namelijk net zo (on)veilig als het plaintext opsturen, want uiteindelijk vergelijkt de server nog steeds 2 strings, of het nou gehashed is of niet.

De hashing gebeurt dus altijd op de server, en daardoor kan het wachtwoord ook prima van de 2FA code gescheiden worden. En gezien je 2FA code als het goed is nog steeds maar 1 keer, of heel kort geldig is, verhoogt het nog steeds de beveiliging.

[ Voor 35% gewijzigd door --MeAngry-- op 21-06-2022 16:57 ]

[DataGhost]

--MeAngry-- schreef op dinsdag 21 juni 2022 @ 16:53:
Lijkt me sterk dat het wachtwoord al gehashed naar de server wordt gestuurd. Dat is namelijk net zo onveilig als het plaintext opsturen, want uiteindelijk vergelijkt de server nog steeds 2 strings, of het nou gehashed is of niet.

Dat gebeurt tegenwoordig wel vaker bij de wat meer secure oplossingen, alleen vaak ook met een challenge en zowel aan client- als serverzijde een aantal iteraties van het hashalgoritme. Voordeel daarvan is dat de plaintext-versie van het wachtwoord niet over de lijn gaat waarmee hopelijk credential stuffing wordt tegengegaan. Maar volgens mij valt het nog wel tegen hoe gangbaar dit is op bijvoorbeeld websites.

[--MeAngry--]

DataGhost schreef op dinsdag 21 juni 2022 @ 16:56:
[...]

Dat gebeurt tegenwoordig wel vaker bij de wat meer secure oplossingen, alleen vaak ook met een challenge en zowel aan client- als serverzijde een aantal iteraties van het hashalgoritme. Voordeel daarvan is dat de plaintext-versie van het wachtwoord niet over de lijn gaat waarmee hopelijk credential stuffing wordt tegengegaan. Maar volgens mij valt het nog wel tegen hoe gangbaar dit is op bijvoorbeeld websites.

Ja goed, het kan uiteraard wel, maar dat lijkt me hier niet van toepassing.

[Heedless]

Het gaat hier natuurlijk om 'heel' oude code, dus lokale hashing zal hij waarschijnlijk inderdaad niet doen.
Moet eigenlijk zeggen dat ik niet helemaal weet waarom ik er vanuit ging dat het hashen op de client zou gebeuren, dat is/was inderdaad helemaal niet gangbaar

Je verbinding is inderdaad (hopelijk) versleuteld maar je input gaat verder gewoon zo die kant op, en de server trekt je wachtwoord en 2fa code uit elkaar voordat hij het wachtwoord deel hasht om te kunnen vergelijken met de database.
Het idee van die hash is natuurlijk vooral om te zorgen dat er bij diefstal niets te lezen valt en heeft niet direct iets te maken met het transport van je info.

Hoe dan ook, ik vind het een slimme tussenoplossing van ze om toch je 2fa code te kunnen gebruiken in een systeem dat er oorspronkelijk niet voor ontworpen was