Frage:
Was tun mit Websites, auf denen Nur-Text-Passwörter gespeichert sind?
jamesj
2011-09-13 23:18:51 UTC
view on stackexchange narkive permalink

Ich habe kürzlich eine E-Mail von einer beliebten Jobwebsite für Hochschulabsolventen (spects.ac.uk) erhalten, die ich seit einiger Zeit nicht mehr verwendet habe, und vorgeschlagen, eine neue Funktion zu verwenden. Es enthielt sowohl meinen Benutzernamen als auch mein Passwort im Klartext. Ich gehe davon aus, dass dies bedeutet, dass sie mein Passwort im Klartext gespeichert haben.

Kann ich irgendetwas tun, um entweder die Sicherheit zu verbessern oder meine Daten vollständig aus dem System zu entfernen?

UPDATE: Vielen Dank an alle für den Rat . Ich schickte ihnen eine E-Mail, in der ich darlegte, was falsch war und warum, und sagte, dass ich an den DP-Kommissar schreiben und sie zu plaintextoffenders.com hinzufügen werde.

Eine Stunde später erhielt ich eine Antwort: eine automatisierte Nachricht mit einem Benutzernamen und einem Passwort für das Support-System. Oh je ...

Und was ist für zusätzliche Bonuspunkte zu tun, wenn die Eigentümer des Systems behaupten / angeben, dass dies der Industriestandard ist?
Verwenden Sie einfach nicht Ihr Lieblingskennwort ** tyrFTgjh432 # @@ ** auf unbekannten (beliebigen) Websites. Sie können Ihr Passwort nicht im Klartext senden, es aber dennoch im Klartext speichern (anzeigen, verkaufen ...).
Siehe auch: http://security.stackexchange.com/questions/4997/is-it-a-bad-idea-for-an-information-holder-to-e-mail-a-user-their-password
Ein bisschen spät, aber das ist relevant: http://www.troyhunt.com/2012/07/lessons-in-website-security-anti.html
Dies ist auch etwas spät, könnte aber etwas zur Community beitragen.https://pogsdotnet.blogspot.sg/2017/06/risks-associated-with-plain-text.html
Zwölf antworten:
Igal Tabachnik
2011-09-14 00:02:53 UTC
view on stackexchange narkive permalink

Sie können nicht wirklich viel tun, außer die Website zu kontaktieren und zu erklären, wie schlecht eine Idee und Praxis ist, Passwörter im Klartext zu speichern (und per E-Mail zu versenden).

Eine Sache, die Sie tun können, ist, jede beleidigende Website an plaintextoffenders.com zu melden - eine Website (derzeit ein Tumblr-Blog, aber wir arbeiten bald an einer geeigneten Website), auf der verschiedene "Klartext-Straftäter" aufgelistet sind. Websites, die Ihnen Ihr eigenes Passwort per E-Mail zusenden und so die Tatsache offenlegen, dass sie es entweder im Klartext speichern oder eine reversible Verschlüsselung verwenden, die genauso schlecht ist.

Bei allem, was mit Sony passiert ist Immer wieder werden die Menschen auf die Gefahren von Websites aufmerksam, auf denen vertrauliche Daten unverschlüsselt gespeichert werden, viele jedoch immer noch nicht. Es wurden über 300 Websites gemeldet, und jeden Tag kommen weitere Berichte!

Hoffentlich hilft plaintextoffenders.com, indem immer mehr Websites verfügbar gemacht werden. Sobald dies auf Twitter oder anderen sozialen Medien genügend Beachtung findet, ändern Websites manchmal ihren Weg und beheben das Problem! Zum Beispiel haben Smashing Magazine und Pingdom kürzlich den Umgang mit Passwörtern geändert und speichern oder versenden die Passwörter nicht mehr im Klartext!

Das Problem ist das Bewusstsein, und ich hoffe, dass wir der Sache mit Klartext-Straftätern helfen.

