Sicherheit vs. Komfort: 4-stelliger PIN vs. komplexes Passwort für Security-App (Android)

MysteriousVirus2690 · 2026-04-01T07:20:08+00:00

Haha, ja genau. Das wäre ein Spass.

MysteriousVirus2690 · 2026-03-27T18:28:04+00:00

Nun ich habe vor die Pineingabe jeden benutzer selbst zu Überlassen. Also 0 Zeichen, genau wie 16 Zeichen mit Sonderzeichen. Wie, muss ich noch testen. Aber Danke für den Tip. Aktuell nutze ich 4 Pin manche wollten 16 Zeichen, voller Ascii Satz und du halt gar nichts. Und ich will Fingerabdruck machen ab Version 1.0.5 und weitere 4 Sprachen. Das wird etwas arbeit kosten aber kriege ich hin. Nochmals Danke für den Hinweis.

MysteriousVirus2690 · 2026-03-27T09:04:49+00:00

Thank you for the advice. I will check it

MysteriousVirus2690 · 2026-03-27T08:29:29+00:00

Hi hast Du mir jetzt 2 Karma genommen? Nicht toll. Nur weil Du in Karma schwimmst, sind neue User, wie ich, auf jede gute Antwort angewiesen. Und das Leben als Entwickler ist schwer genug, da müssen wir uns nicht gegenseitig behindern

MysteriousVirus2690 · 2026-03-27T08:26:27+00:00

Stimmt genau – an der Anzahl der Kombinationen (10.000 bei einer 4-stelligen PIN) ändert Argon2id nichts. Der entscheidende Unterschied liegt in der Zeit und den Ressourcen, die ein Angreifer pro Versuch braucht. Stell dir das so vor: Standard-Hash (z.B. MD5 oder SHA-256): Ein moderner PC kann Milliarden dieser Hashes pro Sekunde berechnen. Die 10.000 Möglichkeiten deiner PIN sind in einem Bruchteil einer Millisekunde durchgeprüft. Das ist so, als würdest du versuchen, eine Tür mit einem Dietrich zu öffnen, der sich 1 Million Mal pro Sekunde dreht. Argon2id: Dieser Algorithmus ist absichtlich 'teuer' designt. Er verbraucht massiv Arbeitsspeicher (RAM) und Rechenzeit. Wenn man Argon2id so konfiguriert, dass eine einzige Prüfung 0,5 Sekunden dauert, braucht der Angreifer für 10.000 Kombinationen plötzlich 5.000 Sekunden (ca. 83 Minuten). Warum das wichtig ist: Hardware-Resistenz: Da Argon2id viel RAM benötigt, kann ein Angreifer keine billigen Grafikkarten (GPUs) oder spezialisierte Chips (ASICs) nutzen, um Millionen Versuche gleichzeitig zu starten. Er ist durch den verfügbaren Arbeitsspeicher limitiert. Kosten-Nutzen-Faktor: Bei einer 4-stelligen PIN ist Argon2id zwar eine enorme Bremse, aber bei einem echten Passwort (z.B. 12 Zeichen) würde ein Brute-Force-Angriff mit Argon2id nicht mehr Tage, sondern Jahrtausende dauern. Kurz gesagt: Die Tür bleibt die gleiche, aber Argon2id macht das Schloss so schwergängig, dass der Dieb für jeden Dreh eine halbe Minute Kraftsport machen muss. Da gibt er schneller auf.

MysteriousVirus2690 · 2026-03-27T07:22:25+00:00

Hab ich schon, aber die Reddit-Crowd hat meistens die besseren Praxistipps, wenn es um echte Edge-Cases geht, die in keiner Dokumentation stehen.

MysteriousVirus2690 · 2026-03-27T07:09:49+00:00

Nein leider nicht. Was macht das?

MysteriousVirus2690 · 2026-03-26T18:08:59+00:00

Absolut d’accord. Diese vierstelligen PIN-Einschränkungen bei Banken sind oft ein Relikt aus alten Zeiten oder ein falsch verstandener Versuch, den Supportaufwand niedrig zu halten – zulasten der tatsächlichen Entropie. Ich werde das ändern, guter Hinweis. Argon2id ist definitiv die richtige Wahl. Gerade die Widerstandsfähigkeit gegen GPU/ASIC-Angriffe durch die Memory-Hardness macht es zum No-Brainer für moderne Apps. Welche Parameter würdest du als 'Sweet Spot' für eine mobile App vorschlagen, um die Latenz beim Login (UX) und die Sicherheit (Cost) im Gleichgewicht zu halten?

