AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Algorithmen, Datenstrukturen und Klassendesign Grundsatzüberlegungen zum Thema Speichern von Passwörtern

Grundsatzüberlegungen zum Thema Speichern von Passwörtern

Ein Thema von Codehunter · begonnen am 10. Apr 2013 · letzter Beitrag vom 16. Apr 2013
Antwort Antwort
Seite 2 von 4     12 34   
Delphi-Laie

Registriert seit: 25. Nov 2005
1.470 Beiträge
 
Delphi 10.1 Berlin Starter
 
#11

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 11. Apr 2013, 12:20
Was mich jetzt prinzipiell wundert: Keines der mir bekannten FTP-Programme fragt mich jemals nach einer Art Masterpasswort. Daraus folgt doch eigentlich, dass die Methode zur Verschlüsselung der Passwörter mehr oder weniger hartcodiert sein muss und die Sicherheit dabei vorrangig auf "Security by Obscurity" basiert. Oder mache ich einen Denkfehler?
Ich verstehe das so, daß - abhängig von einem ggf. einzugebenden Masterpaßwort - die Paßwörter unterschiedlich codiert sein können.

Diese "hardcodiert" ist dann m.E. aber dennoch vorhanden, sprich: Der Verschlüsselungsalgorithmus. Nur gibt es eben (flexiblere) Algorithmen, die - abhängig von weiteren Eingaben, hier eben dem Masterpaßwort - zu anderen Verarbeitungen und damit Ausgaben führen können.

Stimmen Paßwort und Masterpaßwort überein, so ist auch das verschlüsselte Paßwort dasselbe (Verschlüsselungsalgorithmen müssen nach meinem Verständnis determiniert arbeiten, sonst wäre Entschlüsselung doch gar nicht möglich). Ist also nur eine Verlagerung des Problems auf eine Metaebene.
  Mit Zitat antworten Zitat
Benutzerbild von jfheins
jfheins

Registriert seit: 10. Jun 2004
Ort: Garching (TUM)
4.578 Beiträge
 
#12

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 11. Apr 2013, 12:58
Stimmen Paßwort und Masterpaßwort überein, so ist auch das verschlüsselte Paßwort dasselbe (Verschlüsselungsalgorithmen müssen nach meinem Verständnis determiniert arbeiten, sonst wäre Entschlüsselung doch gar nicht möglich). Ist also nur eine Verlagerung des Problems auf eine Metaebene.
Nö. Wenn man das Passwort im Kalrtext, oder base64enkodiert oder ohne Masterpasswort verschlüsselt, dann befinden sich alle Informationen die man zum Entschlüsseln benötigt auf der Festplatte.
Mit einem Masterpasswort hingegen wäre der Benutzer gezwungen dieses jedes Mal einzugeben. Die Information zum Entschlüsseln befindet sich also nicht auf der HDD. (Sondern ggf. auf dem Post-it am Monitor)

"Klaut" jetzt also ein Trojaner die config-datei kann der Angreifer damit erstmal nichts anfangen da er das Passwort nicht kennt. ==> Zusätzliche Sicherheit
  Mit Zitat antworten Zitat
Benutzerbild von Aphton
Aphton

Registriert seit: 31. Mai 2009
1.198 Beiträge
 
Turbo Delphi für Win32
 
#13

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 11. Apr 2013, 14:06
Edit: Zu undurchdacht
das Erkennen beginnt, wenn der Erkennende vom zu Erkennenden Abstand nimmt
MfG

Geändert von Aphton (11. Apr 2013 um 15:21 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von sx2008
sx2008

Registriert seit: 16. Feb 2008
Ort: Baden-Württemberg
2.332 Beiträge
 
Delphi 2007 Professional
 
#14

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 11. Apr 2013, 14:37
Mein Vorschlag sieht so aus:

1.) man legt ein Masterpasswort fest; dies kann entweder hartcodiert in der Anwendung sein oder von Aussen kommen
2.) man berechnet masterkey := MD5(masterpasswort)
3.) man erzeugt für jeden Vorgang einen "randomkeystring" (3 - 10 Zeichen)
key := MD5(masterkey + randomkeystring);
4.) dieser "key" hat eine Länge von 16 Bytes.
Damit wir auch Passwörter mit mehr als 16 Zeichen verschlüsseln können, wird der key verlängert:
key := key + MD5(key); Damit hat der key eine Länge von 32 Bytes.
Diese Art der Verlängerung kann wiederholt werden um so einen key mit 48 oder 64 Bytes zu erhalten.
5.) das zu verschlüsselnde Passwort wird auf mindestens 32 Zeichen verländert
Delphi-Quellcode:
if Length(password) < 32 then
   paddedPW := copy(password+#0+Randomstring2, 1,32)
else
   paddedPW := password;

6.) das verlängerte Passwort wird nun einfach mit dem Key XOR verknüpft
cryptedPW := XORstring(key, paddedPW);
7.) gespeichert wird so
Code:
$randomkeystring$cryptedPW$
Die Dollarzeichen dienen dazu, die beiden Teilstücke später wieder zu trennen.
Das cryptedPW muss hexadezimal codiert werden weil es ja alle Zeichen zwischen #0 bis #255 enthalten kann.

