Frage:
Wie fragen einige Websites (z. B. Online-Banken) nur nach bestimmten Zeichen aus einem Passwort, ohne es als Klartext zu speichern?
alexmuller
2011-06-27 15:47:52 UTC
view on stackexchange narkive permalink

Ich dachte, Wie kann ein System eine Mindestanzahl geänderter Zeichen erzwingen ... würde meine Frage beantworten, aber es scheint, dass dies ein anderer Fall ist.

Wenn ich unterschreibe Auf meinem Online-Banking-Konto werde ich aufgefordert, drei zufällige Ziffern von einer vierstelligen PIN und drei zufällige Zeichen von meinem (langen, zufälligen) Passwort einzugeben.

Aufgrund meines begrenzten Verständnisses all dessen, der Die Bank kann aus diesem Login keinen Passwort-Hash erstellen, da sie nicht mein gesamtes Passwort hat. Speichern sie mein Passwort im Klartext und vergleichen einzelne Zeichen? Ist es ein angemessenes Gleichgewicht zwischen Komfort und Sicherheit?

Diese Blog-Post hat Sie aufgefordert, diese Frage zu stellen: Wer kümmert sich um die Passwortsicherheit? NatWest nicht

Sie gehen davon aus, dass sie es NICHT als Klartext speichern;)
AviD macht einen guten Punkt. Ich habe ein Bankensystem gefunden, das offensichtlich Passwörter als Klartext speichert: Wenn Sie die Routine "Passwort zurücksetzen" durchlaufen, * senden sie Ihnen Ihr Passwort im Klartext per E-Mail zurück *!
@bstpierre - Welche Bank ist das? Ich möchte sie vermeiden !!!
Sechs antworten:
Rory McCune
2011-06-27 19:26:04 UTC
view on stackexchange narkive permalink

Obwohl ich nicht explizit weiß, wie Banken mit dieser Anforderung umgehen, besteht ein alternativer Prozess zu dem von @rakhi erwähnten darin, ein HSM und eine reversible Verschlüsselung zu verwenden.

Die Idee ist, dass das vollständige Passwort in der Datenbank gespeichert wird, die mit einer symmetrischen Verschlüsselung (z. B. AES) verschlüsselt ist. Wenn die Kennwortzeichen an die Anwendung übergeben werden, werden sie zusammen mit dem verschlüsselten Kennwort in den HSM eingegeben.

Der HSM könnte dann das Kennwort entschlüsseln und bestätigen, dass die 3 Zeichen wie erwartet sind, und einen Pass / zurückgeben. Antwort auf die Anwendung fehlschlagen. Das Passwort wird also zu keinem Zeitpunkt im Klartext gehalten (außer im HSM, das als sicher gilt).

Dies würde mit der Art und Weise zusammenhängen, wie die PIN-Verschlüsselung von ATM-Netzwerken (z. B. symmetrisch) gehandhabt werden kann Verschlüsselung und HSMs)

Oder machen Sie es ohne HSM - tatsächlich ist dies die Art und Weise (reversible Verschlüsselung durch die Anwendung), wie ich es bei mehreren namhaften Banken gesehen habe. Nicht die beste Vorgehensweise, entspricht jedoch den meisten Vorschriften (z. B. PCI). Und schützt fairerweise vor * den meisten * (aber definitiv nicht ALLEN) Bedrohungen, die für sie von Interesse und Priorität wären.
Gut zu wissen, dass es existiert, aber es scheint höchst unwahrscheinlich, dass dies tatsächlich getan wurde.
@Wildcard aus Neugier, was lässt Sie denken, dass es höchst unwahrscheinlich ist, dass eine Bank einen HSM zur Speicherung von Passwörtern verwendet?
Vielleicht nicht unwahrscheinlich für „eine Bank“, aber für diese Bank.Warum die Beschränkung auf 6-8 Zeichen, wenn sie so sicherheitsbewusst sind?
Viele ältere Banken verwenden Back-End-Systeme (z. B. Mainframes), bei denen die Kennwortlänge sehr veraltet ist.Sie nutzen HSMs auch häufig für die Schlüssel- / Geheimverwaltung.Ich habe Fälle gesehen, in denen Kennwortbeschränkungen auf Front-End-Systemen mit Einschränkungen des endgültigen Speicherorts des Kennworts zusammenhängen.
Jeff Ferland
2011-06-27 21:06:43 UTC
view on stackexchange narkive permalink

