Pro@programming.dev to Programming@programming.devEnglish · 1 year agoCursed knowledge we have learned as a result of building Immich that we wish we never knew.immich.appexternal-linkmessage-square56linkfedilinkarrow-up1147arrow-down14
arrow-up1143arrow-down1external-linkCursed knowledge we have learned as a result of building Immich that we wish we never knew.immich.appPro@programming.dev to Programming@programming.devEnglish · 1 year agomessage-square56linkfedilink
minus-squareMaestro@fedia.iolinkfedilinkarrow-up9·1 year agoYes. Current best practice is to use pass phrases. They can get long. Also, salt length is added to the password length as well, depending on implementation.
minus-squarePhen@lemmy.eco.brlinkfedilinkarrow-up3·1 year agoImagine getting a multi byte character at the right position to get it split so that one byte gets in and the other doesn’t.
minus-squareMaestro@fedia.iolinkfedilinkarrow-up5·1 year agoIt doesn’t matter. That will happen for both the stored hash and the entered password, so it still matches.
minus-squarePhen@lemmy.eco.brlinkfedilinkarrow-up1·1 year agoAs long as it runs the same code, yes. But things may change, clients may pre-emptively split the string or stuff like that.
Yes. Current best practice is to use pass phrases. They can get long. Also, salt length is added to the password length as well, depending on implementation.
Imagine getting a multi byte character at the right position to get it split so that one byte gets in and the other doesn’t.
It doesn’t matter. That will happen for both the stored hash and the entered password, so it still matches.
As long as it runs the same code, yes. But things may change, clients may pre-emptively split the string or stuff like that.