Vorteile:
* ohne Kenntniss des masterpassworts oder masterkeys ist die Verschlüsselung kaum zu knacken (zumindest nicht wirtschaftlich lohnend)
* selbst wenn alle FTP-Passwörter = "123456" sind entsteht durch den randomkeystring jedesmal eine neue Verschlüsselung
* da das zu verschlüsselnde PW auf 32 Zeichen verlängert wurde, kann der Angreifer nicht erkennen wie lange das ursprüngliche PW ist

Geändert von sx2008 (11. Apr 2013 um 14:51 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.230 Beiträge
 
Delphi 10.4 Sydney
 
#15

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 12. Apr 2013, 08:53
Wenn das Masterpasswort schon hartcodiert wäre, dann müßte wenigstens ein "komplizierter" Algorithmus dafür sorgen, dass die als Ausgangswerte verwendeten Daten nochmal ordentlich "verwurschtelt" werden bevor der daraus entstehende Key als Passwort für den eigentlichen "Passwort-Safe" verwendet wird.

Die Idee, die zu verschlüsselnden Daten künstlich zu verlängern kam mir auch schon. Mit langen Keys verschlüsselt wird das eine harte Nuss, selbst für hardwarebeschleunigte Passwortknacker. Allerdings wäre ich nicht auf die Idee gekommen, XOR zum Verschlüsseln zu verwenden. Eher was schickes aus dem DEC. Vielleicht sogar 16 verschiedene Verschlüsselungsalgorithmen und das erste Byte des MD5-Hashes vom eigentlichen Masterpasswort entscheidet, welche davon verwendet wird. Die nächsten vier Bytes entscheiden, wie viele Runden verschlüsselt wird. Hach ja, da kann man sich mal richtig austoben ^^

Aber dieses ganze Prinzip kann man nur dann als halbwegs sicher ansehen, solange der Rechner auf dem die Anwendung läuft nicht kompromittiert ist. Andernfalls gibt es immer Möglichkeiten, die entschlüsselnde Anwendung zu belauschen. Dann bräuchte man die Daten nicht mal aufwendig knacken, man holt sich alles aus dem Speicher der laufenden Anwendung.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
r2c2

Registriert seit: 9. Mai 2005
Ort: Nordbaden
925 Beiträge
 
#16

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 12. Apr 2013, 09:10
Sry, aber so wird das nichts. Entschuldigung, wenn ich das so direkt sage, aber das hier ist blindes Security-Rumgerate und und das führt zu allem nur nicht zu einem sicheren System.

- Mein Post von oben, war durchaus ernst gemeint und nicht nur "guckt mal her, was ich alles im Studium gelernt habe". Wenn man nicht weiß, vor was man sich schützen will, braucht man gar nicht erst anzufangen. Also @Codehunter: Wenn du wirklich an einem sicheren System interessiert bist, poste hier eine Liste der Angreifer, gegen du dich schützen willst. Am besten gleich noch eine der Angriffsszenarien, aber die können wir auch gemeinsam ableiten.
- @sx2008: Sry, aber deine Verschüsselung ist IMHO *nicht* sicher. Ich bin jetzt kein ausgemachter Security-Experte, und kann deshalb deinen Algo nicht einfach so im Handumdrehen auseinander nehmen, aber eine handgestrickte Stromchiffre zu bauen (und auch noch auf Basis vom md5) und einfach zu behaupten, sie sei sicher, ist gewagt. Krypto ist kompliziert. Verdammt kompliziert. Und selbst echt Experten haben damit mitunter Probleme. Ich rate dringend davon ab, Alogs selbst zu erfinden. Nur mal so aus dem Bauch heraus, was ich, der ich mich auch nach drei Security-Vorlesungen noch als Krypto-Laie bezeichnen muss, so vermute:
-- md5 ist gebrochen. Damit kann man vielleicht was lustiges anstellen.
-- wenn das Passwort hartkodiert ist, braucht man sich eh keine mühe machen. Da ist Rot13 gut genug. Aber das mit den Angriffsszenarien hatten wir ja schon.
-- ein Problem sind die Zufallswerte, die mitunter nicht leicht sind, kryptographisch zufällig hinzukriegen
-- die Schlüssel-Verlängerung erscheint mir angreifbar
-- über die #0 im paddedPW kann man ggf. leicht nen Gültigkeitstest bauen. Das macht BruteForce *deutlich* schneller
-- ggf. kann man darüber auch was basteln, weil man ja einen teil des Plaintexts kennt
-- ...

Also bitte: Macht keine Krypto selbst. Benutzt einen bekanntermaßen für sicher befundenen Algo wie AES, aus einer Implementierung von jemandem, dem ihr sehr gute Kryptokenntnisse zutraut (negaH...). Das sichere Verwenden einer Library wie des DEC ist definitiv kompliziert genug und bietet ausreichend Fehlerpotenzial.

Ich will damit niemandes Bemühungen kleinreden: Sich über sowas Gedanken zu machen und ein bisschen mit Krypto rumzuspielen ist gut. Man lernt dadurch viel. Das ist aber nur was zum Spielen, nichts, was man in echten Projekten einsetzen sollte...

Zitat:
Wenn das Masterpasswort schon hartcodiert wäre, dann müßte wenigstens ein "komplizierter" Algorithmus dafür sorgen, dass die als Ausgangswerte verwendeten Daten nochmal ordentlich "verwurschtelt" werden bevor der daraus entstehende Key als Passwort für den eigentlichen "Passwort-Safe" verwendet wird.
Nein. Wenn das Passwort hartcodiert ist, nützt der beste Algo nichts. Das ist Augenwischerei.

Zitat:
Die Idee, die zu verschlüsselnden Daten künstlich zu verlängern kam mir auch schon. Mit langen Keys verschlüsselt wird das eine harte Nuss, selbst für hardwarebeschleunigte Passwortknacker. Allerdings wäre ich nicht auf die Idee gekommen, XOR zum Verschlüsseln zu verwenden.
xor an sich ist nicht schlecht. Das ist das Prinzip von Stromchiffren. Wie RC4 z.B. das Problem dabei nicht das xor, sondern der Keystream..

Zitat:
Eher was schickes aus dem DEC.
Ja, siehe oben.

Zitat:
Vielleicht sogar 16 verschiedene Verschlüsselungsalgorithmen und das erste Byte des MD5-Hashes vom eigentlichen Masterpasswort entscheidet, welche davon verwendet wird.
Das hat zur Folge, dass die Sicherheit auf das Level des unsichersten dieser 16 Algos sinkt.

Zitat:
Die nächsten vier Bytes entscheiden, wie viele Runden verschlüsselt wird.
Das hat zur Folge, dass das Sicherheitsniveau vom zufall abhängig ist bzw. genau genommen auch wieder so ist, die bei einer Runde. Runden haben nicht den Zweck Veränderung zu schaffen. Sie sollen den Algo langsam machen. Deshalb muss die Anzahl der Runden -- so man so etwas einsetzt -- groß sein und fest.

Zitat:
Aber dieses ganze Prinzip kann man nur dann als halbwegs sicher ansehen, solange der Rechner auf dem die Anwendung läuft nicht kompromittiert ist. Andernfalls gibt es immer Möglichkeiten, die entschlüsselnde Anwendung zu belauschen. Dann bräuchte man die Daten nicht mal aufwendig knacken, man holt sich alles aus dem Speicher der laufenden Anwendung.
Deshalb solltest du dir Gedanken über Angriffsszenarien machen.

mfg

Christian
Kaum macht man's richtig, schon klappts!
  Mit Zitat antworten Zitat
Benutzerbild von DeddyH
DeddyH

Registriert seit: 17. Sep 2006
Ort: Barchfeld
27.265 Beiträge
 
Delphi 10.4 Sydney
 
#17

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 12. Apr 2013, 09:38
[OT] Ihr könnt ja auch mal den Kryptochef fragen [/OT]
Detlef
"Ich habe Angst vor dem Tag, an dem die Technologie unsere menschlichen Interaktionen übertrumpft. Die Welt wird eine Generation von Idioten bekommen." (Albert Einstein)
Dieser Tag ist längst gekommen
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#18

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 12. Apr 2013, 10:21
Es ist doch wie im Leben - einfach mal nachdenken:

Zitat:
Die sicherste, dickste, mit 2 Trilliarden Sicherheitskomponenten geschützte Haustür nützt rein gar nichts, wenn der Schlüssel unter der Fussmatte liegt.
Ist das Passwort also auf dem Rechner, dann liegt der damit "unter der Fussmatte".

So einfach ist das ... und das "Andere" sich das Leben einfach machen, heißt nicht, dass die das gut machen.

@r2c2
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)
  Mit Zitat antworten Zitat
