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?
1)
https://stackoverflow.com/questions/9828202/obfuscating-stored-passwords-in-bash
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?>> 1)> 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.
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:
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/
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.