Jedes Mal, wenn Sie auf einen Fall stoßen, in dem Sie etwas anderes über Ihr Passwort als den Hash des vollständigen Passworts wissen müssen, können Sie davon ausgehen, dass das Passwort nicht gehasht ist. Obwohl PCI-DSS erwähnt wurde, gibt es keine mir bekannte Regelung, die für Banken gilt, die Kennwortinformationen verschlüsseln oder hashen. PCI-DSS deckt Ihre Bankkontoinformationen nicht ab, einschließlich der Anmeldung mit Ihrer PIN oder einer Variation davon.

Wenn sie gut sind, wird das Passwort verschlüsselt gespeichert. Wenn sie nicht so gut sind, könnte sie tatsächlich im Klartext gespeichert werden.

Ich gebe zu, dass mir der Kompromiss hier eher gefällt. Die gesamte Passwortdatenbank ist möglicherweise einem höheren Angriffsrisiko ausgesetzt, wenn sie kompromittiert wird, aber ich würde dem entgegenwirken, dass die Sicherheit bei Banken am oberen Ende liegen sollte. Wenn ein Kompromiss der Datenbank vermutet würde, müsste ohnehin alles geändert werden, ob gehasht oder verschlüsselt. In beiden Fällen Bei dieser speziellen Methode dauert es viel länger und komplexer, bis ein Angreifer genügend nützliche Informationen erhält, um einen Angriff mit einem Keylogger auszuführen.

Etwas Tangentiales: http: //projecteuler.net/index.php?section=problems&id=79

ferland PCI-DSS v2 p47 "8.4 Rendern Sie alle Passwörter unlesbar, um die Übertragung und Speicherung auf allen Systemkomponenten mithilfe einer starken Kryptografie zu gewährleisten."
Ferland. Eine Sache, die in Bezug auf viele Consumer-Banking-Systeme zu berücksichtigen ist, ist, dass sie möglicherweise Kartendetails (Debit oder Kredit) enthalten oder diese für Zahlungen verwenden (z. B. Kreditkarten-Websites). Als solche (IMO) würden sie in den Geltungsbereich von PCI fallen, sodass DSS gelten würde
Ich sollte umformulieren: PCI-DSS gilt normalerweise nicht für Ihre Bank. Es hat keinen Einfluss auf Ihr Giro- oder Sparkonto. Dies gilt nicht für Ihren Online-Zugriff auf Ihr Konto. Obwohl Ihre PIN damit verknüpft ist, bezieht sich dieses System nicht auf eine Kreditkartentransaktion.
Selbst wenn die Sicherheit bei Banken höher ist, handelt es sich um viel größere Ziele, sodass Sie von außen oder von innen einen Kompromiss erwarten können. Wenn Sie eine verschlüsselte Datenbank mit Kennwörtern kompromittieren, in der die App sie entschlüsseln muss, erhalten Sie in der Regel auch den Verschlüsselungsschlüssel, sodass die häufig wiederverwendbaren Kennwörter verloren gehen und Ihre Kunden noch mehr davon haben Risiko. Es ist also schlecht, etwas anderes als einen guten Hash (oder einen HSM, wie Rory bemerkt) für Passwörter zu tun. Mit einem starken Passwort und gutem Hashing sind Benutzer selbst bei einem DB-Kompromiss keinem großen Passwortrisiko ausgesetzt.
Umgekehrt geht die am weitesten verbreitete Bedrohung, der Banken am meisten ausgesetzt sind, von kompromittierten Kunden oder Phishing aus. Ein großer Kompromiss bei einer Bank kann ein großes Ereignis sein, aber viele kleine Ereignisse von Bankkunden können zu höheren Kosten führen.
@Jeff, @Rory, @Rakkhi - Das symmetrische Verschlüsseln von Passwörtern * ist * mit PCI-DSS kompatibel *. Nicht unbedingt die besten Ideen, aber es ist konform.
Der Kompromiss ist Stier. Klartext bedeutet, dass jeder, der sich in der Bank befindet, das Potenzial hat, dieses Passwort zu sehen, was einfach nur schlecht ist.
D.W.
2011-06-27 22:43:59 UTC
view on stackexchange narkive permalink