Benutzerbild von Codehunter
Codehunter

Registriert seit: 3. Jun 2003
Ort: Thüringen
2.230 Beiträge
 
Delphi 10.4 Sydney
 
#19

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 12. Apr 2013, 10:50
Ist das Passwort also auf dem Rechner, dann liegt der damit "unter der Fussmatte".
Womit wir wieder bei meinem Eröffnungspost wären (einfach nochmal lesen). Denn genau das brachte mich ja darauf, über die Problemstellung nachzudenken.

Frage 1:
Was ist besser: Ein userdefiniertes oder ein hartcodiertes Passwort?
Antwort: Userdefiniert.

Frage 2:
Wenn ein Programm mit hartcodiertem Passwort verlangt wird, wie sollte es am besten konstruiert sein?
Antwort: So kompliziert wie möglich.

Das userdefinierte Masterpasswort hat eben den Nachteil dass man bei jedem Programmstart danach gefragt wird. Manche Leute wollen das nicht. Das kann man als Entwickler gut oder schlecht finden, man muss damit leben. Ich denke, der beste Kompromiss wäre, userdefiniertes und hartcodiertes Passwort parallel zu implementieren und dem Anwender per Konfigurationsoption die Wahl zu lassen.

Als Entwickler hat man ja auch prinzipiell zwei Möglichkeiten: Entweder man implementiert was richtig gutes, was natürlich Zeit und Geld kostet sowie permanent auf dem aktuellen Stand gehalten werden muss. Oder man implementiert "irgendwas", hält sich selbst für den tollsten Hecht der Welt, der Kunde (selbst Laie) sieht nur verschlüsselte Daten und nimmt das Programm so ab, und am Ende hoffen Entwickler und Kunde einfach nur dass die Sache "irgendwie" dicht hält.

