Data klein aantal gebruikers van 2fa-app Authy ingezien bij hack moederbedrijf

De data van een klein aantal gebruikers van Authy, een app voor tweetrapsauthenticatie, is buitgemaakt bij een hack van moederbedrijf Twilio. Het gaat in totaal om 125 gebruikers, zo meldt het bedrijf.

Het is onbekend bij welke data de aanvallers precies konden, maar het gaat niet om wachtwoorden, tokens of api-keys, meldt Twilio. Met wachtwoorden en tokens zouden de aanvallers codes kunnen genereren namens die gebruikers en toegang krijgen tot accounts. Als gebruikers geen bericht hebben gehad van het bedrijf, betekent het volgens Twilio dat er geen bewijs is dat aanvallers bij hun data konden.

Authy is een app voor Android en iOS die toegang mogelijk maakt met tweetrapsauthenticatie en geldt als concurrent voor bijvoorbeeld de authenticator-apps van Google en Microsoft. Twilio zegt niet hoeveel gebruikers Authy heeft.

De hack was mogelijk doordat medewerkers in een gerichte phishing-aanval waren getrapt. De medewerkers kregen een sms met de mededeling dat een wachtwoord was verlopen en een verzoek om een nieuwe aan te maken. Zij zagen die aan voor berichten van de eigen IT-afdeling en klikten dus op de links.

Het bedrijf gaat onderzoek doen naar het incident en zegt dat het gefrustreerd is over de gang van zaken. Ook heeft het contact met Amerikaanse providers om het spoofen van de sms'jes niet langer mogelijk te maken.

Reacties (68)

[MaDMaRTiGaN648]

Ik lees in het bericht van Twilio nergens dat bij de hack gegevens van Authy gebruikers zijn ingezien.

[ex87]

Ja, ik heb ook verder zitten zoeken (artikel, andere nieuwsbronnen) maar overal (behalve op Tweakers) wordt er gesproken over Twilio data, niet Authy.

[g_v_rijn]

Als hacker zou ik mij ook 'voorlopig' stil houden.

[DRaakje]

Wachtwoorden worden niet standaard bij authy bewaard, als je dit doet heb je een encryption wachtwoord nodig.

Backups are encrypted prior to upload
Let’s set the record straight on how we handle encryption. For your convenience, Authy can store an encrypted copy of your Authenticator accounts in the cloud. The account is encrypted/decrypted inside your phone, so neither Authy or anyone affiliated with Authy have access to your accounts.

How the Authy key backups work:
Backups are executed in several steps:

We ask you to enter a password. Passwords must be 6 characters long, although we recommend that you aim for at least 8 characters.
Your password is then salted and run through a key derivation function called PBKDF2, which stands for Password-Based Key Derivation Function 2. PBKDF2 is a key stretching algorithm used to hash passwords in such a way that brute-force attacks are less effective. The details of how this is done are quite important:
We use a secure hash algorithm that is is one of the strongest hash functions available. It’s a one-way function – it cannot be decrypted back and is one of the strongest hash functions available.
We use 1000 rounds. This number will increase as the low range Android phone’s processor power increases.
We salt the password before starting the 1000 rounds.
The salt is generated using a secure random value.
Using the derived key, each authenticator key is encrypted with Advanced Encryption Standard AES-256, in Cipher Block Chaining (CBC) mode along with a different initialization vector (IV) for each account. To make each message unique, an IV must be used in the first block.
If any Authenticator keys are 128 bits or less, we pad them using PKCS#5.
Only the encrypted result, salt, and IV are sent to Authy. The encryption/decryption key is never transmitted.

bron

[Reactie gewijzigd door DRaakje op 24 juli 2024 01:54]

[RVervuurt]

De hack was mogelijk doordat medewerkers in een gerichte phishing-aanval waren getrapt. De medewerkers kregen een sms met de mededeling dat een wachtwoord was verlopen en een verzoek om een nieuwe aan te maken. Zij zagen die aan voor berichten van de eigen IT-afdeling en klikten dus op de links.

Ik snap dat de mens altijd de zwakste schakel is in de security van een platform of dienst, maar zeker in het geval van iets als Authy is het toch wel heel ironisch dat het op deze manier gebeurt.

[Anoniem: 1322]