NatWests Schema scheint mir von zweifelhaftem Wert zu sein. In NatWests Schema kann ein Phishing-Angriff wahrscheinlich Ihre gesamte PIN und Ihr gesamtes oder den größten Teil Ihres Passworts stehlen. So würde der Phishing-Angriff funktionieren.

  1. Auf der Phishing-Site wird ein gefälschter Anmeldebildschirm angezeigt, in dem 3 Ziffern der PIN und 3 Zeichen des Kennworts abgefragt werden.

  2. Der Benutzer gibt seine Antwort ein.

  3. Die Phishing-Site zeigt jetzt eine Antwort an, die angibt, dass der Eintrag falsch ist, und fordert den Benutzer auf erneut.

  4. Viele Benutzer würden wahrscheinlich annehmen, dass sie etwas falsch eingegeben haben, und es erneut versuchen.

    5. ol>

    Wenn der Phisher aktiviert ist clever, die zweite Eingabeaufforderung von der Phishing-Site fragt nach einem anderen Satz von Ziffern und Zeichen. Wenn der Benutzer es ein zweites Mal versucht, kann die Phishing-Site alle 4 Ziffern der PIN und 6 Zeichen des Benutzerpassworts lernen. (Beachten Sie, dass bei NatWest Benutzer ein Kennwort mit 6-8 Zeichen auswählen müssen, sodass 6 oder fast alle Zeichen des Kennworts garantiert vollständig sind.) Zu diesem Zeitpunkt ist das Spiel beendet.

    Folglich ist mir nicht klar, dass NatWests Schema Ihnen etwas kauft.

NatWest fragt nicht nach Ihrer Geldautomaten-PIN, sondern ist eine separate Online-Banking-PIN.
Danke für die Korrektur, @Polynomial! Das wusste ich nicht. Ich habe meine Antwort entsprechend überarbeitet.
Sie haben sich jetzt tatsächlich von dieser "Online-Pin" -Idee entfernt und verwenden spezielle Kartenleser, die einen Hash bestimmter Informationen auf der Karte erzeugen und diese mit asymmetrischer Kryptographie verschlüsseln. Sie geben weiterhin Ihre Kontoanmeldedaten an, aber die Karte erweitert die Authentifizierung auf "etwas, das Sie kennen und etwas, das Sie haben". Ich bin mir ziemlich sicher, dass sie immer noch die Sache "Geben Sie drei Zeichen Ihres Geheimcodes ein" machen.
For Natwest in particular at least, a vigilant user would not be fooled by this. If you enter your details incorrectly, Natwest always ask for the exact same details again - they don't ask for different ones until your next log in. (Which also mitigates threats like keyloggers and shoulder surfing)
AilibkmsorCMT the overwhelming majority of users don't behave that way. I've done user studies to test this sort of thing, and users don't act or think like that. Generally, they don't notice these details; they just enter in their credentials. And if they do happen to notice something unusual, they don't get suspicious or assume they're under attack; instead, they usually just chalk it up to the Internet being flaky. It's really remarkable. For better or worse, your assumptions about how a "vigilant user" will behave are pretty much a pipe dream.
I didn't mean to imply that most or even many users would notice, just that if you are vigilant, this attack has been accounted for in their protocol. I agree that a "vigilant user" is like a unicorn - I've never seen either in the wild!
Mein NatWest-Passwort ist mehr als 8 Zeichen lang und war es zum Zeitpunkt der Antwort.
@JoshGallagher Mine auch, die Beschränkung auf 8 Zeichen ist einfach nicht wahr und seit mindestens 7 Jahren nicht mehr.
Oh, ich kann sehen, was passiert ist. Sie sprechen über die Kreditkartendienste, die ich nie genutzt habe, da Sie auch über die aktuelle Kontoverwaltungsseite auf Kreditkartenvorgänge zugreifen können. (Was nicht die lächerliche Beschränkung auf 8 Zeichen auferlegt.)
Piskvor left the building
2011-10-11 18:06:52 UTC
view on stackexchange narkive permalink

In einer ähnlichen Frage wurde ein Kommentar von @captaincomic mit diesem Artikel verknüpft: Teilkennwörter - Wie? (Von Archive.org) Hier erfahren Sie, wie Sie diese Funktionalität zulassen, ohne das Kennwort in einer wiederherstellbaren Form zu speichern oder jedes Zeichen separat zu hashen - unter Verwendung des geheimen Shamir-Freigabeschemas.

Der Link zu "Teilpasswörter - wie?"Artikel ist jetzt kaputt und zeigt "404 - Nicht gefunden".Ich habe den Link durch einen Link zu einer archivierten Kopie auf Archive.org ersetzt.
sampablokuper
2015-05-10 01:54:33 UTC
view on stackexchange narkive permalink

Es ist nur tangential verwandt, aber David Aspinall (Universität von Edinburgh) und Mike Just (Glasgow Caledonian University) haben 2013 einen Artikel über Teilkennwörter veröffentlicht: "Gib mir die Buchstaben 2, 3 und 6!": Teilkennwort Implementierungen &-Angriffe.

In ihrem Artikel werden Online-Angriffe behandelt, für die der Backend-Speichermechanismus irrelevant ist, aber es gibt eine vorübergehende Bemerkung, die für Ihre Frage von Bedeutung ist:

Um das Teilprotokoll zu unterstützen, muss die Implementierung entweder Klartext für das Kennwort speichern oder einen Mechanismus zur Durchführung von Einwegprüfungen für alle Kombinationen entwickeln, die möglicherweise abgefragt werden (was bei langen Kennwörtern eine große Zahl sein kann). . Wir untersuchen diesen Angriffsmodus hier nicht.

Lesen Sie den Artikel.Es hat überhaupt nichts mit dieser Frage zu tun.Es untersucht z.B.die Auswirkung der Anforderung von zu wenig Zeichen aus dem ursprünglichen Kennwort auf die Durchführbarkeit von Wiederholungsangriffen und so weiter.Wie Sie selbst bemerkt haben, wird den verwendbaren kryptografischen Systemen praktisch keine Aufmerksamkeit geschenkt.
@vucalur,, ob etwas tangential verwandt ist oder stattdessen nicht, ist Ansichtssache.Wir müssen uns darauf einigen, in diesem Fall nicht zuzustimmen.Aber die vorübergehende Bemerkung ist deutsch, nicht wahr?
Rakkhi
2011-06-27 16:24:35 UTC
view on stackexchange narkive permalink

Nein, was sie tun, ist, jedes Zeichen zu haschen und dieses zu speichern oder das Passwort in einem hoffentlich sicheren Gerät, z. HSM.

Es ist kein schlechter Ansatz. Die Bank fordert den Benutzer auf, eine Anzahl von Zeichen einzugeben (z. B. ist HSBC 3 von zufälligen Positionen). Dies bedeutet, dass ein Trojaner, ein Key Logger oder eine Phishing-Site, die diese 3 Zeichen erfasst haben, nicht über das vollständige Kennwort verfügen.

Außerdem kann die Bank das Teilkennwort zur Authentifizierung von Benutzern über das Telefon usw. ohne verwenden Verlassen Sie sich auf geheime Fragen oder ein anderes Passwort, ohne dass die Callcenter-Person das vollständige Passwort kennt.

Einige Probleme, weshalb es wahrscheinlich nicht häufiger verwendet wird:

  • Das wichtigste ist, dass Sie das Passwort nicht im Klartext speichern möchten (tatsächlich verbieten Vorschriften wie PCI-DSS es). Der Ansatz besteht also darin, einen Einweg-Hash des Passworts zu erstellen und diesen zu speichern. Wenn der Benutzer das Kennwort eingibt, wird dieses gehasht und mit dem gespeicherten Hash verglichen, wenn sie übereinstimmen, wird der Benutzer authentifiziert. Bei einem Teilkennwort müssen Sie entweder das Kennwort mit reversibler Verschlüsselung speichern, was nicht die beste Vorgehensweise ist, oder eine große Anzahl von Hashes speichern, z. Für HSBC mit einem Geburtstag und jedem Zeichen des Passworts ist ein separater Hash erforderlich. Sie müssen auch eine maximale Kennwortlänge festlegen, damit Sie die Felder in der Datenbank zuweisen können, um alle Hashes zu speichern (obwohl es jetzt wahrscheinlich intelligentere Datenbank- und Anwendungstechnologien gibt, die dies umgehen würden)

  • Es ermutigt Benutzer, schwache Passwörter auszuwählen, z Wenn ich ein komplexes Passwort mit 8 Zeichen habe: tpEz% e2S. Der Versuch, sich daran zu erinnern, was das 2., 4. und 5. Zeichen davon ist, ist schwierig, was Benutzer dazu ermutigt, ein einfaches Wörterbuchwort auszuwählen.

  • Auch wenn es keinen Kontosperrungstyp gibt, wird es verwendet Es ist exponentiell einfacher, 3 Zeichen als 8 Zeichen zu erraten oder zu erzwingen.

  • Das Vertrauen, dass das vollständige Passwort nicht bekannt ist, könnte falsch platziert werden, z. Wenn das Passwort Fulham ist und Sie F, l, h kennen, können Sie möglicherweise das vollständige Passwort erraten.

  • Eine Phishing-Site, die einfach nach dem 1. gefragt hat. 3., 5. dann sagte das Passwort falsch und geändert, um nach 2., 4., 6. zu fragen, könnte auch das vollständige Passwort erhalten, da der Benutzer es wahrscheinlich eingeben würde, bevor er zweimal überlegte

  • von einem Benutzer Aus praktischen Gründen bedeutet dies, dass sie die Browser nicht verwenden können, um sich ein Passwort oder einen Passwort-Manager wie Lastpass oder 1Password zu merken.

Die meisten Banken verlassen sich nicht mehr auf einen Benutzernamen und ein Passwort, z HSBC bietet ein RSA-Token für Geschäftskunden an. Barclays verfügt über einen EMV-Smartcard-Leser. Fast alle verwenden Erkennungstechnologien wie die adaptive RSA-Authentifizierung, um eine Basis für Browser, Standort, Nutzungsprofil, Geschwindigkeit usw. für die passive Authentifizierung und die Erkennung nicht autorisierter Verwendung zu erstellen.