Insofern gebe ich r2c2 vollkommen recht, das Thema ist eine Sache für Spezialisten zu denen ich mich nicht zähle. Darum kann ich nur bewährte Prinzipien anwenden und auf sichere Algos wie AES aus dem DEC vertrauen. Garantieren würde ICH trotzdem nicht dafür. Nach allem was ich so lese kann es sichere Kryptografie gar nicht geben. Höchstens solche, die wenn sie gut gemacht ist, den Angriff darauf in hohem Maße erschwert. In meinen Augen begibt sich derjenige, der für sichere Verschlüsselung GARANTIERT, auf sehr dünnes Eis.
Ich mache grundsätzlich keine Screenshots. Schießen auf Bildschirme gibt nämlich hässliche Pixelfehler und schadet der Gesundheit vom Kollegen gegenüber. I und E zu vertauschen hätte den selben negativen Effekt, würde aber eher dem Betriebsklima schaden
  Mit Zitat antworten Zitat
Benutzerbild von Sharky
Sharky

Registriert seit: 29. Mai 2002
Ort: Frankfurt
8.248 Beiträge
 
Delphi 2006 Professional
 
#20

AW: Grundsatzüberlegungen zum Thema Speichern von Passwörtern

  Alt 12. Apr 2013, 11:28

Frage 1:
Was ist besser: Ein userdefiniertes oder ein hartcodiertes Passwort?
Antwort: Userdefiniert.

Frage 2:
Wenn ein Programm mit hartcodiertem Passwort verlangt wird, wie sollte es am besten konstruiert sein?
Antwort: So kompliziert wie möglich.
Die Richtige Antwort lauter bei Frage 2 eigentlich. Auftrag ablehnen da absolut unsicher.
Stephan B.
"Lasst den Gänsen ihre Füßchen"
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +2. Es ist jetzt 05:44 Uhr.
Powered by vBulletin® Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf