bcrypt + eigenen salt?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Hi,

habe folgendes Problem:

Habe ein challenge Response Schema:

Ich bekomme von einem Server einen Salt und eine Challenge, beide 16bytes groß.
um die Antwort zu berechnen muss ich folgendes machen:
response = bcrypt(bcrypt(pw, salt), challenge)

Auf der Seite des Servers wird das mit php gemacht und war gar kein Problem aufer
Python Seite aber hab ich keien Ahung wie ich das hinbekommen soll.
Wollte eigentlich die Bcrypt Library verwenden, die sieht aber anscheinend gar nicht vor, dass man
einen eigenen Salt ein geben kann sondern bietet nur eien Funktion "gensalt" die immer einen neuen
zufälligen Salt erzeugt.

Meine Frage ist nun:

Weiß jemand wie man in python Bcrypt mit einem eigenen Salt machen kann?
MfG

p90
Boa
User
Beiträge: 190
Registriert: Sonntag 25. Januar 2009, 12:34

Soweit ich das sehe kannst du einfach den gensalt Aufruf mit deinem eigenen salt ersetzen.
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Hi,

hab ich probiert, da meint er nur, dass wäre ein Invalider salt.
Habs jetzt doch gefunden.
Und zwar hier: http://stackoverflow.com/questions/8869 ... ypt-hashpw
Man darf da nicht den normalen salt füttern sondern muss da noch extra zeug drum rum machen (warum auch immer...)
Was bcrypt haben will hat diese Form: $Version$log2(NumRounds)$salt
Werde das mal ausprobieren und mich dann nochmal melden aber gerade ist echt mal zu früh für sowas ^^
Boa
User
Beiträge: 190
Registriert: Sonntag 25. Januar 2009, 12:34

Der Salt hat ein spezielles Format; er fängt mit dem Identifier '$2a$12$' an und dem fogen 22 Zeichen.

Code: Alles auswählen

salt = 'aaaaaaaaaaaaaaaaaaaaba'
pw= 'abc'
bcrypt.hashpw(pw, '$2a$12$'+salt)
>>'$2a$12$aaaaaaaaaaaaaaaaaaaabOK5ODO9BeB8zq472j4G/DTWd2E5WBZWa'

bcrypt.hashpw(pw, '$2a$12$aaaaaaaaaaaaaaaaaaaabOK5ODO9BeB8zq472j4G/DTWd2E5WBZWa')
>>'$2a$12$aaaaaaaaaaaaaaaaaaaabOK5ODO9BeB8zq472j4G/DTWd2E5WBZWa'

len(salt)
>>22
Warum das 22.te Zeichen beim erstellten Hash ignoriert wird weiß ich nicht; könnte ein Fehler sein, aber ich kenne mich nicht mit dem Algorithmus aus. Die Frage ist wie dein PHP Code aus den 16 Bytes die 22 Zeichen macht. Und ich bin mir nicht sicher ob der Prefix bei jeder Implementierung gleich sein muss.
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Erstmal, bcrypt braucht tatsächlich 16random bytes als salt, PHP nimmt diese 16bytes base64 encoded was dann genau 22 Zeichen sind.

Aber erst mal Danke für die Antwort! Das Hilft sehr weiter!
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Oh Gott. Das ist noch hässlicher.
Der Salt muss eigentlich ein Bytestring sein. Arrrrrrg.
BlackJack

@p90: Macht doch irgendwie auch Sinn, sonst würde man ja Bits verschenken.
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Das macht überhaupt keinen Sinn weil man ja gar nicht weiß, welches Encoding das "$2y$12$ braucht.
Um genau zu sein machen sie es anscheint so, dass das immer das Plattform Encoding ist.
Naja, hab jetzt die gensalt Funktion gepatcht sodass ich der die 16bytes einfach so geben kann und der Rest dann wieder davon gemacht wird. Mal sehen ob das gemergt wird.
BlackJack

@p90: Wieso encoding? Ich denke es soll ein Bytestring sein, da gibt es Bytes. Das hat mit Text oder Kodierungen dann nichts zu tun.
p90
User
Beiträge: 198
Registriert: Donnerstag 22. Juli 2010, 17:30

Für die 16 random bytes stimmt das auch aber "$2y$10$" ist ja erst mal ein Unicode String. Und ob die dann z.B. Ascii Encoding nehmen oder das System Encoding war mir erst mal nicht so ganz klar (bis ich mir halt die gensalt Funktion genauer angeguckt habe).
Dachte eigentlich erst die würden ascii verwenden weil der eigentliche bcrypt Kram dann in c oder c++ gemacht wird.
BlackJack

@p90: Wie '$2y$10$' kodiert wird ist doch fast egal, da geht eigentlich fast alles ausser UTF-16 oder UTF-32 weil da ja nur Zeichen aus dem ASCII-Bereich vorkommen. Wenn man das irgendwo im Quelltext literal angeben muss, würde man doch sowieso einfach ein b vor das Literal schreiben und gut ist.
Antworten