Wenn ich in Großbritannien ansässig bin, kann ich dann vorschlagen, dass sie gegen das Datenschutzgesetz verstoßen?
@jamesj: Ich weiß es leider wirklich nicht!
Schöne Idee mit dieser Seite! Sobald Sie zu einer geeigneten Site gewechselt sind (oder wenn möglich sogar vorher), können Sie einen Abschnitt mit "konvertierten Tätern" hinzufügen. Ich hoffe, dass ein solcher Abschnitt nicht leer bleibt und ein zusätzlicher Anreiz für Websites ist, ihre Probleme zu beheben.
@jamesj IANAL, aber es sieht so aus, als ob es gegen [das siebte Prinzip] verstoßen könnte (http://www.legislation.gov.uk/ukpga/1998/29/schedule/1/part/II/crossheading/the-seventh-principle) (siehe "Unfallverlust" in 9a).
@jamesj - es lohnt sich auf jeden Fall, den DP-Kommissar zu informieren; Versuchen Sie, einen kurzen, leicht verständlichen Brief (auf echtem Papier) für sie zu schreiben. Erwarten Sie jedoch nicht zu viel. :-(
@DanBeale Danke, das werde ich tun. Diese Website wird von fast jeder Universität des Landes empfohlen, daher stelle ich mir vor, dass sich die meisten Studenten und Ex-Studenten irgendwann angemeldet haben.
@IgalTabachnik, Woher erhalten Sie Ihre Statistiken für "Es werden über 300 Websites gemeldet, und jeden Tag kommen weitere Berichte"?
Thomas Pornin
2011-09-13 23:22:54 UTC
view on stackexchange narkive permalink

Das Speichern eines Passworts im Klartext ist kein wirkliches Problem - zumindest viel weniger als das Senden des Passworts in einer Klartext-E-Mail !

Diese E-Mail beweist dies nur Die Website-Administratoren gehen nicht sehr vorsichtig mit den Informationen um, die Sie ihnen anvertrauen, und das ist ein guter Grund, ihnen keine weiteren Daten anzuvertrauen.

Können Sie etwas näher erläutern, warum dies kein Problem ist? Ich (zusammen mit Millionen anderen) habe ein starkes pwd, das ich für viele Dinge benutze. Wenn jeder seinen Job macht und hascht, sollte ich mir Sorgen machen müssen, dass mein PWD im Klartext angezeigt wird und ein verärgerter Mitarbeiter es sieht und es verwendet, um auf eines meiner vielen Konten zu gelangen (meine Bank / andere wichtige Passwörter unterscheiden sich aus diesem Grund ). Aber Passwörter für jedermann sichtbar zu machen, scheint ein Problem zu sein, und ich bin gespannt, warum Sie sagen, dass dies nicht darauf zurückzuführen ist, dass Sie tatsächlich der ansässige Experte sind :)
Wie gesagt, es ist _less_ ein Problem als das Versenden als E-Mail. Dies unterstreicht jedoch die Notwendigkeit ortsspezifischer Passwörter. Ich verwende niemals dasselbe Passwort für zwei verschiedene Dienste - und Sie sollten dasselbe tun, da Sie nicht wissen können, wie (un) kompetent die Systemadministratoren einer Site sind. Sie können das Passwort im Klartext speichern oder, noch schlimmer, per E-Mail an schlecht validierte Adressen senden.
Das Speichern des Passworts im Klartext ist ein * großes * Problem. LinkedIn hat seine Anmeldeinformationsdatenbank gestohlen und über 6.000.000 Benutzerkonten wurden kompromittiert. Diese Passwörter wurden nicht einmal im Klartext gespeichert, sondern mit SHA-1 ohne "Salz" gehasht. **JEDOCH**; Ich stimme Ihnen zutiefst zu, dass diese Praxis bedeutet, dass die Website es nicht wert ist, dass Sie ihnen weitere Daten anvertrauen.
Das Speichern von Klartext-Passwörtern ist absolut ein Problem.Wer weiß, wie viele Mitarbeiter Zugriff auf ihre Datenbanken haben, die einen schlechten Tag davon entfernt sind, all diese Klartext-Passwörter zu missbrauchen.Das Unternehmen muss keine Benutzerkennwörter kennen und sollte diese auch nicht kennen.Zeitraum.
smokris
2011-09-14 22:55:20 UTC
view on stackexchange narkive permalink

Verwenden Sie für jede Site ein anderes Kennwort. Auf diese Weise, wenn das Kennwort kompromittiert wird (sei es durch Snooping bei Klartext-E-Mail-Übertragungen oder sogar, wenn eine Datenbank mit ordnungsgemäß gehashten / gesalzenen Kennwörtern geknackt wird). Der Angreifer kann nur auf dieser einen Site auf Ihr Konto zugreifen und nicht auf allen Sites, auf denen Sie über ähnliche Kontoanmeldeinformationen verfügen.

... und Sie müssen sich nicht daran erinnern zig Passwörter: Stanfords PwdHash ist eine praktische Browser-Erweiterung, die automatisch eindeutige Passwörter generiert, indem sie ein gemeinsames Passwort hasht, das Sie mit der Domain der Site eingeben.

Siehe auch die ähnlichen Supergenpass-Optionen: [Ist der Bookmarklet Password Generator von SuperGenPass.com sicher zu verwenden? - Stapelüberlauf] (http://stackoverflow.com/questions/554224/is-the-bookmarklet-password-generator-from-supergenpass-com-safe-to-use)
woliveirajr
2011-09-13 23:25:35 UTC
view on stackexchange narkive permalink

Senden Sie ihnen eine E-Mail mit der Bitte, aus ihrer Datenbank entfernt zu werden.

Geben Sie ihnen keine weiteren Informationen über Sie.

Stellen Sie sicher, dass dieses Passwort nirgendwo verwendet wird.

Ich habe das Gefühl, dass jeder, der so fahrlässig mit der Sicherheit umgeht, Ihren Datenbankeintrag höchstens als inaktiv markieren würde. Ich sehe keine Möglichkeit, die Gewissheit zu haben, dass Ihr Klartext-Passwort nicht mehr für alle und jeden verfügbar ist - der einfachste Weg wäre wahrscheinlich, es zu hacken und zu löschen.
Vielleicht ändern Sie das Passwort tausendmal, nur für den Fall, dass es irgendwo gespeichert ist, um zu verhindern, dass "Ihre letzten 3 Passwörter nicht wiederholen".
@woliveirajr Wenn Sie es tausendmal tun, wird wahrscheinlich ein DoS-Schutz ausgelöst.
genesis
2011-09-14 00:00:51 UTC
view on stackexchange narkive permalink

Aus diesem Grund wird empfohlen, auf jeder Site ein anderes Kennwort zu verwenden.

Versuchen Sie, diese per E-Mail zu senden, um Ihr Konto zu löschen. Andernfalls verwenden Sie diese Site nicht und verwenden / generieren Sie wirklich ein anderes Passwort (und ein langes!) Auf jeder Site, bei der Sie sich registrieren. Sie wissen nie, welche einfache Passwörter in ihrer Datenbank speichern

+1 Für die Empfehlung eindeutiger Passwörter auf jeder Site.
pal4life
2011-09-14 05:32:08 UTC
view on stackexchange narkive permalink

Ich würde sagen, da das Passwort für die ganze Welt sichtbar ist, aktualisieren Sie es einfach auf ein Passwort, das Sie nirgendwo anders verwenden. Somit kann niemand Ihre Informationen auf einer anderen Site mit dem Passwort auf dieser Site hacken. Ein Beispiel könnte sein, wenn Ihre E-Mail Ihr Login ist und Sie das Passwort auf dieser Website als Passwort für Ihre E-Mail verwenden.

Abgesehen davon, wenn Sie anbieten möchten, der Website beim effektiven Speichern von Passwörtern zu helfen und senden Sie ihnen den Link dieses Stackoverflow-Threads.

Robert David Graham
2012-02-03 06:34:38 UTC
view on stackexchange narkive permalink

Wenn Passwörter im Klartext übertragen werden, handelt es sich um eine "Sicherheitslücke".

Der erste Schritt besteht darin, Beweise zu finden, z. B. indem Sie Wireshark ausführen, um die Passwörter zu erfassen, wenn sie auf dem Draht gesendet werden.

Der zweite Schritt besteht darin, das Unternehmen zu kontaktieren, z. B. indem Sie eine E-Mail an "Secure@example.com" senden. Die E-Mail-Adressen "Secure @" und "Security @" sind die E-Mail-Boxen, die Unternehmen eingerichtet haben, wenn sie von solchen Entdeckungen betroffen sind.

Speichern Sie die Antworten, die Sie vom Unternehmen erhalten.

Wenn sich herausstellt, dass das Unternehmen das Problem nicht beheben wird, senden Sie eine Nachricht an die Mailingliste " vollständige Offenlegung". Beschreiben Sie das Problem kurz, zeigen Sie den Beweis und die Antwort.

Lesen Sie die E-Mail-Postings in der Liste mit den vollständigen Angaben, um zu sehen, wie andere Personen dies getan haben.

"Der erste Schritt besteht darin, Beweise zu finden, indem Sie beispielsweise Wireshark ausführen, um die Passwörter zu erfassen, die auf dem Draht gesendet werden." - das wird * nichts * beweisen. Um sich anzumelden und anzumelden, müssen Sie natürlich Ihr Klartext-Passwort an deren Server senden. Wie sonst könnte der Server das Passwort verarbeiten und Sie authentifizieren? Das eigentliche Problem ist, dass Passwörter als Klartext in einer Datenbank * gespeichert * werden.
Außerdem wird die Site wahrscheinlich unter https ausgeführt, sodass Sie die Verbindung MITM müssen, um die Anmeldeinformationen zu erfassen und zu erfassen
Bernard
2012-02-03 07:02:44 UTC
view on stackexchange narkive permalink
  1. Verwenden Sie kein System, von dem Sie nachweisen können, dass es unsicher ist, wenn es sicher sein soll.
  2. Wenden Sie sich an das Unternehmen / den Eigentümer, das für die Entwicklung des Systems verantwortlich ist, und teilen Sie Ihren Beweis für seine Unsicherheit mit.
  3. Wenn Sie von der Firma / dem Eigentümer eine ungünstige Antwort erhalten, die darauf hinausläuft, dass sie nicht bereit sind, das System zu Ihrer Zufriedenheit zu korrigieren, wechseln Sie zu einem anderen System.
woliveirajr
2012-02-03 17:39:57 UTC
view on stackexchange narkive permalink

Was sind Best Practices im Umgang mit diesem System? :

Verwenden Sie dieses System nicht mit vertraulichen Informationen. Überlegen Sie, welche Probleme für Sie auftreten würden, wenn Daten verloren gehen oder wenn jemand beginnt, das System mit Ihrem Login zu verwenden. Wenn dies nicht der Fall ist, verwenden Sie das System nicht mehr.

[Best Practices im Umgang] und die Eigentümer dieses Systems :

Registrieren Sie Ihre Unzufriedenheit Verwenden von E-Mails und anderen Kontaktmitteln: Kundensupport, Telefonanruf, Kontakt-E-Mails, Foruns, Blogs, Wikis ...

bei gleichzeitiger Minimierung des Risikos für sich selbst durch die Verwendung des Systems :

Wenn Sie der Meinung sind, dass Sie dieses System trotzdem verwenden werden, verwenden Sie nicht dasselbe Kennwort für dieses System und jedes andere System. Wenn Sie Ihre E-Mail nicht als Login verwenden können, ist dies sogar noch besser.

oder Berichterstattung über die damit verbundenen Probleme?

Die gleichen anderen Antworten haben Ihnen Folgendes mitgeteilt: Registrieren Sie alle Ihre Beschwerden, verwenden Sie sie nicht mehr.

syneticon-dj
2011-09-14 20:14:55 UTC
view on stackexchange narkive permalink

Das Ändern des Passworts wurde bereits vorgeschlagen. Ändern Sie es in "Speichern Sie keine Passwörter im Klartext, Sie Lamers!" Wenn Sie sie dann per E-Mail bitten, Ihr Konto zu entfernen und alle persönlichen Daten zu löschen, wird Ihre Nachricht möglicherweise besser gehört.

Abgesehen davon sind Kennwörter im Klartext kein so großes Problem, da selbst Kennwortdatenbanken gehasht wurden kann heutzutage in angemessener Zeit von Bruteforce angegriffen werden, insbesondere wenn die Hash-Daten kein Salz enthalten.

fwgx
2012-02-06 14:27:30 UTC
view on stackexchange narkive permalink

Was ist der Unterschied zwischen dem Speichern und Versenden eines Klartext-Passworts und dem Versenden eines eindeutigen Links zu einer Seite, um Ihr Passwort zurückzusetzen, wenn Sie es vergessen?

Ich denke, wenn Sie dasselbe Passwort auf einer anderen Site verwenden könnte bedeuten, dass ein Hacker auf Ihre anderen Konten zugreifen kann. Oder wenn sie die gesamte Site beschädigen und auf die Datenbank zugreifen, und selbst dann, was hindert sie daran, die Salze zu erhalten, die zum Verschlüsseln Ihrer Passwörter verwendet werden.

Senden der Passwörter im Klartext (oder mit einem eindeutigen Link) zu einem Rücksetzformular) über E-Mail macht keinen Unterschied für ihre Fähigkeit, auf die Website zu gelangen, wenn der Hacker Zugriff auf Ihre E-Mail hat. Sie sind im Grunde genommen durcheinander, es sei denn, die Site hat die Richtlinie, Ihnen nur Passwörter per Post zu senden, wenn Sie diese vergessen haben, oder erfordert ein Authentifizierungstoken, wie es die Banken für Chip-and-Pin-Geräte jetzt benötigen.

Ein Link zum Zurücksetzen des Kennworts kann als Einmalverwendung konfiguriert werden. Wenn der legitime Benutzer zuerst darauf klickt, kann ein Angreifer es nicht verwenden. Der Link kann auch ablaufen, falls der Benutzer die Nachricht nicht erhält.
Stimmt, aber wenn jemand auf Sie zielt, macht das keinen Unterschied. Wenn sie Ihren E-Mail-Verkehr abhören oder auf andere Weise auf Ihr Postfach zugreifen (was hier vorausgesetzt wird, da es sich um das Versenden von E-Mails im Klartext handelt), müssen sie nur auf "Ich habe mein Login vergessen" klicken "und sie werden da sein, bevor du überhaupt weißt, dass du die Post hast. Es spielt keine Rolle, dass das Zeitlimit überschritten wird oder nur einmal verwendet wird. Sie drücken es erst, wenn sie bereits Ihren Datenverkehr abhören und dem Link sofort folgen. Die einzige sichere Sache wäre, das Konto zu sperren und einen Link- / Entsperrcode per E-Mail zu senden.
Der Vollständigkeit halber hier diese Frage für sich mit einer guten Antwort: http://security.stackexchange.com/questions/13026/email-forgotten-password-or-send-reset-link-both-just-as-insecure
user7610
2014-12-08 18:30:48 UTC
view on stackexchange narkive permalink

Es ist nichts Falsches daran, Klartextkennwörter zu speichern. In mancher Hinsicht ist dies die beste Lösung.

[nicht] Das Speichern von Passwörtern im Klartext schränkt die Sicherheit der Kommunikation ein.

Es ist sicherer, verschlüsselte Passwörter zu senden über das Netzwerk und speichern Sie sie im Klartext in der Datenbank, als die Kennwörter im Klartext über das Netzwerk zu senden und sie verschlüsselt in der Datenbank zu speichern.

Mit anderen Worten, der Server muss das Benutzerkennwort kennen unterstützen die sichersten Authentifizierungsmechanismen.

Quelle: ejabberd Book, Kapitel Speichern von Kennwörtern im Klartext in der Datenbank aus Sicherheitsgründen ( Link)

Nachricht an die Downvoter: Stimmen Sie nicht nur ab, sondern sagen Sie, warum Ihnen meine Antwort nicht gefällt. Das Speichern von Passwörtern im Klartext ist in der Jabber-Welt eine gute und gängige Praxis.
Wenn dies für ein Produkt spezifisch ist, sollte die Antwort dies sagen. Ansonsten ist dies eine gefährliche und irreführende Antwort. Das Speichern als Klartext ist ** nie ** sicherer als das Speichern von Hash. Das Umgehen einer Produktbeschränkung ist im Allgemeinen nicht sicherer.
Darüber hinaus scheint die Person, die dieses "Buch" geschrieben hat (eher eine FAQ auf einer Website), die Sicherheit oder die Bedeutung von Hashing-Passwörtern nicht zu verstehen. Kein kompetenter Programmierer (mit einem Verständnis für Sicherheit) würde sich für eine Klartext- * oder * verschlüsselte Speicherung von Passwörtern einsetzen.
@ChrisMurray Plaintext bietet Ihnen die Möglichkeit, Ihr Authentifizierungsschema zu aktualisieren, wenn etwas Besseres verfügbar wird. Manchmal können Sie das Upgrade nicht durchführen, wenn Sie den Hash gespeichert haben. Dann müssen Sie weiterhin das alte, weniger sichere Authentifizierungsschema verwenden.
@ChrisMurray Darüber hinaus bietet Klartext die Flexibilität, mehrere Authentifizierungsmethoden für verschiedene Zwecke zu verwenden. Angenommen, ich möchte Besucher auf meiner Webseite mit HTTP Digest authentifizieren. Dafür brauche ich Klartext-Passwörter.
das macht keinen Sinn. Warum sollte sich derselbe Benutzer mit demselben Kennwort mit einem niedrigeren Sicherheitsniveau als normal anmelden? Die untere Ebene wird zu Ihrem schwächsten Glied und genau dort, wo ein Angreifer zuschlägt. Wenn etwas sicher sein muss, muss es tatsächlich sicher sein. Es macht keinen Sinn, ein Passwort zu verwenden, wenn es als einfacher Text angezeigt wird, da dies die gesamte Sicherheit aufhebt und ein ** falsches ** Sicherheitsgefühl hinterlässt, das wohl schlimmer ist als ** keine ** Sicherheit.
Genau. Durch das Verschlüsseln oder Hashing der Passwörter erhalten Sie ein ** falsches ** Sicherheitsgefühl. Mit der Verschlüsselung erhält der Angreifer wahrscheinlich gleichzeitig Ihre Passwörter * und Ihren Schlüssel *. Und jedes Hashing-Schema wird irgendwann gebrochen, wenn genügend Rechenleistung vorhanden ist. Mit Klartext wissen Sie immer, wo Sie stehen. Es gibt keinen Anspruch auf Endpunktsicherheit. Endpunkte sind unsicher, was auch immer Sie tun. Schauen Sie sich zum Beispiel die kürzlich bekannt gewordenen SSL-Fehler an. Konzentrieren Sie sich stattdessen auf die Sicherung der Kommunikation. Dies ist der einzige Bereich, in dem Sie die Chance haben, die Sicherheit erheblich zu erhöhen.
Hashing ist nicht dasselbe wie Verschlüsselung. Hashing ist nicht umkehrbar und es ist ** kein ** Schlüssel zu bekommen.
Um das Hashing richtig zu verstehen, lesen Sie die ausgezeichnete Antwort von Thomas Pornin [hier] (https://security.stackexchange.com/questions/211/how-to-securely-hash-passwords).
Ich habe nie etwas über Schlüssel gesagt, als ich über Hasking sprach. Alles, was ich gesagt habe, ist * Und jedes Hashing-Schema wird irgendwann gebrochen, wenn genügend Rechenleistung vorhanden ist. * Und ich stehe dazu.
Und jedes Schloss kann geöffnet werden, wenn genügend Geschick und Zeit vorhanden sind. Sollten wir uns nicht die Mühe machen, unsere Türen zu verschließen?
Ich würde Hashing-Passwörter nicht mit dem Verschließen von Haustüren vergleichen. Es ist eher so, als würde man Balken an Fenstern installieren, etwas "Extra". Und ja, Sie sollten sich nicht die Mühe machen, vergitterte Fenster zu installieren, wenn Sie nur ein billiges Schloss an Ihrer Tür haben und die Tür trotzdem leicht geöffnet werden kann. Web-Apps haben normalerweise eine Menge Probleme mit der Websicherheit: XSS, SQL-Injektionen und so weiter. Man sollte sich darauf konzentrieren und nicht zu viel Zeit mit dem verschwenden, was im Wesentlichen Verschleierung ist. Entwickler von Chrome-Browsern wissen, dass https://news.ycombinator.com/item?id=6166731
Sie verstehen Hashing nicht, wenn Sie denken, dass es "im Wesentlichen Verschleierung" ist. Sie können eine Hashing-Funktion nicht umkehren. Ja, es lohnt sich, Ihre Zeit auf die kritischste Sicherheitsanfälligkeit in Ihrer App zu konzentrieren, aber das bedeutet nicht, dass Sie alle anderen Fehler ignorieren können. Das Speichern eines Passworts im Klartext ist ** nie ** besser als das Speichern von Hash, und Sie haben keine gegenteiligen Beispiele angegeben.
Natürlich kann ich. Ich kann es brutal erzwingen. Da die Eingabe nicht gleichmäßig verteilt war ('password1' ist wahrscheinlicher als 'asd865 $ * sdf.aa'), habe ich gute Chancen, relativ schnell vernünftige Ergebnisse zu erzielen.
* Das Speichern eines Passworts im Klartext ist niemals besser als das Speichern eines Hashs, und Sie haben keine gegenteiligen Beispiele angegeben. * Sie haben Recht. Es gibt jedem mehr Zeit zu reagieren, falls ein Leck auftritt. Menschen neigen dazu, Passwörter wiederzuverwenden, daher ist dies sicherlich wertvoll. Ich werde meine "Antwort" löschen, damit ich nicht noch mehr Downvotes bekomme.
Die Hauptanwendung bei der Aufbewahrung nicht verwaschener Kennwörter besteht darin, dass Sie eine Authentifizierung vom Typ "Challenge-Response" durchführen können (wie den von jemandem erwähnten HTTP-Digest, der für unverschlüsselte Verbindungen nützlich ist). TLS mit kostenlosen Zertifikaten macht dies jedoch weniger erforderlich ...
-1."Es ist sicherer, über das Netzwerk verschlüsselte Passwörter zu senden und im Klartext in der Datenbank zu speichern, als die Passwörter über das Netzwerk im Klartext zu senden und in der Datenbank verschlüsselt zu speichern." Dies ist eine falsche Zweiteilung, da nichts das sagtDas Passwort muss im Klartext übertragen werden, wenn es verschlüsselt gespeichert wird.Das Passwort muss (im Klartext) ** über einen verschlüsselten Kanal (TLS) ** gesendet werden.Es gibt auch viele andere falsche Aussagen in dieser Antwort und relativen Kommentaren, aber dies sollte ausreichen, um diese Antwort als völlig falsch zu qualifizieren.
_Sie können eine Hashing-Funktion nicht umkehren._ Das ist einfach nicht wahr.Jede Hash-Funktion muss kollidierende Eingaben haben.Bei ausreichender Rechenleistung können Sie eine Kollision mit dem Passwort feststellen.Welches ist ein ebenso gutes Ergebnis.
Kollision finden! = Hash umkehren.Das ist sehr wahr, wenn Sie die richtigen Wörter für die Dinge verwenden.Und bitte erklären Sie mir, wie ein ** theoretisches ** Knacken des Hashs (viel Glück beim Bruteforcing von `scrypt` oder` argon2`!) Bedeutet, dass das Speichern des Passworts im Klartext" nichts Falsches "ist.Es ist wie zu sagen, dass es keinen Sinn macht, Ihre Haustür zu verriegeln, wenn Sie nach draußen gehen, da sie mit genügend Aufwand geöffnet werden kann.Das stimmt einfach nicht.


Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...