Ironisch zeker maar er zit ook raar smaakje aan dit verhaal.
Het hele punt van 2FA (authy is een 2FA app) is dat het niet uitmaakt dat je inlognaam/wachtwoord lekt gezien je daarna nog de 2FA code nodig hebt. Inloggegevens lekken dagelijks met miljoenen tegelijk daarom hebben we MFA nodig op alles.

Dus een klik op die link zou de medewerkers nog niet in gevaar brengen (anders dat ze verplicht hun wachtwoord moeten resetten). Ze hebben blijkbaar diensten draaien die dus met enkel inlognaam en wachtwoord beschikbaar zijn. Dat is extra ironisch...

Ik heb het ooit gebruikt omdat ik niet aan MS of Google vast wil zitten maar ondertussen ben ik over naar het open-source Tofu (IOS only helaas). Die draait helemaal offline.

[Reactie gewijzigd door Anoniem: 1322 op 24 juli 2024 01:54]

[RVervuurt]

Als die neppe site ook een 2FA-veld heeft, en ze dit netjes invullen, kan die 2FA gewoon gebruikt worden door de hackers. Zover ik weet is een 2FA-code 60 seconden geldig: 30 seconden zichtbaar en daarna nog 30 seconden terwijl deze in de app is vervangen voor een nieuwe.

Zeker als hackers het automatiseren, is 60 seconden ruim voldoende om een account binnen te komen.

De reden dat ik Authy gebruik is de backupmogelijkheid en synchronisering tussen apparaten. Op deze manier hoef ik niet op alle accounts m'n 2FA uit en aan te zetten als ik een nieuwe telefoon krijg bijvoorbeeld.

[batjes]

2FA codes zijn doorgaans langer dan 60seconden bruikbaar. Anders zouden ze onbruikbaar zijn want niemands telefoon heeft zijn/haar tijd tot op de seconde gelijk als de website of SSO waar je op probeert in te loggen.

[DataGhost]

Vrijwel alle recente apparaten (PC's, telefoons, tablets, servers, etc) gebruiken tegenwoordig standaard NTP, GPS en/of het mobiele netwerk waarmee ze verbonden zijn om uiteindelijk tot op de seconde gelijk te lopen met alle andere apparaten. De RFC raadt dan ook aan om by default effectief een window van 60 tot 90 seconden aan te houden (afhankelijk van het precieze moment waarop het OTP gegenereerd wordt). Daarmee ondervang je latency-problemen en heeft de gebruiker inderdaad een beetje tijd om de code over te typen. Het wordt over het algemeen het probleem van de gebruiker gevonden als deze anno 2022 geen tijdssynchronisatie gebruikt. Je moet er namelijk moeite voor doen om het uit te zetten.

[Reactie gewijzigd door DataGhost op 24 juli 2024 01:54]

[jacobras]

Ja, tijd synchroniseert automatisch maar je kan er niet vanuit gaan dat het het daarmee overal goed werkt. Op Android-apparaten, bijvoorbeeld, kan de tijd best verschillen. Ik heb een jaartje of anderhalf geleden flink wat smartphones vergeleken en vooral de wat oudere Samsungs vielen op omdat ze soms wel minuten afweken — tot een herstart. Veel Android smartphones lijken alleen een synchronisatie te doen bij het opstarten en vervolgens niet meer. Op modernere Pixels nooit langer dan een paar seconden afwijking gezien.

In de praktijk doen apps vaak zelf een interne tijdsynchronisatie. Gewoon even de afwijking opvragen en vervolgens daarmee doorrekenen. Ik vermoed dat elk stuk software met 2FA dat wel doet, in ieder geval in de mobiele apps.

[McBacon]

Android 11 en lager prefereren NITZ boven NTP, maar je kan als gebruiker voor zover ik weet niet eens iets aanpassen/instellen m.b.t. NTP. NITZ is alleen redelijk inaccuraat; de tijd tussen mijn laptop (met NTP) en telefoon verschilt vrijwel altijd zo'n 3-4 minuten en dat gebeurt bij meerdere providers. Je kunt ook niet even handmatig een NITZ-sync doen, alleen bij reboot en periodiek (volgens mij elke paar weken) checkt ie de tijd weer. NTP-servers worden bij mij gewoon via DHCP doorgegeven en toch gebruikt Android ze dus niet. Ik heb geen zin om iedere keer mijn 2FA-app de time offset te laten corrigeren, dus ik heb automatische tijd maar gewoon uitgezet en de klok 1 keer handmatig gelijk gezet met mijn laptop. Andersom accepteerden veel sites mijn codes niet meer, dus de tijd die ik via NITZ krijg is daadwerkelijk verkeerd.

[DataGhost]

Klinkt gek en ligt misschien aan gebruikersinstellingen of aan je fabrikant. Ik gebruik Android nu sinds versie 7 ofzo (Samsung) en altijd is de tijd fatsoenlijk gesynchroniseerd geweest. Daarbij kan ik me voorstellen dat fabrikanten prima die prioriteit kunnen aanpassen (wat nu in 12 default is) en ook dat bij gebruik van GPS de tijd automatisch daarmee gesynchroniseerd wordt, dat zou ik zelf doen in ieder geval want die krijg je helemaal gratis uit het signaal. Dus als je telefoon echt geen NTP gebruikt en je je locatie altijd uit hebt staan kan ik me daar een beetje bij voorstellen, anders niet. En aan je netwerk kan het ook liggen natuurlijk.

[McBacon]

Nouja, voor NITZ zíjn er geen gebruikersinstellingen. Of je moet het schuifje "tijd automatisch synchroniseren" meetellen. Overigens heb ik locatieservices standaard gewoon aan staan. Het klopt dat nu met Android 12 NTP de default is boven NITZ, maar dat verandert niks aan je opmerking dat elk beetje modern device correcte tijd bijhoudt. ;] Android 11 is immers ook "beetje modern" en toch is er online genoeg te vinden m.b.t. problemen met tijdssynchronisatie.

[lenwar]

Anders zouden ze onbruikbaar zijn want niemands telefoon heeft zijn/haar tijd tot op de seconde gelijk als de website of SSO waar je op probeert in te loggen.

Ik denk zelf dat dit in de praktijk meevalt. Allicht niet letterlijk op de seconden, maar wel dichtbij genoeg.

Vrijwel iedere computer/telefoon/tablet/enz praat wel met een één of andere NTP-server of ander type tijd-server. De meeste computerklokken zijn goed genoeg om een kleinere afwijking dan 5 seconden per week te krijgen zonder tussentijdse synchronisatie.

Het voornaamste probleem zit hem in de vertraging van de gebruiker. Het overtypen kan voor sommige mensen redelijk problematisch zijn. Zeker as je TOTP-token op hetzelfde apparaat staat als waar je op wil inloggen.
Dus van browser naar 'home', zoeken naar je TOTP-app. De token onthouden/kopieren, terug naar home en naar je browser en het invulveld opnieuw aanklikken voordat je gaat overtypen of plakken. Uiteraard zijn er zat mechanismen die dit versimpelen/versnellen, maar niet iedereen gebruikt dit.

[vbmot]

En bij meer dan 4 cijfers soms nog een keer terug swipen naar de 2FA app als copy/paste niet goed wordt ondersteund. Er gaat al snel redelijk veel tijd inzitten en voor veel gebruikers is het een bron van irritatie. Als dan ook nog de code snel verloopt, zullen veel gebruikers het systeem geheel dumpen mits ze daar de mogelijkheid voor hebben.

[Rannasha]

2FA codes zijn doorgaans langer dan 60seconden bruikbaar. Anders zouden ze onbruikbaar zijn want niemands telefoon heeft zijn/haar tijd tot op de seconde gelijk als de website of SSO waar je op probeert in te loggen.

Naast wat al genoemd is over het feit dat de meeste apparaten tegenwoordig hun klok syncen met een tijdserver, zijn er nog andere methodes om klok-drift te compenseren.

Bij het aanzetten van 2FA wordt je gevraagd om een code in te voeren ter controle. Wanneer dit gebeurt, kan de server een lange reeks codes genereren, overeenkomend met een tijdspanne van meerdere minuten, en kijken waar de ingevoerde code valt in die reeks. Aan de hand daarvan kan een klok-drift van de gebruiker worden vastgesteld en opgeslagen.

Bij volgende inlogpogingen kan die klok-drift worden gebruikt om de nieuwe code te controleren. Zolang de klok van het apparaat van de gebruiker niet sterk veranderd in korte tijd en gewoon 60 seconden per minuut blijft tikken, zal een verschil in tijd tussen gebruiker en server niet noodzakelijk een probleem opleveren.

