it-swarm.com.de

Wie kann ich mein Passwort wiederverwenden und es trotzdem schützen, wenn es aus einer Hand verfügbar ist?

Ich weiß, dass alle Server sollten zumindest meine Anmeldeinformationen als hash(password + salt) + salt speichern, mit einer sicheren und bekannten hash -Funktion und einer salt einzigartig für mich, generiert aus einer sicheren und bekannten Quelle.

Das Problem ist, dass Server dies tun sollten, aber möglicherweise nicht. Als Benutzer kann ich ihnen nicht vertrauen.

Ich suche nach Möglichkeiten, wie ich mein Kennwort ändern kann, bevor ich es an den Server sende. Wenn der Server beispielsweise Klartext speichert, wird die Sicherheit meines Kennworts auf anderen Servern nicht beeinträchtigt.

Ich dachte daran, hash(password + service) an die Server zu senden, wobei der Dienst beispielsweise "Facebook" Oder "Amazon" Ist. Auf diese Weise hat jemand, der hash(password + service) von diesem Dienst im Klartext gespeichert bekommt, den Hash meines Passworts + das Salz gefunden, das für diesen Dienst eindeutig ist.

Ich sehe bereits ein Problem mit dieser Idee: Jemand könnte für jeden Dienst eine Regenbogentabelle erstellen, wodurch die Verwendung des Dienstes als Salz unbrauchbar wird.

Ich kenne die Regel erfinde keine eigene Krypto/Protokoll, deshalb möchte ich wissen, ob es ein bekanntes Protokoll für einen Client gibt, der sich selbst sichert?

22
Sinder

Sie versuchen, ein Problem zu lösen, das Sie gar nicht erst haben sollten: Kennwortwiederverwendung

Das Konzept ist einfach. Sie denken an ein "gutes" Passwort und verwenden dieses für alles. Ihr Bankkonto, Online-Shopping, Ihr E-Mail-Anbieter usw.

Das Problem ist, wenn alle von ihnen durchgesickert sind, sind alle anderen Konten möglicherweise in Gefahr. Dies ist ein völlig unnötiges Risiko!

Was ist mit meinem vorgeschlagenen Schema?

Sie selbst sagten, erfinden Sie das Rad nicht neu. Wenn Sie das tatsächlich tun würden, müssten Sie entweder eine Anwendung schreiben, die die Hashes für Sie berechnet, oder sie selbst berechnen und speichern.

Es gibt bereits Anwendungen, die das Problem der Speicherung von Anmeldeinformationen lösen, und sie machen es viel besser: Offline-Passwort-Manager

Warum sind Offline-Passwort-Manager besser?

Weil sie wirklich zufällige und eindeutige Passwörter generieren. Es besteht keine Notwendigkeit, Kryptographie in diese zu bringen. Ich muss mein Passwort für mein E-Mail-Konto nicht daran binden, dass es die Zeichenfolge "gmail.com" enthält.