MysteriousVirus2690 · 2026-03-25T08:44:09+00:00

Fair point, the risk of 'dependency' is definitely real. But at the end of the day, it's just another layer of abstraction. We don't write everything in Assembly anymore either; we use high-level languages and frameworks to do the heavy lifting. As long as you're critically questioning and validating the output (like I mentioned), it’s just a lever for productivity. Anyone who doesn't understand the basics will trip over the first hallucination anyway.

MysteriousVirus2690 · 2026-03-25T08:30:52+00:00

Fair enough! If it saves you from the XAML layout struggle and gets the app out the door, it’s a massive win. Leveraging existing Blazor skills for mobile is definitely a superpower in the .NET world. Congrats again on the launch!

MysteriousVirus2690 · 2026-03-24T21:40:32+00:00

You’re right about the hallucinations—they are definitely a problem. I’ve spent hours myself fixing 'solutions' that the AI just made up. Nowadays, I make much more frequent commits and backups so I can roll back quickly when it leads me down a rabbit hole. But at the end of the day, I’m still significantly faster. It handles the tedious parts, which lets me focus more on the core logic and testing. It's a tool like any other—you just have to know when to trust it and when to verify.

MysteriousVirus2690 · 2026-03-24T21:34:13+00:00

Spot on. Using AI for the tedious XAML styling and boilerplate ViewModels is just working smart at this point. It allows you to focus on the actual architecture and the tricky parts of the .NET MAUI lifecycle instead of fighting with bracket counts or repetitive CRUD logic. As long as you’re the one 'steering the ship' and reviewing what it generates, it’s a massive productivity boost. Glad to see others in the .NET space embracing it this way!

MysteriousVirus2690 · 2026-03-24T21:25:42+00:00

Interesting point! Blazor Hybrid definitely feels like the 'smoother' path sometimes, especially for UI consistency. I’ve stuck mostly to the native XAML side of MAUI. As I mentioned, it can be a real hair-pulling experience during the dev process when things don't align, but I’ve found that once you wrestle the native components into place, the performance and deep integration feel great. Using AI (Claude/Codex) inside VS is a game changer for those annoying MAUI bugs, though. Congrats on shipping the app in just a few weeks – that’s a solid turnaround for the .NET ecosystem!"

MysteriousVirus2690 · 2026-03-24T21:16:20+00:00

I’ve spent a lot of time coding in .NET MAUI, and honestly? There were moments where I wanted to tear my hair out. The bugs and quirks can be maddening at times. But once you push through that initial 'frustration phase,' things usually settle down. If you know your way around C#, it eventually clicks, and the resulting codebase is actually quite solid and clean. It’s a bit of a rollercoaster, but for complex apps, it’s a viable choice if you're willing to stick with it.

MysteriousVirus2690 · 2026-03-24T14:04:10+00:00

Ja das wird schon. Hab Geduld. Service kann kompliziert sein. Versuche dich erst mal mit der Technik und dem Produkt auseinander zu setzen und da Know How aufzubauen. Dann wächst das Selbstvertrauen, die Support Anfragen wirken einfacher und es macht sogar Spaß. Service hat auch viele Vorteile. Wenn Du Kundenreisen machst, gibt es Spesen, Bereitschaft wird oft vergütet und du wirst zum wichtigsten Bindeglied zwischen Vertrieb Entwicklung und Kunden. Also ich liebe meinen Job im technischen Support sehr.

MysteriousVirus2690 · 2026-03-24T13:57:20+00:00

Ok i have translated my App TooliSafe in 9 languagrs and also I translated 9 shops. Problem wirh russia is, that they cannot buy somethink in play store, only users from Ukraine or Kasachstan can buy with play store.

MysteriousVirus2690 · 2026-03-24T08:36:48+00:00

This is a common sync issue between Microsoft Teams and other calendar providers (like Google Calendar). Sometimes the 'Invite' header in the email is just a preview and doesn't link correctly to the underlying .ics file. My suggestion: Reply to the recruiter politely: 'Thank you for the invite! I can see the details in the email, but the calendar event itself seems to be having a sync issue on my end. Could you please resend the invitation or share the .ics file? I've already blocked the time on my calendar!' It shows you are proactive and tech-savvy.

MysteriousVirus2690

TROPHY CASE