11
AES Verschlüsselung - Sicheres Speichern des SALT Wertes
Hallo Zusammen,
ich habe mir einen TCP/Ip Server/Client programmiert. Ich verschlüssle den zu übertragenden String mit AES 265 bit.
Zur verschlüsselung/entschlüsselung wird ja ein sogennanter SALT Wert benötigt. Dieser ist bei mir im Programm gespeichert.
Doch wie wäre es am sichersten und sinnvollsten den SALT Wert zu speichern ?
Vielen Dank für eure Zeit,
Mfg
ich habe mir einen TCP/Ip Server/Client programmiert. Ich verschlüssle den zu übertragenden String mit AES 265 bit.
Zur verschlüsselung/entschlüsselung wird ja ein sogennanter SALT Wert benötigt. Dieser ist bei mir im Programm gespeichert.
Doch wie wäre es am sichersten und sinnvollsten den SALT Wert zu speichern ?
Vielen Dank für eure Zeit,
Mfg
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 357243
Url: https://administrator.de/contentid/357243
Ausgedruckt am: 24.11.2024 um 01:11 Uhr
11 Kommentare
Neuester Kommentar
100% Sicherheit wirst du nicht erreichen.
Die Frage ist eher vor wem möchtest du den "Verstecken" ?
Der Normale User wird sich da kaum die Mühe machen als Leute mit Ahnung/Wissen.
Zudem dürfte Wireshark den Code auch bekommen egal wo der gespeichert ist.
Aber welche Sprache zu verwendest ist auch so eine Sache da du das ganze auch in Batch machen kannst oder in C,VB ect wo du da noch die Daten "Verschlüsseln" kannst das die so nicht einfach einzusehen sind.
Jeder der ein Kopierschutz entwirft hat die selben Probleme das ganze Sicher zu machen und die Spielefirmen haben etliche Leute und Budget für so was und werden teilweise nach kurzer Zeit umgangen....
Die Frage ist eher vor wem möchtest du den "Verstecken" ?
Der Normale User wird sich da kaum die Mühe machen als Leute mit Ahnung/Wissen.
Zudem dürfte Wireshark den Code auch bekommen egal wo der gespeichert ist.
Aber welche Sprache zu verwendest ist auch so eine Sache da du das ganze auch in Batch machen kannst oder in C,VB ect wo du da noch die Daten "Verschlüsseln" kannst das die so nicht einfach einzusehen sind.
Jeder der ein Kopierschutz entwirft hat die selben Probleme das ganze Sicher zu machen und die Spielefirmen haben etliche Leute und Budget für so was und werden teilweise nach kurzer Zeit umgangen....
1
Hallo,
überlichweise wird das Kennwort für AES mit RSA übertragen (PKI) oder gespeichert.
Ein Salt speichert man üblichweise direkt mit dem Benutzername und dem Hash des Kennwortes.
Es verhindert "nur" die Verwendung einer Ranbow-Table um den Hash zu knacken. Ein Hacker hat üblicherweise aber Zugriff auf beides, da er das System kontrolliert. Du kannst das Hash aber auch in einer anderen Tabelle, Datenbank oder in einer Datei speichern. Hilft aber alles nichts wenn der Hacker schon "drin" ist.
Stefan
überlichweise wird das Kennwort für AES mit RSA übertragen (PKI) oder gespeichert.
Ein Salt speichert man üblichweise direkt mit dem Benutzername und dem Hash des Kennwortes.
Es verhindert "nur" die Verwendung einer Ranbow-Table um den Hash zu knacken. Ein Hacker hat üblicherweise aber Zugriff auf beides, da er das System kontrolliert. Du kannst das Hash aber auch in einer anderen Tabelle, Datenbank oder in einer Datei speichern. Hilft aber alles nichts wenn der Hacker schon "drin" ist.
Stefan
1
Okei dann ist das wohl ein größeres Thema. Mein Programm ist eher nur für Private Zwecke gedacht und im Lokalen Netzwerk.
Programmieren tuhe ich das ganze in Viusal Basic. Habe den Salt Wert in den Settings gespeichert. Habe mich dann eben gefragt wie man das eigentlich richtig macht :D
Wie würde man den zum Beispiel den Salt Wert verschlüsseln ?
Vielen Dank
Programmieren tuhe ich das ganze in Viusal Basic. Habe den Salt Wert in den Settings gespeichert. Habe mich dann eben gefragt wie man das eigentlich richtig macht :D
Wie würde man den zum Beispiel den Salt Wert verschlüsseln ?
Vielen Dank
Gar nicht
Ein Salt verwendet man eigentlich bei einer Kennwortabfrage.
Einfach den String der Eingabe oder des Kennwortes nehmen und den Salt hinten anfügen. Davon einen Hash bilden.
Hash(Kennwort+Salt) = Hash in der DB
Wichtiger ist, dass für jedes Kennwort ein eigenes Salt verwendet wird als wie das Salt gespeichert wird.
Wegen AES und RSA schau mal bei Google. Man überträgt ein Einmalkennwort für AES mit RSA (PKI)
Stefan
1
Oder ein Token Verwenden der den Benutzer als solchen Autorisiert.
Ein Token ist aber auch nichts als Benutzername und Kennwort in einem. Mit oder ohne Hash und Salt.
Stefan
Stefan
nicht ganz da der User diesen meist selbst immer neu Generieren kann für die Authorisierung.
Moin,
klinke mich eigentlich nur kurz zum Thema Salt ein, weil es a) den Autor ggf. interessieren könnte, mich aber mal aus rein persönlichen Interesse, ohne konkretes Vorhaben:
Wäre es sinnvoll, das Salt aus dem Hash des Kebnnwortes zu bilden und anzuhängen?
Quasi wie folgt (Code frei erfunden):
Die Ausgabe wäre dann:
*Hashes via SHA-256 Online erzeugt: hashgenerator.de
Bzw. könnte ich ja den "inneren" Hash mittels SHA-256 erzeugen und den gesamten Hash nochmal via SHA-512...
Wäre sowas geeignet oder auch fehlerbehaftet?
Klar, wenn ich weiss, wie das Kennwort zusammengesetzt wird, habe ich "verloren", aber mit einem fest kodierten, in abhängigkeit des Users eingesetzten Salts ist das System ja genauso anfällig, oder?
Gruß
em-pie
P.S. Sry, wenn das Thema ggf. jetzt etwas aufgebläht wird, aber ich finde, es passt hier aber gerade ganz gut rein.
klinke mich eigentlich nur kurz zum Thema Salt ein, weil es a) den Autor ggf. interessieren könnte, mich aber mal aus rein persönlichen Interesse, ohne konkretes Vorhaben:
Wäre es sinnvoll, das Salt aus dem Hash des Kebnnwortes zu bilden und anzuhängen?
Quasi wie folgt (Code frei erfunden):
$myPassword = meinKennwort
$hash = hash($myPassword & hash($myPassword))
print "Ergebnis: " & $hash Die Ausgabe wäre dann:
bbff31b7b52e8dce424e5af229a0afa85ffdc911394e4a9cb11916a898662f91 Bzw. könnte ich ja den "inneren" Hash mittels SHA-256 erzeugen und den gesamten Hash nochmal via SHA-512...
Wäre sowas geeignet oder auch fehlerbehaftet?
Klar, wenn ich weiss, wie das Kennwort zusammengesetzt wird, habe ich "verloren", aber mit einem fest kodierten, in abhängigkeit des Users eingesetzten Salts ist das System ja genauso anfällig, oder?
Gruß
em-pie
P.S. Sry, wenn das Thema ggf. jetzt etwas aufgebläht wird, aber ich finde, es passt hier aber gerade ganz gut rein.
1
Hallo,
bei dem Salt geht man davon aus, dass das System kompromitiert ist und der Angerifer Zugriff auf den Code und die Datenbank hat.
Also hilft die Verschleierung nicht.
Wenn man nun einen Kennworthash ohne Salt hat, kann man mit einer Rainbow-Table das Klartextkennwort ermitteln.
Durch das Salt benötige ich für jeden Salt eine eigene Tabelle.
Dafür kann man Monsterfarmen mieten die sowas in kurzer Zeit erstellen.
Was natürlich Geld kostet.
Wenn nun Jemand eine komplette Kundendatei aus einem Shop hat mit Email und Hash macht das einen großen Unterschied.
Für 500 Kundendatensätze kann sich eine RBT schon lohnen. Aber nicht 500.
Stefan
bei dem Salt geht man davon aus, dass das System kompromitiert ist und der Angerifer Zugriff auf den Code und die Datenbank hat.
Also hilft die Verschleierung nicht.
Wenn man nun einen Kennworthash ohne Salt hat, kann man mit einer Rainbow-Table das Klartextkennwort ermitteln.
Durch das Salt benötige ich für jeden Salt eine eigene Tabelle.
Dafür kann man Monsterfarmen mieten die sowas in kurzer Zeit erstellen.
Was natürlich Geld kostet.
Wenn nun Jemand eine komplette Kundendatei aus einem Shop hat mit Email und Hash macht das einen großen Unterschied.
Für 500 Kundendatensätze kann sich eine RBT schon lohnen. Aber nicht 500.
Stefan
A Chiffriersoftware zu programmieren setzt extrem viel Erfahrung und Wissen zur Sache voraus. Das ist eine Kette von a mathematischer Grundalgorithmus b Software zum Algorithmus c Software PRNG d Gestaltung Funktionssoftware mit Ergebnis d Fertigung Endsoftware.
B Regenbogentabellen werden in der echten (De)Kryptografie kaum genutzt, da diese spätestens bei 12 Stellen zu groß und zu unhandlich werden
C Regel 1 Selbst erstelle Kryptografie Software ist so lange Kinderquatsch, bis ein Team weltweit anerkannter Kryptografen diese einem Audit unterzogen hat
D Geschehen bei Truecrypt und Veracrypt
E Klar, wenn ich weiss, wie das Kennwort zusammengesetzt wird, habe ich "verloren", Echte Kryptografie muss immer vollständig Quelloffen sein! Es darf außer dem PW kein Geheimnis notwendig sein. Echte Kryptografie Software liegt vollständig im Quelltext vor und basiert auf der Tatsache, bis Dato nicht gelöster mathematischer Probleme!
B Regenbogentabellen werden in der echten (De)Kryptografie kaum genutzt, da diese spätestens bei 12 Stellen zu groß und zu unhandlich werden
C Regel 1 Selbst erstelle Kryptografie Software ist so lange Kinderquatsch, bis ein Team weltweit anerkannter Kryptografen diese einem Audit unterzogen hat
D Geschehen bei Truecrypt und Veracrypt
E Klar, wenn ich weiss, wie das Kennwort zusammengesetzt wird, habe ich "verloren", Echte Kryptografie muss immer vollständig Quelloffen sein! Es darf außer dem PW kein Geheimnis notwendig sein. Echte Kryptografie Software liegt vollständig im Quelltext vor und basiert auf der Tatsache, bis Dato nicht gelöster mathematischer Probleme!
Ja und Nein
- ein shared Secret aus dem Algorithmus zu machen ist wenig sinnvoll, kann Scriptkiddies aber durchaus aufhalten
- Salt und Pepper sind machen es Angreifern schwer
- Die Sicherheitsstufe muss zu meinem Projekt passen. Ein Team weltweit anerkannter Kryptografen ist wohl nicht immer notwendig. RSA und AES sind gut dokumentiert.
Nur am Rande
- Es gibt keinen Algorithmus der mathematisch sicher ist.
Die Sicherheit basiert allein auf der benötigen Zeit für einen Bruteforceangriff auf die Verschlüsselung. Eine aktuell sichere Verschlüsselung mit AES-256 kann durchaus in 20 Jahren innerhalb von 5 Minuten geknackt sein.
Vertrauen ist ein Problem.
Wenn mein OS durch den Hersteller schon kompromitiert ist, kann man keine Daten sicher speichern.
Und wer weiß ob die Hardware nicht auch solche Funktionen enthält? Alle Daten müssen an der CPU vorbei... Trojaner in Hardware sind möglich...
- ein shared Secret aus dem Algorithmus zu machen ist wenig sinnvoll, kann Scriptkiddies aber durchaus aufhalten
- Salt und Pepper sind machen es Angreifern schwer
- Die Sicherheitsstufe muss zu meinem Projekt passen. Ein Team weltweit anerkannter Kryptografen ist wohl nicht immer notwendig. RSA und AES sind gut dokumentiert.
Nur am Rande
- Es gibt keinen Algorithmus der mathematisch sicher ist.
Die Sicherheit basiert allein auf der benötigen Zeit für einen Bruteforceangriff auf die Verschlüsselung. Eine aktuell sichere Verschlüsselung mit AES-256 kann durchaus in 20 Jahren innerhalb von 5 Minuten geknackt sein.
Vertrauen ist ein Problem.
Wenn mein OS durch den Hersteller schon kompromitiert ist, kann man keine Daten sicher speichern.
Und wer weiß ob die Hardware nicht auch solche Funktionen enthält? Alle Daten müssen an der CPU vorbei... Trojaner in Hardware sind möglich...