Weil SN2\ZJ2Cw92DQx^{$OmqAC_P'xR|Md)[ ist definitiv ein besseres Passwort als die MD5-Summe von hunter2+gmail.com (es ist 01f9a94a0febf268495d08f5960e7f05, Falls du dich gewundert hast).

95
MechMK1

Die etablierte Lösung für dieses Problem besteht darin, unterschiedliche Kennwörter für unterschiedliche Websites zusammen mit einem Kennwortmanager zu verwenden. Auf diese Weise müssen Sie das Rad nicht neu erfinden.

Ich weiß, dass die Regel keine eigene Krypto/Protokoll erfindet. Deshalb möchte ich wissen, ob es ein bekanntes Protokoll für einen Client gibt, der sich selbst sichert.

Nicht jedes Problem muss durch eine technische, überkomplizierte Lösung gelöst werden.
Das Nicht-Wiederverwenden von Passwörtern ist eine elegante Lösung.

23
Vipul Nair

Ich habe früher eine Browser-Erweiterung verwendet, die ziemlich genau das tat, was Sie vorgeschlagen haben. (Es hat mein aktuelles Passwort + die URL der Site genommen, sie zusammen gehasht und daraus ein Passwort generiert). Es war großartig ... bis eBay mich dazu brachte, mein Passwort zu ändern, weil sie ihre Datenbank durchgesickert waren. Zu diesem Zeitpunkt musste ich mich daran erinnern, welche Websites ein Passwort und welches ein anderes verwendeten.

Das zusätzliche Problem ist, dass, wenn eine Site mein "Passwort" im Klartext gespeichert hat, ein Angreifer möglicherweise erkannt hat, wie mein Passwort generiert wurde, und es geknackt hat.

Das letzte Problem sind Websites wie Amazon.de, Amazon.co.uk und Amazon.com, die alle ein Kennwort gemeinsam nutzen müssen.

Ich habe zu einem Passwort-Manager (LastPass) gewechselt, der mit einem starken, zufällig generierten (Diceware) Passwort (und 2FA auf meinen wichtigen Konten) gesichert ist.

Ich weiß, dass die Regel kein eigenes Krypto/Protokoll erfindet. Deshalb möchte ich wissen, ob es ein bekanntes Protokoll für einen Client gibt, der sich selbst sichert.

Das Problem, das im Bereich Security Engineering auftritt, wird als "Greedy Password" Modell bezeichnet. Jede Website, die Sie besuchen, ist der Meinung, dass dies die einzige Website im gesamten Web ist, und es ist in Ordnung, Sie zu bitten, komplexe Kennwörter zu verwalten/sich daran zu erinnern. Siehe auch Peter Gutmanns Engineering Security.

Sie können tun, was @ MechMK1 vorschlägt, und den Passwort-Manager verwenden. Das Problem ist, dass es nur das Passwortproblem verschiebt und die Verwaltung ein wenig vereinfacht. Sie müssen zu einem bestimmten Zeitpunkt immer noch ein echtes Passwort verwenden. In einem Risikomanagement-Framework haben Sie das Risiko reduziert, aber nicht beseitigt.

Sie sollten für jedes nicht kritische Konto Wegwerfkennwörter verwenden. Ich persönlich verwende Strong Random Password Generator , um zufällige 32-Byte-Passwörter für jede gierige Site zu generieren. Humorvoll - auf krankhafte Weise - können einige Websites nicht mit langen oder komplexen zufälligen Passwörtern umgehen. Auf einigen Websites geben Sie ein schwächeres Kennwort an.

Sobald Sie sich bei einer Site anmelden, erhalten Sie ein Token (Cookie) für die Site, für die Sie das Passwort nicht mehr benötigen. Wenn Sie das Kennwort erneut eingeben müssen, lassen Sie es vom Browser aus dem Anmeldeinformationsspeicher eingeben.

Wenn sich das Kennwort nicht im Anmeldeinformationsspeicher befindet, führen Sie einfach den Vorgang "Kennwortwiederherstellungskennwort" durch. Die Site sendet Ihnen eine E-Mail, und Sie können den Vorgang verwenden, um ein anderes Wegwerfkennwort festzulegen. Ich benutze es die ganze Zeit für abgelaufene Cookies.

Der in der E-Mail des Wiederherstellungsprozesses gesendete Link wird als "Selbstauthentifizierende URL" bezeichnet. Ich glaube Python verwendet ein ähnliches zur Authentifizierung von Paketen. Siehe auch Peter Gutmanns Engineering Security .

Mehrere Konten sind wichtig genug, dass Sie ein echtes Passwort benötigen. Zum Beispiel Ihr Firmenkennwort und Ihr E-Mail-Kontokennwort {Gmail | Yahoo | Hotmail | Apple | Microsoft | etc}. Verwenden Sie für sie ein sicheres Passwort und notieren Sie es, damit es nicht verloren geht oder vergessen wird. Dann stecken Sie das Passwort in Ihre Brieftasche oder Geldbörse. Richten Sie noch besser 2FA für die kritischen Konten ein, damit der Angreifer sowohl Ihr Kennwort als auch Ihr OTP/Token benötigt.

Einige Dienste, wie Spotify, erwägen, alle Passwörter insgesamt zu streichen. Sie passen den "Password Recovery Process" für die Authentifizierung an. Wenn Sie sich anmelden möchten, geben Sie Ihre E-Mail-Adresse ein und Sie erhalten einen Link für ein Token. Sie benötigen kein Passwort mehr - Sie benötigen nur noch ein E-Mail-Konto.

Die größte Bedrohung ist der Netzwerkangreifer, der es nicht geschafft hat, über Ihren Monitor zu gelangen und Ihre Haftnotizen zu lesen. Wenn sie in Ihren Passwort-Manager oder Browser-Anmeldeinformationsspeicher eindringen, lassen Sie sie so viele Wegwerfpasswörter sammeln, wie sie möchten.


Ich suche, was ich mit meinem Passwort tun kann, bevor ich es an den Server sende ... Ich habe darüber nachgedacht, Hash (Passwort + Dienst) an die Server zu senden

Wenn Sie diese Art von Dingen ausführen möchten (Risikoanalyse, Angriffsmodellierung usw.), sollten Sie Peter Gutmanns Engineering Security. Seine Doktorarbeit studierte Sicherheit und Benutzerverhalten. Sein Buch ist eine Behandlung für den Aufbau sicherer und sicherer Systeme.

2
user29925

Ich werde nur die Kryptoaspekte Ihrer Argumentation beantworten. Weitere Informationen zu den Sicherheitsauswirkungen eines zustandslosen Hauptkennworts finden Sie in anderen Antworten.

Konzeptionell ist Ihre Idee gut. Dies wäre im Random Oracle-Modell korrekt, bei dem Hash-Funktionen unabhängige Ausgaben für teilweise identische Eingaben haben. In der realen Welt haben unsere Hash-Funktionen jedoch Einschränkungen und können für Erweiterungsangriffe anfällig sein.

Hier besteht das Risiko, dass ein Gegner die Ausgabe H(key + service1) für einen kompromittierten Dienst stiehlt und einen effizienteren Weg findet, um H(key + service2) zu generieren, für den keine vollständige Wiederherstellung erforderlich ist password.

Aus diesem Grund würden wir hash(key + service/salt) nicht als Grundelement verwenden. Stattdessen würden wir eine Nachrichtenauthentifizierungscode Funktion verwenden, MAC(key, service). MAC-Funktionen wurden speziell entwickelt, um dieses Problem zu vermeiden.

2
b0fh

https://getvau.lt/ scheint Ihre Frage genau zu beantworten. Ihr Passwort wird mit dem Namen der Site versehen, sodass Sie für jede Site ein eindeutiges Passwort erhalten und sich nur eines merken können.

Persönlich würde ich immer noch einen Passwort-Manager empfehlen, aber wenn Sie darauf bestehen ...

0
Jamie Kitson

Wie andere gesagt haben, sollten Sie Ihr Passwort nicht wiederverwenden, aber ich möchte auch hinzufügen, dass Sie Ihre ID nicht wiederverwenden sollten. Wenn die Erstellung unter Ihrer Kontrolle steht, verwenden Sie für jede etwas Zufälliges: -

Server 1, ID: bluecanary81 Passwort: isoudi £ & 8r902) 38rficsu78
Server 2, ID: tuliptop19 Passwort: uiouew893 £ * (2dferff $ () _ 5

usw. usw.

Wenn das System auf einer E-Mail-Adresse besteht, holen Sie sich Ihre eigene Domain und verwenden Sie [email protected] für Server 1, tulipt[email protected] für Server 2 usw.

Selbst wenn jemand Ihre Anmeldeinformationen erhält, ist auf diesem System kein anderes System verfügbar.

0
Alan Dev

Die Frage, die Sie sich stellen müssen, ist, was Sie erreichen wollen.

Sie sagten, Sie möchten ein eindeutiges Passwort haben, mit dem Sie hashen:

Hash (Passwort + Service) Der resultierende Hash wird je nach verwendetem Algorithmus (Hinweis: Erstellen Sie keinen eigenen Algorithmus) wahrscheinlich 32 Zeichen lang sein.

Das erste Problem ist: Was ist, wenn Sie auf der Website kein 32 Zeichen langes Passwort verwenden können?

Zweites Problem: Planen Sie, sich dieses Passwort für jede Website zu merken? Wenn Sie sie irgendwo speichern möchten, ist die Verwendung eines Passwort-Managers zum Erstellen eines 10 Zeichen langen, eindeutigen, zufälligen Passworts, das Sie für keine andere Website verwenden, sowohl einfacher als auch sicherer

Wenn Sie sich diese 32 Zeichen langen Kennwörter merken möchten, ist es immer noch einfacher, sich ein eindeutiges Kennwort mit 10 Zeichen zu merken.

Um auf meine ursprüngliche Frage zurückzukommen: Was versuchen Sie zu erreichen?

Das Versalzen und Hashing des Kennworts in der Datenbank ist eine Sicherheitsstufe, damit:

  • wenn die Datenbank kompromittiert ist, hat der Hacker Probleme, Ihr ursprüngliches Passwort zu finden, und kann daher Ihre anderen Konten bei anderen Diensten nicht kompromittieren, wenn Sie auf jeder Website dasselbe Passwort (oder kleine Abweichungen) verwendet haben.
  • wenn Sie jedoch auf jeder Website/jedem Dienst ein anderes Kennwort verwenden, kann jemand, der Ihr Kennwort für eine Website erhält, nicht viel damit tun, sodass Sie sich nicht darum kümmern sollten

Wenn der Angreifer den von Ihnen verwendeten Dienst stillschweigend kompromittiert hat und über einen vollständigen Zugriff verfügt, kann er einfach Ihre Sitzungs-ID stehlen, um sich als Sie auszugeben. Er kann das Anwendungsverhalten so ändern, dass Ihr Klartext-Kennwort vor dem Hashing an ihn gesendet wird. Er kann Ihr Hash-Kennwort ändern in der Datenbank zu seinem eigenen Hash-Passwort, melden Sie sich mit seinem Passwort an und ändern Sie dann das Passwort in der DB wieder in Ihr Hash-Passwort ... er besitzt im Grunde das System und SIE können nichts dagegen tun.

Durch Hashing und Salting des Kennworts versucht der von Ihnen verwendete Dienst/die von Ihnen verwendete Site nicht, sie zu schützen, sondern versucht, Ihre anderen Konten zu schützen, falls sie kompromittiert werden.

0
Maxime