Maar goed, dit werkt alleen als de aanbieder van de dienst de functionaliteit zo heeft geimplementeerd.

[TheVivaldi]

Als die neppe site ook een 2FA-veld heeft, en ze dit netjes invullen, kan die 2FA gewoon gebruikt worden door de hackers.

Dat vind ik toch wel opvallend, want telkens als het hier over 2fa gaat, dan zijn een hoop tweakers niet gecharmeerd van sms want onveilig en wordt keer op keer gezegd "met een 2fa-app kunnen dit soort dingen niet gebeuren". Maar blijkbaar is in het geval van een lek als dit een 2fa-app dus ook niet 100% veilig.

[ThoffeGast]

Het is natuurlijk prachtig nieuws, een beveiligingsbedrijf (om het maar even simpel zo te noemen) die zelf 'gehackt' wordt.

Maar in de praktijk is authy nog steeds 100% veilig te noemen. Er zijn namelijk ten eerste geen (gehashte) gegevens van klanten uitgelekt, dus geen wachtwoorden of tokens van je 2fa sleutels.

En ten tweede, als deze wel gelekt zouden zijn, zijn deze met de manier waarop ze versleuteld zijn zo goed als onmogelijk te kraken, zeker niet in korte tijd. (en in die tijd had je al een mail gehad met instructies om de boel weer veilig te maken).

juist het feit dat de hack dmv sms spoofing is gebeurd, geeft opnieuw aan hoe onveilig sms eigenlijk is. Dus ja, TL;DR; 2fa app = veiligst, sms = onveilig, gebruiker = weakest link

[vrow]

Je reactie is helemaal goed, tot het einde :-)

SMS voor 2FA is niet per sé onveilig vanwege de mogelijkheid tot spoofing.
Alles is te spoofen: websites worden nagemaakt, brieven van de belastingdienst, e-mails…
Het gaat erom dat je nooit moet klikken op een link, ongeacht hoe je die ontvangt.

De reden dat 2FA-codes via sms relatief onveilig zijn, is omdat het relatief eenvoudig is om een sim kaart van iemand anders (ander nummer) te bemachtigen. Maar ook in de praktijk is dat nog lastig genoeg voor menig hacker van aan de andere kant van de wereld. Het moet dan vaak al echt een gerichte aanval tegen jou persoonlijk zijn. 2FA via sms is nog altijd veel veiliger dan helemaal geen 2FA.
Ik wacht nog steeds op de echte doorbraak van Fido2… Prachtige techniek maar helaas nog niet doorgebroken bij het grote publiek.

Ik denk dat daar ook een taak voor banken of de overheid ligt. Combineer dit op een handige manier in de bankier-app of met DigiD zodat iedereen het standaard al heeft en heel makkelijk kan gaan gebruiken. iDin was een poging maar is ook ergens gestrand. Er komt wel eer weer een uitbreiding van iDeal aan waarmee je ook kan inloggen en je adres ed. kan bewaren. Maar even kijken wat dat wordt. Mooier was het als beide gewoon volgens Fido2 werkten.
Ik krijg ook alweer een punthoofd van bank-app, DigiD, Battle.Net authenticator, Steam guard en ga zo maar door….

[RVervuurt]

Het "lek" was hier een mens, niet 2FA.

[DataGhost]

Vrijwel geen enkel bedrijf heeft mijn telefoonnummer echt ergens voor nodig dus die krijgen ze ook niet. Zeker niet voor iets onveiligs als 2FA via SMS, wat dus afhankelijk is van het bij hebben en werken van mijn telefoon en het betreffende nummer, vooral in het buitenland wil ik nog wel eens een lokale SIM hebben waardoor het niet eens bruikbaar is. Verder is dat relatief makkelijk af te luisteren of dmv lekke procedures bij een provider aan een extra/nieuwe SIM te komen waardoor een aanvaller dus eventueel zonder mijn telefoon/toestemming/2FA-app toch aan mijn 2FA-code kan komen.

Door de manier waarop deze hack is gegaan, phishing, maakt de gebruikte 2FA-methode niet echt uit aangezien de gebruiker zelf de code invoert. Maar bij 2FA dmv SMS is de gebruiker deels of volledig overbodig dus, en kan je de boel veel simpeler maken zeker als je de credentials al uit een of andere hack/leak hebt verkregen.

[addictive_rhymz]

