BCrypt

dennoch sollte es nicht hardcodet sein, oder in ConfigFiles einsehbar, sondern für jedes Passwort neu generiert.
Daraus wiederum folgt, dass das Salt dem CryptText unverschlüsselt mitzugeben ist.
Habich Tut zu gemacht.

Hash Funktion erzeugt immer den selben Hash aus dem Klartext.

1. Fall es wird nur das Passwort vom User gehasht :
z.B. sowas:
Pwd: 123456 ->hash lkdjfglksjhg
Pwd: Passwort -> hash sdjkw4erjkb324
Pwd: abc -> hash fjhkdfgre
es kann ja auch sein das zwei User unabhängig von einander das selbe simple Passwort nehmen. Es würde dann zweimal der selbe Hash in der DB stehen.

Diese erzeugten Hashes kann ein Angreifer dann leicht mit so genanten RainbowTables abgleichen. Eine Datei in der alle Hashes von solch einfachen Passwörtern stehen und wenn er ein Match findet kennt er das entsprechende Passwort (vorausgesetzt er kennt die Hashfunktion).

2. Fall das Userpasswort (Klartext) und Salt (jede mal wird eine zufällig Zeichenfolge erzeugt) werden im Klartext zusammengefügt und dann erste gehashet. Jetzt machen die Rainbowtables keinen Sinn mehr da.

Pwd: abc+salt -> hash fsdfsdfwedfedsfgsdfgfjhkdfgre+salt
Pwd: abc+salt -> hash aaaaaaaaaaaaaaakjhlkjhkjhkl+salt
Pwd:abc+salt -> hash bbbbbbbbbkljhlkjhsdfsd+salt

Da nun aus dem selben Passwort unterschiedliche Hashes werden. Das Salt wird unverschlüsselt dem Hash hinzugefügt. Ist auch egal, da es nur dazu dient, dass unterschiedliche Hashes entstehen.

3. Fall Pepper dient dazu simple Passwörter stärker gegen Brutforce zu machen. UserPasswort im Klartekt plus geheimes Pepper (ist nur dem Programmierer bekannt; das selbe Pepper wird allen Userpasswörtern angehangen). Pepper bleibt immer gleich:

z.B
Pwd: abc+pepper -> hash dfgertfgeetbrerberb
Pwd: 123456+pepper -> hash tzhjtj5tnbfrdtbrth

Also: Userpasswort+Pepper+Salt dann hashen
(Pepper geheim aber immer gleich, Salt immer neu aber 'öffentlich')

Pepper hilft gegen Bruteforce und macht kurze unsichere Passwörter besser.
Salt soll vor dem Angriff mit Lookuptables schützen in denen weitverbreitete Passwörterhashes stehen.

Pepper muss geheim sein. Salt muss bekannt sein.

Die Frage wie nun das Pepper sicher in Quelltext (oder wo auch immer) steht/aufgehoben wird kann ich nicht beantworten.

my 2 cents

Dein zweiter Fall ist nicht richtig
Ein Salt wird genauso mitgehasht. Statt abc wird abcsalt gehasht. In dem von dir konstruierten Verfahren wäre ein öffentlicher Salt nutzlos auch bei Passworttabellen
Wenn man den Salt mithasht, dann kann er öffentlich sein und er könnte sogar immer gleich bleiben und macht immer noch Passworttabellen nutzlos, allerdings nur die.

In den meisten Szenarien machen Salt und Pepper dasselbe. Man muss genau die Angriffstruktur definieren um diese Dinger zu unterscheiden.

@Haudruferzappeltnoch Ich hab deinen Post nicht so ganz verstanden. Eventuell meine ich das selbe wie Du.

Pwd: (abc+salt) -> hash aaaaaaaaaaaaaaakjhlkjhkjhkl+salt

Das plus steht dafür das die zwei strings zusammengehören. Dann erst wird die Hashfunktion damit ausgeführt. aaaaaaaaaaaaaaakjhlkjhkjhkl+salt soll dafür stehen, dass dem Hash (pwd+salt)-Ergenbis dann das Salt einfach angehangen wird (also auch wieder mach aus zwei strings einen).

Ich meine
passwort: geheim -> hashcode: mieheg
passwort: geheim, salt: salzig -> hashcode: gizlasmieheg

was ich bei dir verstanden hab
passwort: geheim, salt: salzig -> hashcode: miehegsalzig

@Haudruferzappeltnoch Nochmal und hoffentlich ohne Missverstände.

User gibt sein Passwort in Klartext in die Inputbox ein z.B.

Input.Text= 123456Passwort

Mit Random wird ein Salt erstellt und zwar für jeden User/Password ein neues z.B.

Rnd= fbc9eb //das ist das Salt

Hash(123456Passwortfbc9eb) => der Ergebnishash:
1b6809716752839b23a5a32a4ea4ddf0f032f800e1652658e0f0a8add4c851fd

An diesen HashString wird das Salt an einer bekannten Stelle angefügt. Meist am Anfang oder Ende des Hashes. Hier mal am Ende, das ergibt dann

1b6809716752839b23a5a32a4ea4ddf0f032f800e1652658e0f0a8add4c851fdfbc9eb

Dieser String wird in der Passwortdatenbank gespeichert. Das Salt ist also nicht verschlüsselt, wird aber zu Erstellung des Hashes benutzt.

UserObj ( Email:'xyz@bb.com', PasswordHash (1b6809716752839b23a5a32a4ea4ddf0f032f800e1652658e0f0a8add4c851fdfbc9eb) )

Beim nächsten mal Userlogin wird das gespeicherte Salt fbc9eb aus der Datenbank hinten vom Hash ausgelesen (gesucht mit der Email und dem Wissen das die letzten 6 stellen das Salt sind).
Der User gibt wieder sein Passwort als Klartext ein und das Programm fügt diesem wieder den Salt aus der DB an und schon bekommt man den richtigen Hash Wert und der User darf sich einloggen.
Und RainbowTable 123456Passwort = 262d7c43b8a76a498120039b55ffa2fded7095a789d0b0cecc699b920eaa700d funktioniert nicht mehr.
Zum spielen

Jau ich sehe, du verschlüsselst den Salt mit ok ok.
Dass du den Salt nochmal mit anhängst ist nur die Abspeicherung des Werts und verwirrt bei der Erklärung sehr. Denn die RainbowTable scheitert schon bei 1b6809716752839b23a5a32a4ea4ddf0f032f800e1652658e0f0a8add4c851fd
Man könnte den Salt genauso gut in eine Tabelle daneben packen

naja der Salt muss ja abgespeichert werden. Damit man den Hash wieder erzeugen kann userpasswort+Salt halt. Der user weiß ja nix vom Salt und gibt diesen ja nicht ein. Okay der Salt könnte auch extra gespeichert werden.

UserObj ( Email:'xyz@bb.com', PasswordHash:'1b6809716752839b23a5a32a4ea4ddf0f032f800e1652658e0f0a8add4c851fd', Salt:'fbc9eb' )

Ich kenn das nur so, dass der Salt gleich mit an den Hash 'rankommt'.

Zitat:
"Denn die RainbowTable scheitert schon bei 1b6809716752839b23a5a32a4ea4ddf0f032f800e1652658e0f0a8add4c851fd"

Ja aber nur weil das Salt mit gehashet wurde.