Passwort verstecken?

Sherlock 🕵🏽‍♂️ schrieb:

Mein Lieblingswörterbuch (dict.cc) übersetzt das Wort mit "verfinsternd". Passt irgendwie nicht.

Verschleiern ...

Erste Frage: to obfuscate: verdunkeln, vernebeln, verschleiern... https://dict.leo.org/englisch-deutsch/obfuscate

Zweite Frage: Es steht Dir frei es so zu machen. Sicher ist das aber trotzdem nicht. Echte Sicherheit gibts nur durch kryptografische Verfahren. Vermutlich macht es deshalb niemand wirklich ernsthaft so.

Bauform B. schrieb:

hallo!

Wie schreibt obfuscating auf deutsch? Egal, im Prinzip ist das¹ auch meine Frage:

1

I want to do this

2

> 

3

> PASSWORD="10101001001010010101010100101" #binary or other code

4

> NEW_PASS=`decrypt $PASSWORD`

5

> program --pass=$NEW_PASS

Wenn man die Ausgabe von decrypt per file descriptor übergeben kann, ist das Passwort schon ziemlich unsichtbar -- außer, jemand bekommt das Script in die Finger.

Wenn aber decrypt eine 4-stellige Pin abfragen würde, wäre es knapp 10000 Mal sicherer... Geldautomaten funktionieren auch mit einer 4-stelligen Pin (ok, die können die Karte einziehen). Finde ich nur nichts zum Thema oder warum macht man das nicht?

https://stackoverflow.com/questions/9828202/obfuscating-stored-passwords-in-bash

Gibts hier eine Frage?

Die Frage warum Geldautomaten nur 4 stellige Pin haben hast du dir ja beantwortet.

Cyblord -. schrieb:

program --pass=$NEW_PASS

Patch "program", so das es sicher ist und das Passwort nicht per Command Line parameter erwartet.

Oliver schrieb:

Cyblord -. schrieb:

program --pass=$NEW_PASS

Würdest du bitte korrekt zitieren? Der Codeschnipsel ist nicht von mir.

Bauform B. schrieb:

Wie schreibt obfuscating auf deutsch? Egal, im Prinzip ist das¹ auch meine Frage:…

Es gibt bei Sicherheit genau zwei Wege:

• Man kann es gut machen und bewährte, verlässliche Methoden anwenden.
• Man kann obfuscation nutzen.

An solchen Stellen ist base64 Codierung weit verbreitet.

hust hust

Mach das bitte ordentlich. Speicher nicht das Passwort, auch nicht verschlüsselt, speichere einen Hashwert des Passworts.

Für PHP z.B. folgendes:

1

$pass_hash=password_hash($password, PASSWORD_DEFAULT, ['cost'=>13]);

Nur den Hashwert speichern, den diese Funktion zurückgibt. Für cost einen Parameter einsetzen, der möglichst hoch ist, aber nicht zuviel Rechenzeit für den Hash verwendet. 13 sollte einigermaßen gängig sein, auf starken Servern geht mehr.

Das Passwort kann man dann hiermit prüfen...

1

$pass_hash='<hier Ausgabewert von password_hash eintragen>';

2

if (password_verify($password,$pass_hash)===true) {

3

 echo'Passwort richtig!';

4

} else {

5

 echo'Passwort falsch!';

6

}

Das Ergebnis davon ist, daß niemand so einfach an das Passwort herankommt, selbst dann nicht wenn er wie auch immer an den Quellcode bzw. an den Hash herangekommen ist.

Andi M. schrieb:

Echte Sicherheit gibts nur durch kryptografische Verfahren. Vermutlich macht es deshalb niemand wirklich ernsthaft so.

Man soll aber auch nicht übertreiben. Ob man in dem ursprünglichen Beispiel "correct horse battery staple" oder "4711" eintippen muss, ist doch kein prinzipieller Unterschied? Solange der Angriff über die normale Benutzerschnittstelle passiert, sehe ich auch keinen praktischen Unterschied. Meinetwegen vielleicht 5 Ziffern, aber dann muss gut sein.

Ben B. schrieb:

Das Ergebnis davon ist, daß niemand so einfach an das Passwort herankommt, selbst dann nicht wenn er wie auch immer an den Quellcode bzw. an den Hash herangekommen ist.

