BeBur schrieb:
Wenn du dem Serverbetreiber dahingehend nicht vertraust, dann solltest du auch dem von ihm ausgelieferten JS Code nicht vertrauen
1. Der (evtl. JS) Code wird nicht notwendigerweise vom Serverbetreiber ausgeliefert (z.B. nach Audit duchs Unternehmen an die Mitarbeiter, z.B. GPlay, z.B. separate Infrastruktur)
2. Better safe than sorry
3. Nicht jeder Nutzer trifft hier eine
bewusste Entscheidung
frei von Zwängen (man siehe mal auf die Situation mit WhatsApp)
4. Wie schon geschrieben, kann der Serverbetreiber angegriffen werden, weshalb überhaupt erst Hashes auf dem Server gemacht werden
5. Der Serverbetreiber kann durch Geheimdienste zu einem Leak gezwungen werden
BeBur schrieb:
der das Passwort angeblich bei dir schon hasht. Das jedesmal zu prüfen ist aber extrem unpraktikabel und macht niemand(tm), von daher hat das keine praktische Relevanz.
Je nach Setup ist ein solches Verifizieren ziemlich einfach, sh. reproducible builds.
Es muss auch nicht von jedem gemacht werden.
Eine Person, die es macht, reicht um die Problematik aufzudecken.
Selbst wenn nichts davon zutrifft: Ein PW ist serverseitig abzufangen ist einfacher als eine Backdoor auszuliefern (z.B. müssen dann u.a. die Frontendentwickler mitspielen).
BeBur schrieb:
Der sinnvolle Weg besteht darin, einen PW Manager und einmalige PWs zu verwenden.
Sinnvoll ist von der Realität auszugehen, in der das nicht jeder nutzt und es sich auch nicht so schnell ändern wird
BeBur schrieb:
aber es ist mir zumindest völlig klar gewesen was er gemeint hat, von daher ist dein abwertender Ton hier fehl am Platz.
😉
owned139 schrieb:
Nein, weil dann der Hash übertragen wird und man im Zweifel nur an den Hash kommen muss, um Zugriff zu erlangen und nicht mehr ans eigentliche Passwort.
Und? Das habe ich in #6 schon beschrieben.
Nur was hat das eine mit dem anderen zu tun?