Timeline for Do I need to sanitize user input to scrypt, or to PBKDF's in general?
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 7, 2021 at 17:50 | comment | added | phoenixdown |
Thanks that's a great idea - i can add a test to ensure foo and foo\0bar do not evaluate to the same result, and fail if they do.
|
|
| Sep 3, 2021 at 5:35 | comment | added | Gh0stFish |
@phoenixdown I don't think that you necessarily need to strip out null bytes, you just need to check that the specific implementation you're using handles them properly. For example, if you compare two strings such as foo and foo\0bar (with a fixed salt) and you end up with the same result, that suggests the library you're using doesn't handle null bytes properly - in which case you'd need to remove them.
|
|
| Sep 2, 2021 at 19:49 | comment | added | phoenixdown |
Thanks @Gh0stFish, i notice in the blog post the author says scrypt and PBKDFv2 are not effected by the issue. What would you recommend? Checking the input for any null bytes and removing them before passing to scrypt? @bk2204 is this something you would also recommend?
|
|
| Sep 2, 2021 at 19:43 | comment | added | Ilmari Karonen | I'd like to blame that mostly on PHP, but a quick glance at Wikipedia suggests that the handling of null bytes in bcrypt was indeed poorly specified, and I wouldn't be surprised if the original C reference implementation also had the same bug. (In any case, bcrypt isn't really a KDF but a password hashing function, and a rather old and outdated one at that. You can't use it for key derivation — at least not easily — and given that there are better alternatives, you really shouldn't be using it for password hashing nowadays either.) | |
| S Sep 2, 2021 at 8:54 | review | First answers | |||
| Sep 2, 2021 at 9:56 | |||||
| S Sep 2, 2021 at 8:54 | history | answered | Gh0stFish | CC BY-SA 4.0 |