Davon muss man wohl ausgehen. Das ist das eigentliche Problem. Verzögerungstaktik oder Karte einziehen ist dann nicht mehr :(

Speicher nicht das Passwort, auch nicht verschlüsselt, speichere einen Hashwert des Passworts.

Das ist ja einfach, also für den Zweck. Aber wenn man das Passwort im Klartext braucht? Manchmal soll ein EMail-Client oder ein Browser ein Passwort speichern oder eben, wenn der User es in einem Script braucht.

Sowas habe ich mal testweise für eine verschlüsselte Datenbank gebaut. Das arbeitet mit einem Master-Key für die Datenbank, den aber kein Benutzer kennt. Dieser Master-Key wird vom Script mit dem Benutzernamen/Passwort-Päärchen des Benutzers (plus Salt) entschlüsselt. Dadurch kann das Script ihn benutzen, wenn ein gültiger Benutzer angemeldet ist.

Nachteil: Man muss den Master-Key für jeden Benutzer einzeln verschlüsseln und sollte ein Benutzer sein Kennwort vergessen, braucht er Hilfe von einem anderen noch gültigen Benutzer, da sonst der Master-Key nicht mit seinem neuen Kennwort neu verschlüsselt werden kann (weil der "verlorene" Benutzer ihn nicht mehr entschlüsseln kann). Aus dem Grund sind auch keine automatisierten Anmeldungen möglich, ein neuer Benutzer muss durch einen bestehenden Benutzer autorisiert werden, bevor er Zugriff auf die Datenbank bekommen kann.

Bauform B. schrieb:

Wie schreibt obfuscating auf deutsch?

Ich würde das, wie auch andere im Thread, mit "verschleiern" oder "verwirren" übersetzen.

1

I want to do this

2

> PASSWORD="10101001001010010101010100101" #binary or other code

3

> NEW_PASS=`decrypt $PASSWORD`

4

> program --pass=$NEW_PASS

Wie andere schon angemerkt haben, ist eine Übergabe über die Kommandozeile zweifellos die unsicherste Möglichkeit. Denn dann steht das Passwort in der Prozeßliste und auch in /proc/<pid>/cmdline, zumindest bis das $program sein argv überschreibt (ja, das geht). Auch als Environment-Variable ist das kaum sicherer, da das Paßwort dann in /proc/<pid>/environ steht...

Wenn man die Ausgabe von decrypt per file descriptor übergeben kann, ist das Passwort schon ziemlich unsichtbar -- außer, jemand bekommt das Script in die Finger.

Korrekt.

Wenn aber decrypt eine 4-stellige Pin abfragen würde, wäre es knapp 10000 Mal sicherer... Geldautomaten funktionieren auch mit einer 4-stelligen Pin (ok, die können die Karte einziehen).

Nunja, Geldautomaten benutzen eine Multifaktor-Authentifizierung: "what you have" ist die Karte, "what you know" die Pin.

Finde ich nur nichts zum Thema oder warum macht man das nicht?

So etwas wird tatsächlich gemacht, beispielsweise GnuPG (GPG) kann man die Passphrase über einen Dateideskriptor mit --passphrase-fd und über eine Datei mit --passphrase-file übergeben, wenn zusätzlich die Option --batch angegeben wird. Ansonsten wird so etwas deswegen selten gemacht, weil es genügend andere Möglichkeiten zur Absicherung gibt: UNIX-Gruppen, ACLs, AppArmor / SE-Linux / RSBAC, sudo / doas / run0, (HashiCorp|Ansible) Vault, Docker Secrets, ... und ja, das hat was von [1].

Wenn Du uns genauer erklärst, welches Programm Du genau wogegen absichern möchtest, dann können wir Dir sicherlich besser helfen. Vieles ließe sich beispielsweise für alle möglichen (und natürlich auch eigene) Programme über die Pluggable Authentication Modules (PAM, libpam) realisieren.

[1] https://xkcd.com/927/

Cyblord -. schrieb:

Würdest du bitte korrekt zitieren? Der Codeschnipsel ist nicht von mir.

ich bitte um Entschuldigung.

Sherlock 🕵🏽‍♂️ schrieb:

Mein Lieblingswörterbuch (dict.cc) übersetzt das Wort mit "verfinsternd". Passt irgendwie nicht.

Technisch gesehen: verstecken.

Ich finde es wichtig auch zu verstehen, wie das gemeint ist. Man hatte ja auch Hardware-Schaltungen versteckt. In der Software kann man das aber machen, ohne äußere Zugaben und da ist das "Vertecken" per "Programm" auch zu einer Art Wettbewerb im Zusammenhang mit Programmiersprachen geworden.