Frage:
Wie kann ich wissen, dass Entwickler ethisch korrekt sind und mein Passwort nicht im Klartext aufzeichnen?
poush
2015-06-07 10:03:38 UTC
view on stackexchange narkive permalink

Ich frage nicht, warum Hashing durchgeführt werden sollte. Stattdessen möchte ich wissen, wie verhindert werden kann, dass Entwickler Benutzerkennwörter aufzeichnen, um die anderen Konten ihrer Benutzer, insbesondere ihre E-Mails, zu hacken.

Könnten sie die Kennwörter ihrer Benutzer nicht im Klartext speichern, ohne dass die Benutzer dies wissen? P. >

Gibt es eine Möglichkeit für einen Benutzer, dies zu erkennen / zu verhindern?

Sie können nicht, deshalb ist es wichtig, unterschiedliche Passwörter auf verschiedenen Websites zu verwenden. Zumindest, wenn Sicherheit für Sie wichtig ist (zufällige Foren oder E-Commerce-Websites spielen möglicherweise keine Rolle). Wenn Sie Schwierigkeiten haben, sich all diese Passwörter zu merken, verwenden Sie einen Passwort-Manager.
@paj28 Das ist * ein Grund *, warum es wichtig ist. Da sind andere.
Eine Seite, die dies tut, ist Mint.com. Ich weiß nicht, ob sie meine Bankkennwörter im Klartext speichern, aber sie müssen zumindest in der Lage sein, meine Kennwörter im Klartext zu rekonstruieren, da die meisten Banken keine ordnungsgemäß authentifizierten APIs haben, um auf ihre Daten zuzugreifen. Trotzdem benutze ich Mint trotz dieser großen Sicherheitslücke immer noch. Die Benutzerfreundlichkeit der Website / Android-Anwendung meiner eigenen Bank ist so schrecklich, dass ich die gute Sicherheit zugunsten der tatsächlichen Nutzung so gut wie aufgegeben habe.
Es besteht zwar kein Risiko, dass dies zu Fehlalarmen führt, aber es gibt sicherlich viele falsche Fehler: Fragen Sie Websites nach Ihrem Passwort. Wenn sie es Ihnen im Klartext zurückgeben, anstatt ein neues Passwort zu erzwingen, können Sie sicher sagen, dass es gespeichert ist im Klartext. Offensichtlich könnten sie es im Klartext speichern, aber Sie trotzdem zwingen, ein neues zu erstellen. Dies ist eher ein naiver Entwickler als ein unheimlicher.
Warum gibt es noch keine standardisierte Möglichkeit zur Authentifizierung mit öffentlichem Schlüssel? (Lassen Sie den Browser ein Schlüsselpaar generieren und nur den öffentlichen Schlüssel an den Server senden. Speichern Sie dann den privaten Schlüssel lokal, optional mit einem Kennwort.)
Wenn Sie die Hardware und Software der Site zum Zeitpunkt der Eingabe Ihres Kennworts nicht vollständig untersuchen können, können Sie nicht "sicher" sein.
Vergessen Sie nicht, dass es nicht nur um Passwörter geht - einer der Gründe, warum ich "Fragen zum Zurücksetzen von Passwörtern" hasse, ist, dass Sie mehr oder weniger gezwungen sind, auf allen Websites (die dieselben haben) dieselben zu verwenden Fragen - sehr häufig). Natürlich werden Passwörter am häufigsten * automatisch * missbraucht, aber es gibt auch andere Informationen, die gegen Sie verwendet werden können (wie "die letzten 4 Nummern Ihrer Kreditkarte" usw.) - jede für sich, aber zusammen harmlos ... und ich würde mich eher vor naiven Entwicklern hüten als vor böswilligen. Zumindest solange Sie nicht viele `.ru`-Websites besuchen: D.
Du weißt es nie. Ich selbst habe ein internes System erstellt, in dem das Kennwort jedes Mal gespeichert wird, wenn sich ein Benutzer beim System authentifiziert. Es funktioniert eine Weile gut, bis ich mich faul fühle und es aus dem System entferne.
@Luaan hat einen wirklich guten Punkt - aus diesem Grund verwende ich falsche Antworten auf diese Fragen, selbst auf den wichtigsten Websites (alles Finanzielle) ... Ich kann jederzeit zur Bank gehen, wenn dies unbedingt erforderlich ist, um meine Identität zu beweisen.
@user1801810 Ich verwende lange zufällige Zeichenfolgen als Antworten und speichere sie an einem relativ sicheren Ort. Wenn ich sowohl den sicheren Ort als auch das Passwort verliere, gibt es direktere Möglichkeiten, sich verifizieren zu lassen. Es ist nur eine weitere Sache, bei der man vorsichtig sein muss :( Und sie nennen es * Verbesserung * der Sicherheit ...
Sie können nicht wissen, ob sie sich ethisch (und kompetent) mit Ihren Daten verhalten, aber Sie können manchmal herausfinden, wann dies nicht der Fall ist. Wenn Sie Passwörter im Klartext speichern und in [** Plain Text Offenders **] (http://plaintextoffenders.com/) erscheinen, ist es eine große rote Fahne, vorsichtig mit dem zu sein, was Sie ihnen geben.
@StephanBranczyk Ich möchte hinzufügen, dass Sie, nachdem Sie für mehrere Bankinstitute in ihren verschiedenen "Sicherheitsabteilungen" gearbeitet haben, definitiv nicht darauf vertrauen, dass sie Ihr Passwort sicher, nicht umkehrbar und verschlüsselt aufbewahren.
Mit @immibis TLS können Client-Zertifikate für den Server bereitgestellt werden, die für Authentifizierungszwecke verwendet werden können. Die Generierung ist jedoch teuer (sowohl in Bezug auf Zeit als auch auf Entropie), die Übertragung zwischen Geräten ist im Allgemeinen schwierig und die Benutzeroberfläche ist normalerweise inkonsistent über Implementierungen hinweg (und manchmal zwischen Versionen wechseln). Vorbehaltlich von auf der Website auferlegter Einschränkungen wie der maximalen Kennwortlänge (die beispielsweise bei ordnungsgemäßem Kennwort-Hashing nicht erforderlich sein sollte) können Kennwörter beliebig komplex gemacht werden. TLS-Client-Zertifikate weisen auch einige praktische Probleme bei der Verwendung auf.
Selbst wenn Sie darauf vertrauen können, dass sie sich perfekt ethisch verhalten, können Sie nicht darauf vertrauen, dass sie niemals Fehler machen. Jeder macht Fehler, und jemand könnte einen seiner Fehler machen, wenn er codiert, wie Ihr Passwort gespeichert wird.
"Code Reviews" ....
Sie können nicht, ich habe Websites, die ich codiert habe, noch bevor ich an die Universität kam, und ja, sie speichern immer noch Klartext-Passwörter .. / Entwickler sind faul, wenn das Framework es nicht nativ unterstützt, gibt es ein HochRisiko, dass sie kein Hashing implementiert haben.Verwenden Sie Passwort-Manager!
Fünf antworten:
AviD
2015-06-07 14:24:28 UTC
view on stackexchange narkive permalink

Natürlich könnten sie es, aber dann könnten sie sich auch jedes Mal eine E-Mail senden, wenn Sie Ihr Passwort ändern.

Abhängig von der Art des Systems gibt es jetzt zahlreiche Vorschriften, Audits, Überprüfungen und Prozesse, die relevant sein können, um sicherzustellen, dass die Entwickler dies nicht tun, oder viele andere Arten von böswilligen Aktivitäten . Als Verbraucher haben Sie jedoch normalerweise nicht viel Einblick in all dies - außer wenn es schief geht, zum Beispiel, wenn sie Ihnen Ihr ursprüngliches Passwort per E-Mail senden, wenn Sie darum bitten, es zurückzusetzen.

Aber Sie stellen hier die falsche Frage.
Ja, es ist wichtig, dass alle von Ihnen verwendeten Systeme sicher entwickelt werden, aber dadurch wird niemals das Element des impliziten Vertrauens entfernt, das Sie immer in das System haben System selbst - und in diesem Zusammenhang entsprechen die Entwickler dem System selbst.

Die eigentliche Frage, die Sie sich stellen sollten - und tatsächlich scheinen Sie dies zu implizieren - ist, wie Sie Ihre anderen Konten auf anderen Systemen vor einem böswilligen Entwickler schützen können oder System .
Die Antwort ist wirklich einfach - verwenden Sie für jedes System ein anderes Passwort.

Lassen Sie mich dies zur Hervorhebung wiederholen:

VERWENDEN SIE NIEMALS PASSWÖRTER FÜR VERSCHIEDENE SYSTEME.

Erstellen Sie für jede Site ein eindeutiges (starkes, zufälliges usw.) Passwort und geben Sie niemals Ihr Passwort für SiteA in SiteB ein.
Denn wie Sie intuitiv bemerkt haben, wenn SiteB dies getan hat Wenn Sie Ihr Passwort für SiteA in irgendeiner Form haben, ist dieses Passwort für SiteB nicht mehr sicher.

Nur zum Spaß, hier ist eine xkcd dazu:

XKCD Password Reuse


Eine letzte Anmerkung, wenn Sie beginnen sich Sorgen zu machen "Wie zum Teufel werde ich mir ein sicheres Passwort unabhängig für jede andere Site merken? !!?" - Sehen Sie sich diese Frage hier in Passphrasen an und schauen Sie sich auch Passwort-Manager an (z. B. Password Safe, Keepass, LastPass, 1Pass usw.).

Eine Alternative zu einem separaten Kennwort für jede Site besteht darin, eine Handvoll von Passwörtern zu verwenden, die Sie verwenden, und zwischen der Sicherheitsstufe einer Site und dem Vertrauen zu wechseln. I.E. Ein Passwort für Ihre E-Mail (das das Zurücksetzen des Passworts steuert), eines für Ihre Bankinstitute und ein anderes für alle beschissenen Websites (Foren / Spieleseiten, Websites, die Sie zwingen, ein Konto zu erstellen usw.). Genau wie Sie eine Spam-E-Mail haben (oder sollten), sollten Sie ein Spam-Passwort haben.
Anstelle von Passwort ** Managern ** würde ich einen Passwort ** Generator ** empfehlen. Es werden eindeutige Passwörter aus der Adresse der gehashten Website + Ihrem Hauptkennwort erstellt. Dies erspart Ihnen nicht nur das Speichern von Passwörtern, sondern auch das Erstellen von Passwörtern!
Die fortlaufende Verwendung von Passwortgeneratoren, wie Sie sie beschreiben, ist problematisch für @Agent_L. Sie berücksichtigen Änderungen des Hauptkennworts oder der Site-Kennwörter nicht sehr gut. Wenn jemand in der Lage ist, stattdessen einen Passwort-Manager zu verwenden, sollte er dies wahrscheinlich tun.
n00b - Wenn ich also Ihr Passwort von einem Angriff auf eine Bank erhalte, bei der Informationen verloren gehen, kann ich alle Ihre Bankkonten abrufen? Hmmm - nicht dein bester Plan!
@PwdRsch Wie alles geht es um Sicherheit und Benutzerfreundlichkeit und jedes Mal darum, das richtige Tool für eine bestimmte Aufgabe auszuwählen. Sicher, für Hauptpostfach und Bank gibt es eindeutige Passwörter, die nirgendwo gespeichert, sondern gespeichert werden sollten. Aber die meisten von uns haben Dutzende von Konten, deren Sicherheit so gut wie nichts bedeutet. Generatoren sind dafür perfekt geeignet, da die soeben beschriebenen Nachteile nie auftreten.
@agent_l Jeder Passwort-Manager, den ich untersucht habe, enthält einen Passwort-Generator, wenn Sie ein neues Passwort benötigen. Ich bezweifle, dass jemand tatsächlich seine eigenen Passwörter erfunden hat, wenn er einen Manager verwendet.
Generatoren klingen cool, aber wenn Sie Ihre Passwörter immer mit demselben Start- und Site-Namen generieren und das Ergebnis nie speichern, wie setzen Sie Ihr Passwort auf einer Site zurück, die kompromittiert wurde? Nein, Passwort-Manager sind der richtige Weg. Jedem meiner Konten, egal wie wichtig oder trivial, ist ein eindeutiges 16-stelliges Zufallskennwort zugeordnet.
@Mikkel 16 Zeichen? Das ist Grundschule ;-) Wenn du dich sowieso nicht daran erinnern musst, dreh es auf! 26 Zeichen, 32, einfach ... (Obwohl es fraglich ist, wie viel zusätzlichen Nutzen Sie nach beispielsweise 26 Zeichen erhalten würden ...)
@Agent_L Wie bereits erwähnt, enthalten alle anständigen Passwortmanager die Passwortgenerierung (das ist Teil der Verwaltung, es ist nicht nur "Erinnern"). Ich war nicht explizit, aber das wird immer angenommen, wenn wir über Passwortmanager sprechen.
@sgroves, AviD, Mikkel - keiner von Ihnen hat meinen Hauptpunkt angesprochen: Wichtige Passwörter sind zu wichtig, um sie in einem Manager zu speichern. Triviale Passwörter sind zu trivial, um sie in einem Manager zu speichern. Das ist der Punkt: Es ist mir egal, ob mein Stack-Passwort kompromittiert wurde - ich kann zu wenig verlieren, um mich darum zu kümmern. Ich verwende keine Manager zum Speichern meines Workstation-Kennworts - es ist zu wichtig, um irgendwo gespeichert zu werden (außerdem kann ich keinen Manager für die Windows-Anmeldung verwenden). Wie auch immer, diese Diskussion ist grob offtopisch, da selbst die Antwort nicht zum Thema gehört.
@Agent_L, aber ich habe das angesprochen. Wichtige Passwörter müssen sicher sein - wirklich stark, zu stark, um sich zu erinnern. Auf der anderen Seite gibt es Situationen, in denen Sie sich das Passwort tatsächlich merken müssen - und hier kommen Passphrasen ins Spiel, wie ich in meiner Antwort erwähnt habe.
"Aber du stellst hier die falsche Frage." Nein, du beantwortest die falsche Frage. Der erste und zweite Absatz sind in Ordnung, der Rest bläht ihn nur auf.
@ChristianStrempfer warum denkst du, ist es die falsche Frage? Dem OP war klar, dass er sich Sorgen darüber macht, dass die Entwickler sein Passwort verwenden, um auf sein E-Mail-Konto zuzugreifen. Ich habe klargestellt, warum "wie verhindert werden kann, dass Entwickler Benutzerkennwörter aufzeichnen" die falsche Lösung ist, und außerdem. Es war klar, dass dies ein Fall von XY-Problem ist; Ich konzentrierte ihn auf die Grundursache und wies ihn auf tatsächliche Lösungen für sein eigentliches Problem hin.
@agent_l Welche Passwörter sind zu wichtig, um sie in einem Manager zu speichern? Vielleicht etwas für die Arbeit, aber Sie könnten dafür ein separates Konto verwenden. Ich werde gerne alle Passwörter in einem Manager speichern ... es ist alles lokal gespeichert.
@AviD: Für mich ist das kein XY-Problem. Dem OP ist bekannt, dass die Kenntnis des einfachen Passworts verwendet werden kann, um eine andere Site zu "hacken". Es ist eine kurze Frage auf den Punkt.
@AviD: Versteh mich nicht falsch. Es ist kein Problem, dass Sie die Gefahren der Wiederverwendung von Passwörtern erwähnen, aber es macht 90% der Höhe der Antworten auf dem Bildschirm aus, während es nur eine Randnotiz sein sollte.
@ChristianStrempfer the OP stützt seine Risikobewertung der Bedrohung "unethischer Entwickler, der das Passwort nicht hascht" auf die Annahme einer Wiederverwendung des Passworts. Für mich schien dies der Kern zu sein, weshalb ich sagte, es sei ein XY-Problem, IMO. Aus diesem Grund habe ich mich bei den meisten Antworten darauf konzentriert, auf das Problem der Wiederverwendung von Passwörtern zu reagieren.
Grizzled
2015-06-07 15:48:17 UTC
view on stackexchange narkive permalink

Sie können nicht wissen, dass sich jemand ethisch oder weise verhält.

  1. Verwenden Sie Kennwörter niemals standortübergreifend wieder.
  2. Entscheiden Sie, wie viele Informationen geteilt werden sollen.
  3. Halten Sie nicht erforderliche Informationen zurück und vermuten Sie eine Website, die mehr Informationen anfordert, als für einen bestimmten Service erforderlich ist.
  4. ol>

    Ich befürchte, dass einige Entwickler dies nicht tun Es ist nicht vorausschauend genug, um die Auswirkungen eines Informationslecks auf die Benutzer zu verstehen. Schützen Sie sich also, anstatt sich auf andere zu verlassen.

+1 "oder mit Bedacht", weil es für mich kaum einen praktischen Unterschied gibt zwischen einem Programmierer, der absichtlich mein Passwort stiehlt, und einem Systemadministrator, der die Linux-Installation blockiert, der Server gerootet wird und ein Hacker mein Passwort stiehlt. Wenn überhaupt, würde ich es * etwas * vorziehen, es ist der Programmierer, da die betroffene Firma zumindest eine Adresse hat, die sie den Polizisten geben kann.
... hat eine Adresse für die Polizei: Ich bin Freiberufler und arbeite in Asien. Kaum jemand fragt nach meiner Adresse. Entwickler und Systemadministratoren vertrauen jedoch am stärksten auf die Kette.
fotijr
2015-06-08 18:22:12 UTC
view on stackexchange narkive permalink

Wie andere bereits gesagt haben, können Sie nach der Übergabe nicht vollständig wissen, was die Entwickler mit Ihren Daten tun. Es kann Ihnen ein gewisses Vertrauen geben, die Funktionsweise der Site zu überprüfen, um festzustellen, ob sie den bewährten Sicherheitsmethoden für die für Sie sichtbaren Teile des Systems entspricht.

  • Verwenden sie HTTPS auf Seiten mit vertraulichen Informationen (einschließlich Login)?
  • Vermeiden sie es, die Passphrase irgendwohin zu übertragen, einschließlich E-Mail (nicht einmal an Sie)?
  • Ermöglichen sie eine Zwei-Faktor-Authentifizierung?

Das Aktivieren dieser Kontrollkästchen garantiert nicht, dass sie anderswo nichts Schattiges tun, aber es gibt Ihnen ein besseres Gefühl dafür, wie die Entwickler haben die Site eingerichtet.

Wie bereits erwähnt, ist die Vermeidung der Wiederverwendung von Kennwörtern die wichtigste Sicherheitspraxis, die Sie befolgen können, um sich selbst zu schützen.

Ich würde ein zusätzliches Kontrollkästchen hinzufügen, um Folgendes zu aktivieren: "Schränken sie unnötig ein, welche Zeichen Sie in Ihrem Passwort verwenden können?" Ein richtig gehashtes Passwort ist schwer von zufälligen Binärdaten zu unterscheiden. Daher muss alles, was einen solchen Hash speichert, in der Lage sein, jede mögliche Sequenz zu berücksichtigen (z. B. indem der Hash zur Speicherung hexadezimal codiert und dann entschlüsselt wird, wenn Sie müssen etwas mit dem Hash vergleichen. Wenn die Site einschränkt, welche Zeichen Sie in Ihrem Passwort verwenden können, kann dies daran liegen, dass jemand es nicht richtig speichert.
@TheSpooniest: Der Code, der erforderlich ist, um ASCII-Zeichenfolgen in Folgen von Bytes abzubilden, sodass Zeichenfolgen, die gleich sind, immer dieselbe Folge von Bytes ergeben, ist trivial. Der Code, der ebenfalls für alle möglichen Unicode-Zeichenfolgen erforderlich ist, ist äußerst kompliziert und weist viele seltsame Eckfälle auf, insbesondere wenn man die Möglichkeiten gemischter Zeichen von links nach rechts und von rechts nach links berücksichtigt. Man könnte viele Nicht-ASCII-Zeichen ohne Schwierigkeiten zulassen, aber es ist einfacher, eine kleine Liste zulässiger Zeichen anzugeben, als zu erklären, welche Zeichen zulässig sind und welche nicht.
@supercat: Das gilt nur, wenn Sie versuchen, Benutzern Passwörter anzuzeigen, und ich hoffe wirklich, dass Sie das nicht tun. Wenn dies nicht der Fall ist, wählen Sie einfach eine intern zu verwendende Codierung aus, codieren das Kennwort entsprechend, führen es durch Ihren Hashing-Algorithmus und Base64 oder Hex-Codierung. Danach müssen Sie nur noch sicherstellen, dass Ihre Kennwortfelder diese Codierung verwenden oder dass Sie die verwendete Codierung erkennen können, wenn sie aus irgendeinem Grund eine andere verwenden müssen.
@TheSpooniest: Mit ASCII kann man ziemlich gut garantieren, dass jedes ASCII-Zeichen einen Codepunkt generiert, wenn jemand "Fred123" als Passwort eingibt. Wenn jemand ein Passwort mit diakritischen Zeichen oder einer Mischung aus Zeichen von rechts nach links oder von links nach rechts eingibt, kann die genaue Reihenfolge der empfangenen Codepunkte in verschiedenen Browsern unterschiedlich sein. Wenn jemand einen Kombinationsakzent gefolgt von einem Buchstaben eingibt und die Kombination in den Tabellen einiger Browser, jedoch nicht in anderen, angegeben ist, geben einige Browser dies möglicherweise als ein Zeichen und einige als zwei an. Wenn man einfachen Text speichern würde, wäre es möglich ...
... um zu sagen, dass Sie ein Kennwort akzeptieren, dessen normalisierte Form mit der normalisierten Form der Datenbank übereinstimmt, und sich nicht um die Möglichkeit sorgen müssen, dass eine falsche Normalisierungstabelle dazu führen kann, dass die Datenbank einen Hash speichert, der nicht korrekt übereinstimmt. normalisierte Passwörter, nachdem die Tabelle repariert wurde.
Andrew Smith
2015-06-07 13:14:35 UTC
view on stackexchange narkive permalink

Sie können feststellen, dass sie Ihr Passwort erhalten können, wenn das vergessene Passwortsystem Ihnen Ihr altes Passwort per E-Mail senden kann. Wenn Sie gezwungen sind, ein neues zu generieren oder festzulegen, ist es dennoch möglich, dass diese in Klartext / 2-Wege-Verschlüsselung gespeichert sind.

Sie können dies auch feststellen, indem Sie sich für ein kostenloses Hotmail-Konto anmelden Wenn Sie sich bei einigen (vertrauenswürdigen) Websites mit demselben Kennwort anmelden, prüfen Sie, ob etwas passiert.

Ansonsten können Sie es nicht wirklich sagen.

Agent_L
2015-06-08 22:25:48 UTC
view on stackexchange narkive permalink

Der einzige Weg, wie eine Website beweisen kann, dass Ihr Passwort NICHT im Klartext gespeichert ist, besteht darin, es niemals im Klartext zu erhalten. Dies kann nur über ein clientseitiges Hashing-Skript erreicht werden. Sofern Sie den Website-Code und / oder den Datenverkehr nicht analysieren können, müssen Sie davon ausgehen, dass der Administrator Ihr Kennwort im Klartext vollständig kennt.

Siehe diese Frage eines Administrators, der dies wollte Geben Sie seinen Benutzern die Sicherheit, die Sie suchen. Es gibt viele interessante Antworten, obwohl sich die meisten auf Sicherheit konzentrieren, anstatt zu beweisen, dass kein Klartext gespeichert wird.

@cHao: Dies wurde in der Frage http://security.stackexchange.com/questions/23006/client-side-password-hashing erörtert, und das OP kam zu dem Schluss, dass der beste Weg, Dinge zu tun, das Hashing auf beiden Clientseiten warund am Server.Der serverseitige Hash behebt das von Ihnen erwähnte Problem der Kennwortwiedergabe, und der clientseitige Hash verhindert, dass die Website den Typ der vom Benutzer verwendeten Kennworttypen bestimmt (ähnliche Benutzerkennwörter zwischen Websites und / oder zwischen Kennwortänderungen).
@MarkRipley: Klingt nach einer guten Idee.Leider kann ich mich nicht genau erinnern, auf welchen Kommentar Sie antworten, da er nicht mehr zu existieren scheint.: P Aber wenn ich mir die Antwort ansehe, kann ich mir vorstellen, was ich gesagt hätte ...
@cHao AFAIK Sie haben sich in einem völlig anderen Problem eines Wiederholungsangriffs von der Seite verfolgt (oder wurden von der Seite verfolgt), genau wie die verknüpfte Antwort.


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...