Ist das Hashing jedes Zeichens sicherer als Klartext? Ich meine, es gibt nur eine Handvoll möglicher Charaktere, die mit der Hash-Funktion getestet werden können, und Sie kennen den Charakter!? Selbst wenn sie Salze verwenden, könnten / werden einige Angreifer, wenn sie Zugriff auf die Website haben, auch Zugriff auf das Salz haben!?
@binfalse nein, ist es nicht, unabhängig davon, ob Sie eine Salt- oder eine langsame Hash-Funktion oder eine Kombination verwenden, denn wenn Sie wissen, dass Sie nur ein Zeichen umkehren müssen, ist Brute Force trivial. Ich hoffe aufrichtig, dass meine Bank dies nicht tut.
Normalerweise ist dieses Bit mit einer gehashten 4-stelligen PIN beispielsweise nur eine Information. Die anderen von meiner Bank sind Benutzername, Passwort und Smartcard-Leser (letzterer nur zum Erstellen oder Autorisieren von Zahlungen), was eine ausreichende Sicherheit für den Zweck bietet.
@ninefingers @binfalse Ich sehe nicht, wie sie es sonst tun würden. Ein vollständiger Satz von 72 Zeichen mit 1 Million Iterationen von bcrypt oder äquivalent würde immer noch einen gewissen Schutz bieten, wenn das Passwort für einen Offline-Angriff gestohlen würde. Sie würden auch das andere Geheimnis, z. dob aber das konnte leicht gewonnen werden.
Ich muss sagen, ich bezweifle, dass sie es mit Hashing machen. Denken Sie daran, dass sie den Vorgang jedes Mal ausführen müssen, wenn sich ein Benutzer anmeldet. Wenn Sie ihn also mit bcrypt oder ähnlichem ausdehnen, um das Brute-Forcing zu verringern, hat dies einen sehr schlechten Einfluss auf die Leistung der Anwendung.
@rory-mccune ja reversible Verschlüsselung ist der andere Weg, wie ich bereits erwähnte, und ein HSM ist ein guter Ort, um das Klartext-Passwort zu speichern. 3 Privatkundenbanken, und ich habe es nicht so gesehen (2c). Die Leistung beim Anmelden war noch nie ein Problem
@rakhi das ist v. Interessant, also haben / haben sie einzelne Charaktere gehasht und sie so gespeichert ..? Und machen sie eine große Anzahl von Krypta-Runden, um das Brute-Force-Risiko zu verringern? andere während ein technisch konformes Sol. Es wäre keine großartige Minderung des Brute-Force-Risikos ...
@rory-mccune Ja, vor meiner Zeit, als das Design ausgewählt wurde, glaube ich nicht, dass es bcrypt war, höchstwahrscheinlich SHA oder MD5, aber ja, Compliance ist das Hauptziel. Trotzdem, wenn jemand eine größere Probleme mit der Passwortdatenbank hat, als sich um Hash zu sorgen. Jetzt mit Lulzsec usw. hoffe, dass jemand überlegt, aber bezweifle es. Das Ändern von Altsystemen ist schwierig (Web-Frontend, Auth-Datenbank im Mainframe)
@rakhi, Ja, ich weiß, was du meinst. Ich habe in einigen Banken gearbeitet und die Freuden älterer Systeme erlebt :)
@Rakkhi, Woher weißt du, dass sie jeden Charakter einzeln hashen? Sie geben kein Zitat an. Ich verstehe nicht, woher du das wissen würdest. Wenn Sie hypothetisieren / spekulieren, sollten Sie dies sagen. (Und ich finde es keine sehr überzeugende Spekulation. Wenn sie das tun, ist es albern.) Jeder Charakter einzeln zu hacken hat keine Sicherheitsvorteile; es ist gleichbedeutend mit nicht Hashing - es ist Sicherheitstheater.
@Rakkhi, Ich stimme Ihrer Aussage nicht zu, dass "es kein schlechter Ansatz ist". Wenn Sie einen Trojaner auf Ihrem Computer haben und sich mehrmals anmelden, hat der Trojaner wahrscheinlich Ihr gesamtes Passwort (oder genug, um den Rest zu erraten). Wahrscheinlich ist der einzig mögliche Vorteil, dass Ihre Sicherheit nicht vollständig gefährdet wird, wenn Sie sich einmal von einem öffentlichen Computer aus anmelden. Ein böswilliger öffentlicher Computer kann Sie jedoch leicht dazu auffordern, sich mehrmals anzumelden (was Sie glauben lässt, dass Sie bei Ihrem ersten Versuch Ihr Passwort falsch eingegeben haben müssen), was bedeutet, dass selbst dieses Ziel wahrscheinlich nicht erreicht wird.
@d-w nur persönliche Erfahrung, kann kein Zitat liefern. Glauben Sie mir nicht, dass das in Ordnung ist, keine Haut von meiner Nase, ich tue nur mein Bestes, um die Frage zu beantworten. Ich bin mir über Trojaner einig, deshalb habe ich gesagt, dass es ein falsches Gefühl des Vertrauens vermitteln kann.
Ihre Annahme ist am häufigsten falsch; Obwohl ich nicht speziell für HSBC oder NatWest sprechen kann, speichern viele Bigname-Banken und -Systeme, die dieses Schema implementiert haben, die Passwörter nicht gehasht, sondern bestenfalls symmetrisch verschlüsselt und nicht gehasht.
Sie müssen am Anfang Ihrer Antwort 3 Wörter hinzufügen: "Ich denke das ..."
* "Sie müssen auch eine maximale Kennwortlänge festlegen, damit Sie die Felder in der Datenbank zum Speichern aller Hashes zuweisen können." * Nicht, wenn Sie über ausreichende Kenntnisse zum Datenbankdesign verfügen.Stattdessen ist es wahrscheinlicher, dass Sie eine Tabelle wie [Kunde, Position, Hash] haben, in der für jeden Kunden eine beliebige Anzahl von Position / Hash-Paaren gespeichert ist.* Et voilá *, keine Notwendigkeit, Längenbeschränkungen aufzuerlegen, * und * es hält den Haupttisch von The Daily WTF fern.Mit ein wenig cleverem Design können Sie auch eine zufällige Länge> = die Passwortlänge des Kunden festlegen, sodass Sie die Länge auch nicht offenlegen.


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