Lol weer wat geleerd. Ik gebruik ook authy en als de timer bijna voorbij is dan wacht ik altijd op de volgende code. Is dus blijkbaar niet nodig

[RVervuurt]

Dat geldt voor alle 2FA-keys (blijkbaar tot 90 seconden, afhankelijk van de implementatie), niet alleen in Authy

[vrow]

Inderdaad, als je een code in beeld hebt, werkt die code, maar ook de vorige en de volgende werken over het algemeen.

[Anoniem: 1322]

Klopt, ik was vergeten te vermelden dat het ook een geavanceerde aanval zou kunnen zijn. Dat zou de aanval echter wel veel complexer maken (want de verdere hacka acties moeten dan ook geautomatiseerd worden gezien de korte lifetime van de token).

De reden dat ik Authy gebruik is de backupmogelijkheid en synchronisering tussen apparaten. Op deze manier hoef ik niet op alle accounts m'n 2FA uit en aan te zetten als ik een nieuwe telefoon krijg bijvoorbeeld.
Yep, dat was ook een reden voor mij om Authy te gebruiken. Maar dat gaat wel een beetje in tegen het idee van MFA. Ze hebben namelijk ook een desktop app (die ik ook gebruikte) en dan ga je snel al je kroonjuwelen op dezelfde locatie opslaan. Open-source heeft daarnaast ook mijn voorkeur indien mogelijk

[g_v_rijn]

Handig dat wel. Maar of het ook veilig genoeg is... geen idee.
Oplossing 1) SMS niet meer toestaan.
of
Oplossing 2) Offline App gebruiken.

[Reactie gewijzigd door g_v_rijn op 24 juli 2024 01:54]

[pbruins84]

Dus een klik op die link zou de medewerkers nog niet in gevaar brengen (anders dat ze verplicht hun wachtwoord moeten resetten). Ze hebben blijkbaar diensten draaien die dus met enkel inlognaam en wachtwoord beschikbaar zijn. Dat is extra ironisch...

Hoe kom je tot die conclusie? De 2FA code kan toch net zo makkelijk worden buitgemaakt via phishing als de gebruikersnaam en wachtwoord?

Toevoeging: MFA op basis van OTP beschermt in de meeste gevallen niet tegen phishing. Dan heb je zoiets nodig als Fido2 / U2F.

[Reactie gewijzigd door pbruins84 op 24 juli 2024 01:54]

[Anoniem: 1322]

Hoe kom je tot die conclusie? De 2FA code kan toch net zo makkelijk worden buitgemaakt via phishing als de gebruikersnaam en wachtwoord?
Zo staat het in het artikel. Ze hebben een link aangeklikt (om hun wachtwoord te veranderen).
Een aanval die 2FA codes in acht neemt is tevens veel complexer gezien de levensduur van de token (meestal 30 seconden tot een minuut). Je moet dan ook in de back-end direct een sessie opzetten met de ingevulde data om de aanval succesvol af te ronden (zodat je een sessie cookie of token behoudt). Dat brengt echter ook weer complexiteit met zich mee want je wil niet jouw IP vrijgeven (bij het aanvragen van de sessie). Dit soort aanvallen zijn zeldzaam vanwege de complexiteit maar ik zie nu dat er al best wat toolkits voor zijn zoals Muraena.

[Sniels]

Complex kun je het niet meer noemen met toolkits als EvilGinx2 naar mijn mening. En helaas worden ze ook steeds minder zeldzaam.

[Reactie gewijzigd door Sniels op 24 juli 2024 01:54]

[Anoniem: 1322]

Ontwikkelingen van open-source projecten gaan altijd sneller dan ik dacht

[Xm0ur3r]

Nou inderdaad, ik snap dan ook niet zo goed hoe dit kan want blijkbaar konden ze iets met het wachtwoord en stond er geen 2fa ingesteld... Als iemand een voorbeeld zou moeten nemen; nu vraag ik mij eigenlijk af of ik hier nog een gedeelte van mijn tokens wil laten genereren.

[emphy]

Als de gebruiker de 2fa uit de app in de phishing-site invoert kan de aanvaller alsnog bij het account totdat hij iets probeert waarbij nóg een keer een 2fa code moet worden ingevoerd.

Ik heb het vermoeden dat er dus wel 2fa gebruikt werd, maar dat na inloggen het nog (tijdelijk) mogelijk was om met de zelfde 2fa code bij gebruikersdata te komen.

