ausgerechnet paypal ...
- Ersteller ed_lumen
- Erstellt am
madmax2010
Fleet Admiral
- Registriert
- Juni 2018
- Beiträge
- 32.270
Witzig
https://www.paypal-community.com/t5...cherer-Token/td-p/3115975?profile.language=de
https://www.paypal-community.com/t5...-not-recommend-using-the-QR-code/td-p/3116231
Der Paypal support empfiehlt einfach authenticator apps zu nutzen, die nicht warnen.
Ich würde ja lieber empfehlen Paypal nicht zu nutzen, aber auch das ist kaum sinnvoll.
hast du bei foxlor ins git geschaut ob da schon ein issue ist?
https://www.paypal-community.com/t5...cherer-Token/td-p/3115975?profile.language=de
https://www.paypal-community.com/t5...-not-recommend-using-the-QR-code/td-p/3116231
Der Paypal support empfiehlt einfach authenticator apps zu nutzen, die nicht warnen.
Ich würde ja lieber empfehlen Paypal nicht zu nutzen, aber auch das ist kaum sinnvoll.
hast du bei foxlor ins git geschaut ob da schon ein issue ist?
Zuletzt bearbeitet:
- Registriert
- Jan. 2021
- Beiträge
- 132
Ich würde dir auch empfehlen auf eine andere 2FA App umzusteigen. Die Fehlermeldung ist zwar richtig aber in dieser Art einfach nicht hilfreich. Der App-Entwickler hält sich wahrscheinlich für was Besseres, weil er hier was von "dringend abraten" und "Anbieter informieren" schreibt ohne aber zu erklären, was jetzt genau so problematisch ist.
Aber vermutlich wird hier wahrscheinlich einfach die Anzahl der Bits, die für den Algorithmus verwendet werden, bemängelt. Wenn Paypal einen, keine Ahnung, 96bit Algorithmus verwendet, aber der Entwickler meint 128bit sind sicher genug, dann kommt die Meldung.
Trotzdem ist aber das Verwenden von 2FA immer ein größerer Sicherheitsgewinn als ein nicht ganz so sicherer Token. Also einfach trotzdem hinzufügen.
Alternativ kannst du bei den Services, die "nicht sichere 2FA Tokens" nutzen auch auf Passkey umsteigen.
Aber vermutlich wird hier wahrscheinlich einfach die Anzahl der Bits, die für den Algorithmus verwendet werden, bemängelt. Wenn Paypal einen, keine Ahnung, 96bit Algorithmus verwendet, aber der Entwickler meint 128bit sind sicher genug, dann kommt die Meldung.
Trotzdem ist aber das Verwenden von 2FA immer ein größerer Sicherheitsgewinn als ein nicht ganz so sicherer Token. Also einfach trotzdem hinzufügen.
Alternativ kannst du bei den Services, die "nicht sichere 2FA Tokens" nutzen auch auf Passkey umsteigen.
Totp gemäß RFC 6238 nimmt standardmäßig SHA1 das ist veraltet, die Warnung kommt "automatisch" bei allen kryptographischen Algorithmen die veraltet sind.
Im Fall von TOTP mit einer Zeit von 30s oder 60s ist das aber ziemlicher Unfug.
Aus Kompatibilität nimmt praktisch niemand SHA2 bei TOTP
Im Fall von TOTP mit einer Zeit von 30s oder 60s ist das aber ziemlicher Unfug.
Aus Kompatibilität nimmt praktisch niemand SHA2 bei TOTP
Ergänzung ()
Bei PayPal ist der Passkey so konfiguriert, dass er einen Faktor übernimmt, also brauchst du üblicherweise immernoch TOTP.chainr3action schrieb:
madmax2010
Fleet Admiral
- Registriert
- Juni 2018
- Beiträge
- 32.270
TIL
Dann sollte man vielleicht die Meldung in den Apps mit entsprechendem Kontext oder "More Information" Button habe, eventuell ein Toggle in den Einstellungen dazu..
Das ist Premium.
Dann sollte man vielleicht die Meldung in den Apps mit entsprechendem Kontext oder "More Information" Button habe, eventuell ein Toggle in den Einstellungen dazu..
red hatchainr3action schrieb:
Das ist Premium.Weils nur der Anbieter ändern kann.gaym0r schrieb:
Und es geht hier um den Seed @Tornhoof, nicht um die Zahl, die dann 30 Sekunden gültig ist.
Den Seed kann ich - wie ein Passwort - bruteforcen.
SHA1 bezieht sich auf HOTP, nicht auf TOTP.
Ich weiß nicht, was PayPal für Seeds anbietet.
Aber 6-stellige Passwörter sind signifikant schlechter als 12-stellige, mal ganz dumm gesagt.
Sicherlich ist dir das bewusst.
Es kostet dich nichts, in so einer Situation - ein per QR-Code automatisiert eingelesenes Passwort! - nen Passwort mit einer hohen Entropie zu verwenden. Gerne 512 Bit, statt 160.
Alles andere sind nur Ausreden. Wir haben seit 2017 Kollisionen auf Sha1, und wissen auch seit 2013 schon, dass uns symmetrische 128 Bit Keys perspektivisch nicht sicher genug sind (> Passwörter), bzw. 2048 Bit Asym RSA Keys.
Es geht hier um einen der weltgrößten Payment-Provider, nicht um den Zugang zu deiner Gartenvereinswebseite.
Wieso macht denn Bitcoin nicht SHA1, huh? Ist doch sicher genug.
Wir haben übrigens gerade ne neue GPU-Generation bekommen, die unsere Rechenkraft von 2017 für ne Single GPU, öh, verfünffacht hat?
Und wir bauen riesige Datacenter damit.
"Haben wir schon immer so gemacht". Ich brech ins Essen.
Zuletzt bearbeitet:
Wie kommst du da drauf @wirelessy ?wirelessy schrieb:
Der Algorithmus ist:
TOTP(K,T) = Truncate(HMAC-SHA-1(K,T))
Wobei T die zeitabhängige Komponente ist.
K ist gemäß Spezifikation ein kryptographisch erzeugter Zufalls Wert (ggf das was du als seed betrachtest), den kennen Client und Server (und nur die).
Damit jetzt also einer den Wert K zurückrechnen kann, muss entsprechend der Angreifer eine größere Menge generierte Codes haben und dann bruteforcen.
Der Angriff ist nicht praktikabel. Kollisionsangriffe funktionieren auf hmac Algorithmen nicht, daher wird hmac -sha1 noch als "sicher" angesehen
Der Angriff der praktikabel ist, aktuell auch bekannt unter AuthQuake ist eine bruteforce Attacke, die durch fehlendes rate limiting und einer zu langen Karenz Zeit der Werte auftritt, im Fall von MS gab's kein Rate limiting und die Karenzzeit war 3minuten.
In dem Zeitraum war die Chance den richtigen 2FA Code durch Zufall auszuprobieren etwa 3%.
Zuletzt bearbeitet:
Von AuthQuake rede ich nicht, genau. Das ist ein Serverseitiges Problem, und hat mit der Meldung des TE nichts zu tun. Das wäre auch ansonsten ein TOTP Problem, weil Truncate nunmal diese 6-stellige Zahl generiert - mit sehr wenig Entropie, die man dann entsprechend bruteforcen kann.
Das sind deine beschriebenen +-3%, würde ich annehmen. Ohne die genaue Zahl gegen zu checken.
Die gelten pro Periode eines gültigen TOTP.
Du stellst deine erste Variante als nicht praktibel hin. Das hängt vom spezifischen Szenario ab, würde ich sagen.
Mit der Größe der Zahl K etwa - der Seed, so nenne ich den, genau.
Ich muss das aber nicht "zurückrechnen".
Ich kann auch TOTPs über die möglichen Seeds "K" lokal generieren, und regelmäßig schauen, ob das einen passenden TOTP ergibt. T ist ja kein Geheimnis, sondern die aktuelle Zeit.
Auch die Entropie von K eines Anbieters ist kein Geheimnis.
Hier zu behaupten, dass die Wahrscheinlichkeit den richtigen Seed zu erwischen nicht mit der Größe von K zu tun hat, ist schlichtweg falsch.
Und wenn ich jetzt 1-n abgefangene TOTP hab, dann kann ich das auch rein lokal bruteforcen, und dann hält mich auch nur noch meine Rechenleistung ab. Die sind fundamental aber nicht nötig, sondern reduzieren den Aufwand nur noch weiter.
Nimm nen möglichst großes K, kostet nichts. Wieso sollte man das nicht machen, erklär mir das doch mal?
Das sind deine beschriebenen +-3%, würde ich annehmen. Ohne die genaue Zahl gegen zu checken.
Die gelten pro Periode eines gültigen TOTP.
Du stellst deine erste Variante als nicht praktibel hin. Das hängt vom spezifischen Szenario ab, würde ich sagen.
Mit der Größe der Zahl K etwa - der Seed, so nenne ich den, genau.
Ich muss das aber nicht "zurückrechnen".
Ich kann auch TOTPs über die möglichen Seeds "K" lokal generieren, und regelmäßig schauen, ob das einen passenden TOTP ergibt. T ist ja kein Geheimnis, sondern die aktuelle Zeit.
Auch die Entropie von K eines Anbieters ist kein Geheimnis.
Hier zu behaupten, dass die Wahrscheinlichkeit den richtigen Seed zu erwischen nicht mit der Größe von K zu tun hat, ist schlichtweg falsch.
Und wenn ich jetzt 1-n abgefangene TOTP hab, dann kann ich das auch rein lokal bruteforcen, und dann hält mich auch nur noch meine Rechenleistung ab. Die sind fundamental aber nicht nötig, sondern reduzieren den Aufwand nur noch weiter.
Nimm nen möglichst großes K, kostet nichts. Wieso sollte man das nicht machen, erklär mir das doch mal?
Zuletzt bearbeitet:
K ist spezifiert als mind. 128bit und empfohlen 160bit. Die spec kam leider nach dem Google Authenticator, der hat damals nur 80bit Ks supported, der wird gerne als Baseline betrachtet bzgl Funktionalitätwirelessy schrieb:
Es gibt sicher genug Implementierungen die noch 80bit Ks generieren, ich hab gerade in meiner 2FA App mal nachgeschaut und grob die Hälfte ist nur 16 Zeichen in base32, dh 80bit.
Aber auch 80bit wirst du nicht zufällig erraten, wenn der Anbieter einen kryptographisch akzeptablen Zufallsgenerator nutzt.
Doch, werde ich, so wie 1-n Affen mit genug Zeit auch die Bibel schreiben werden.
Aufgabe ist, die Zeit hoch zu treiben. Wie immer mit Schlüssellängen. DES, 3DES empfiehlst du mir doch auch nicht, oder? RC4? AES mit 64 bit Keys?
Nein, wir empfehlen mindestens 128 bit für AES, und besser 256 bit.
Wir reden hier immer noch von nem Payment-Anbieter, bei dem es potenziell um richtig viel Geld geht.
Wir machen PBKDF2 mit 100k+ Rounds, nicht mit 10, und wieso? Weil der Aufwand steigt.
Aufgabe ist, die Zeit hoch zu treiben. Wie immer mit Schlüssellängen. DES, 3DES empfiehlst du mir doch auch nicht, oder? RC4? AES mit 64 bit Keys?
Nein, wir empfehlen mindestens 128 bit für AES, und besser 256 bit.
Wir reden hier immer noch von nem Payment-Anbieter, bei dem es potenziell um richtig viel Geld geht.
Wir machen PBKDF2 mit 100k+ Rounds, nicht mit 10, und wieso? Weil der Aufwand steigt.
Schlechtes Beispiel, pbkdf2 erhöht unverhältnismäßig die Zeit für den Anwender und nicht für den Angreifer, durch gpus. Nicht umsonst ist selbst für sha2-512 die aktuelle Empfehlungen bei über 200k Runden und mit der 5090 ist die Erwartung dass es auf 350k oder so steigt. Pbkdf2 ist so oder so ein dead-end, argon2di oder so nutzen, aber das ist Off topic.wirelessy schrieb:
Aber ja, es verneint keiner dass es besseres gibt als TOTP mit hmac-sha1, jedoch ist hmac-sha256 nicht essentiell besser. Es gibt wie gesagt keine Angriffe auf hmac -sha1.
Damit ist die Warnung in Tool des TE Unfug.
Stimmt, schlechtes Beispiel für den konkreten Angriff, aber immer noch passend für das Beispiel den Aufwand hochzutreiben.
Wir wissen nicht genau, wodrauf sich die Warnung bezieht - Alg, oder K-size.
Unfug ist sie aber grundsätzlich nicht, bei schlecht ausgestaltet bin ich dabei.
Klar ist HMAC-SHA256 kryptographisch stärker, das weißt du auch.
Und ein größeres K kostet weiterhin nichts.
Keine Ahnung, wieso ihr alle gratis zu habende bessere Kryptoparameter nicht haben wollt, und einfach sagt "jojo leg dich wieder schlafen".
Als ob es euch irgendwie weh tun würde.
"Ja, könnt besser sein, aber passt schon wenns schlechter ist".
Und dann implodieren wieder U-Boote im Atlantik.
Wir wissen nicht genau, wodrauf sich die Warnung bezieht - Alg, oder K-size.
Unfug ist sie aber grundsätzlich nicht, bei schlecht ausgestaltet bin ich dabei.
Klar ist HMAC-SHA256 kryptographisch stärker, das weißt du auch.
Und ein größeres K kostet weiterhin nichts.
Keine Ahnung, wieso ihr alle gratis zu habende bessere Kryptoparameter nicht haben wollt, und einfach sagt "jojo leg dich wieder schlafen".
Als ob es euch irgendwie weh tun würde.
"Ja, könnt besser sein, aber passt schon wenns schlechter ist".
Und dann implodieren wieder U-Boote im Atlantik.
Jo, darauf können wir uns einigen.wirelessy schrieb:
Am 80bit K, siehe https://github.com/orgs/community/discussions/75936#discussioncomment-7727594, daher hatte ich den Hinweis mit der Kompatibilität von Google Authwirelessy schrieb:
Jo, wenn das trivial praktikabel wäre, wären alle unsere Konten leer.
Und ich reich. Ist das jetzt der Standard?
@gaym0r Und du hast es sicherlich nichtmal probiert.
Ausm Fazialpalmieren komm ich hier irgendwie nicht mehr raus.
Ich behaupte ja nicht, dass die Warnung dazu führt, dass alle Logins auf einmal kompromittiert wären.
Aber du willst jetzt was sagen? Dass man sich nicht verbessern sollte?
Und ich reich. Ist das jetzt der Standard?
@gaym0r Und du hast es sicherlich nichtmal probiert.
Ausm Fazialpalmieren komm ich hier irgendwie nicht mehr raus.
Ich behaupte ja nicht, dass die Warnung dazu führt, dass alle Logins auf einmal kompromittiert wären.
Aber du willst jetzt was sagen? Dass man sich nicht verbessern sollte?
Dass man mal auf dem Teppich bleiben soll... Man könnte jetzt genauso anfangen SHA256 und SHA384 als unsicher zu deklarieren, weil es ja SHA512 gibt. Oder RSA 4096, weil RSA auch 8192 bit unterstützt.wirelessy schrieb:
Kannst du mir mal das konkrete Sicherheitsproblem aufzeigen, dass du hier siehst? Ich bin wirklich gespannt!
wirelessy schrieb:
gaym0r schrieb:
gaym0r schrieb:
Dass PayPal auf einem alten Sicherheits-Standard aufsetzt, und die Stärkung der Sicherheit verpassen könnte, wenn es a) uninformiert bleibt und b) den Wunsch der Kunden sonst nicht mitkriegt.
Auch sollte sich die Bevölkerung, die nicht in der IT Security arbeitet, in der Nutzung moderner Bezahlsysteme sicher fühlen.
Diese Warnung der TOTP-App hätte ausbleiben können, wenn PayPal ihre MFA-Implementierung aktuell halten würde.
Um mal die Kurve zu meiner kritisierten ersten Aussage zu schlagen.
Aber du kannst ja gerne beim Red Hat Authenticator anfragen, dass diese Warnung bitte unterbleiben soll, weil passt schon mit der alten Security.
Ähnliche Themen