[Reactie gewijzigd door emphy op 24 juli 2024 01:54]

[Johan9711]

Goede kans dat er een SSO oplossing word gebruikt zoals OKTA, dat zie je ook aan de gerichte phishing voorbeelden in het artikel. Dan is er gewoon een bepaalde sessieduur, en in die periode kan je doen wat je wilt zolang je maar ge-authenticeerd bent in OKTA zelf.
Oplossing zou zijn om bepaalde handelingen extra af te schermen met 2FA, zoals het inzien en aanpassen van gebruikersdata.

[MacPoedel]

De aanvallers sturen de slachtoffers naar een website waar de 2fa code ingevoerd kon worden, die de aanvaller dan snel op de echte login pagina kan invoeren. Zo was het toch bij Cloudflare, waar ongeveer gelijktijdig phishing aanvallen gebeurden (https://blog.cloudflare.com/2022-07-sms-phishing-attacks/).

Bij Cloudflare kon de aanval daar niet verder omdat zij fysieke 2fa sleutels (bv Yubikey) vereisen.

[jpsch]

Schijnbaar zat er een link in het SMS'je. Dat moet je toch niet willen.

[kozue]

Ik denk eerder dat de SMS client er automatisch een link van maakt omdat het een URL herkent. URL's doorsturen via SMS lijkt me toch geen onredelijke functie? Hoe moet je anders een link delen via SMS?
(en kom nu niet aan met "dan moet je geen verouderde SMS gebruiken", want dit is net zo goed van toepassing op andere messengers)

[jpsch]

Een melding dat je wachtwoord gewijzigd moet worden is toch voldoende?
Als ik een melding van de belastingdienst krijg, zit er BEWUST geen link bij, om te zorgen dat je inlogt bij de belastingdienst en niet een of andere gefingeerde inlogsite.

[kozue]

Ik denk dat je van de belastingdienst geen link krijgt omdat die lang en complex zou zijn en niet in een sms past. Niet om de reden die jij aangeeft. In een echte sms van de belastingdienst zit nooit een fake link, en als de sms niet van de belastingdienst maar van een aanvaller komt, houdt niets hem tegen daar alsnog een link in te zetten.

[MaxxBass]

Wellicht zit die er normaal niet in, maar in dit bericht wel. Heel menselijk om dan als je het vertrouwt op de link te klikken... Ook dom... Maar heel menselijk...

Typo

[Merik]

Blijkbaar was dit een van de meer geraffineerde aanvallen. Een andere aanval was gericht op Cloudflare, waar deze niet effectief was doordat elke werknemer gebruik maakt van (fysieke) FIDO-2 authentificatie methodes. https://arstechnica.com/i...ing-workers-home-numbers/

Uit het artikel:

The threat actor carried out its attack with almost surgical precision. When the attacks on Cloudflare, at least 76 employees received a message in the first minute. The messages came from a variety of phone numbers belonging to T-Mobile. The domain used in the attack had been registered only 40 minutes prior, thwarting the domain protection Cloudflare uses to ferret out impostor sites.

[Reactie gewijzigd door Merik op 24 juli 2024 01:54]

[haam]

Waarom zou een IT afdeling een link in een SMS (willen) zetten?

Volgens mij zou je als policy moeten hebben dat er nooit links gestuurd worden voor dit soort dingen.
Altijd zelf naar de desbetreffende omgeving gaan (desnoods via een companypagina met goedgekeurde links).

Dan voorkom je al een hoop ellende volgens mij

[haam]

Een van de redenen waarom ik n open source standalone app gebruik (andOTP). Ben geen security expert, maar probeer altijd zo min mogelijk gebruik te maken van online diensten.

Het loont volgens mij meer om een online dienst te hacken, waarbij de buit redelijk groot kan zijn. De kans dat ik daar het slachtoffer van word, is een heel stuk kleiner.

[FPSUsername]

Ik heb zoiets overwogen toen ik een keer mijn telefoon had gereset en erachter kwam dat Google Authenticator je accounts niet opslaat. Dan kun je weer langs je tig accounts om weer 2FA te resetten. Daarom gebruik ik al jaren Authy. Ik weet niet of er een open source athenticator bestaat die je accounts kan synchroniseren. Volgens mij kan bitwarden dat met een premium account, en aangezien ik bitwarden al een lange tijd gebruik, misschien geen slecht idee om ook voor 2FA daar naar over te stappen.

[dutchminator]

Zou ik niet doen. Als je je 2FA tokens bij je wachtwoorden opslaat, zijn je tokens geen 2nd factor meer (iemand met toegang tot je Bitwarden heeft dan namelijk ook je tokens).

[Hee_Martijn]

Je hebt op zich wel gelijk, maar is die manier van 2fa sowieso niet afgelopen? Als ze komend jaar die passkeys / multi device fido credentials in gaan voeren dan hebben we binnenkort per website 1 private key die over al je apparaten wordt gesynchroniseerd en verder niet.

[zwartpet]

2FA is dan dus je device waar bitwarden op staat. Gebruik zelf 1password voor beide, maar daar kun je niet even simpel inloggen en moet je echt een apparaat hebben waar de app op staat.

Met het device (1), het wachtwoord van het device (2) en het wachtwoord van 1password (3) heb je opzich wel een aantal lagen beveiliging

[haam]

Ik heb geen automatische sync. Ik maak handmatig een backup als ik een 2fa toevoeg (wat niet heel vaak gebeurd). Maar ik denk dat ik daarmee afwijk van de meeste mensen. Bij mij hoeft het niet perse makkelijker omdat het kan. Makkelijker is niet (altijd) veiliger.

Daarbij wil ik mijn 2fa gescheiden houden van mijn password manager. Mocht die om wat voor reden gehakt worden, dan ben ik niet meteen de controle kwijt.

[Polderviking]

Ik gebruik ook een open source "offline" oplossing hiervoor, maar ik ben er zelf verder niet van overtuigd dat dat inherent beter is. Ik gebruik het omdat ik graag open source oplossingen gebruik.

Als Authy doet wat ze zeggen en je token vault versleutelen voor de upload naar hun servers hebben hackers er niks aan zonder ook bij jou je decryptie sleutel los te peuteren.

Weet niet hoe jij er mee om gaat maar ik heb die token vault gewoon op mijn persoonlijke cloud storage staan en dat synct weer naar mijn apparaten dus als je mijn laptop jat heb je die vault ook.

Denk dat dat makkelijker is dan in infra van Authy binnendringen.

[Reactie gewijzigd door Polderviking op 24 juli 2024 01:54]

[haam]

Ik ben het met je eens dat het niet perse beter is.

Ik heb mn token vault op mijn lokale NAS staan (zonder internet toegang) en gesynced met mn lokale PC.
Natuurlijk kunnen ze een laptop stelen (of PC/mobiel), maar dan heb je alleen de 2FA van 1 persoon. Dat is alleen interessant als je echt een high value target bent.
Bij een online dienst is de buit meestal veel groter en daarmee meteen een stuk interessanter.

[Ziglar]

beter misschien niet, maar ik denk dat ik minder interresant ben dan een password/auth dienst.
als mensen mijn wachtwoorden willen moeten zij mijn systeem direct aanvallen. dan alsnog moeten ze door enkele encrypties en wachtwoorden heen voordat ze toegang krijgen tot de wachtwoorden. de kans dat ik persoonlijk een doelwit ben is 10^x kleiner dan tijd steken in het hacken van pws/auth diensten en daarnaast levert het nog minder op ook.
voor MFA probeer ik zoveel mogelijk Fido2 te gebruiken en anders totp/hotp op de yubikey.

dus ja, pwd/auth diensten zijn lastiger te kraken maar leveren veel meer op dan persoonlijke aanvallen.

[pepsiblik]

Authy is er ook voor Windows en MacOS. Dus je kunt het rechtstreeks op je laptop of desktop draaien en zo de gegeneerde codes via kopieren / plakken invoeren.

[klonic]

en zo de gegeneerde codes via kopieren / plakken invoeren.

Via continuity kan dat sowieso. Je clipboard wordt gedeeld tussen je Apple apparaten. Dus je 2FA kan je gewoon kopieeren op je iPhone en dan plakken op je Mac.

[pepsiblik]

Maar dan moet je dus wel steeds je telefoon bij de hand hebben.

[klonic]

Nu ik erover nadenk. In (iCloud) Keychain zit (TBOTP) 2FA geintegreerd. Die vult hem ook automatisch in op websites en dat werkt dus zowel in iPhoneOS, als MacOS als iPadOS. Je hoeft dus neit te copy/pasten of uberhaupt een app te starten.

Overigens is het bij de hand hebben van mijn telefoon niet echt een issue. Die heb ik altijd bij de hand.

[Jazco2nd]

En daarom ben ik paar jaar geleden van Authy overgestapt op Aegis. Veel mensen hebben nieteens door dat Authy je codes opslaan in een 3rd party cloud die ze contracteren.

Aegis Authenticator

Het maakt de backups in een lokale map naar jouw keuze.

Je bent zelf verantwoordelijk om deze map te syncen met jouw cloud dienst, bijvoorbeeld via FolderSync naar een publieke cloud of naar je eigen (webDAV) server.

[Reactie gewijzigd door Jazco2nd op 24 juli 2024 01:54]

[pdukers]

De data die bij Authy wordt opgeslagen is geencyrpt met je eigen key. Dat betekent dat Authy of welke andere partij niks kan met deze data. Dat vind ik veilig en is niet onveiliger dan wat jij gebruikt.

Tenzij je natuurlijk een hele zwakke key gebruikt, maar dat geldt voor iedere app.

[Jazco2nd]

Ik geloof het wel hoor, maar er zijn meer aspecten die iets "veilig" maken behalve encryptie (wat meer over geheimhouding gaat). Je codes zijn versleuteld, je email adres of account gegevens ook? Vast niet, anders kon Authy je bij deze breach niet emailen, aangezien ze je email adres dan niet kunnen ontcijferen. Daarnaast weet je niet werkelijk waar al deze gegevens precies zijn opgeslagen in de wereld, of het langs een CDN gaat die het TLS ceritifcaat uitgeeft (en data in transit dus ook decrypt voordat het naar Authy servers gaat etc).

[- peter -]

Auch, zolang t geen tokens idd zijn dan valt t mee. Anders zou de beveiliging/architectuur wel erg tekort schieten. Ik ga ervan uit dat de decryptie plaats vind op t device.

[Reactie gewijzigd door - peter - op 24 juli 2024 01:54]

[dehardstyler]

Zeker, allemaal zero knowledge.

[Anoniem: 718943]

Hmm... Ik werk zelf ook bij een IT bedrijf, maar toch, zelfs al zou ik in een phising aanval trappen, ik heb op mijn laptop geen gebruikersdata staan, en ook geen open authenticatie om bij die data te kunnen komen op het netwerk. Dus toch wel lichtelijke kritiek.

[stuiterveer]

Het gaat hier niet om gebruikersdata die op een laptop stond, het gaat om een medewerker die z'n eigen inloggegevens heeft gedeeld om toegang te krijgen tot andere applicaties binnen het netwerk. Heel groot verschil. Plus dat je bij een IT-bedrijf werkt heeft niks te maken met of je wel of niet gebruikersdata op je laptop staat. Dit is ook afhankelijk van in hoeverre je daadwerkelijk met gebruikersdata ooit te maken hebt.

Wat betreft authenticatie geven ze zelf ook aan verbeteringen te hebben uitgevoerd, al hadden ze dat inderdaad beter kunnen doen al vanaf het begin.

[Reactie gewijzigd door stuiterveer op 24 juli 2024 01:54]

[jarco5000]

geen bewijs is dat aanvallers bij hun data konden.

Dat is toch niet hoe security werkt? Je moet bewijs hebben dat ze er niet aankonden. Anders is de data compromised.

[Cergorach]

Dan kan je nooit bewijzen dat er niemand ander bij kon, tenzij het account geheel disabled is. Je weet niet of een attacker het ww heeft of toegang heeft tot de 2FA app van de gebruiker, je weet ook niet of een attacker toegang heeft tot het netwerk/device van de gebruiker (buiten kantoor). Vandaar al die security lagen/detectie (althans dat zou het moeten zijn).

[FrostyPeet]

Het blijft lastig. Sommige wachtwoord managers werken handig, vooral als iemand meerdere apparaten gebruikt bij eenzelfde website. Met een generator kan elke website een sterk wachtwoord krijgen, voorkom je gebruikers die "ABC-123456" op elke website gebruiken.

Aan de andere kant zijn dit soort managers een doelwit. Vroeg of laat glipt er eentje doorheen. Kan een "state actor" zijn met professionele staf en onbeperkt budget, tot een scriptdraaier ergens op een zolder die toevallig net dat ene achterdeurtje opent.