this post was submitted on 21 Jun 2023
86 points (100.0% liked)

Technology

37723 readers
59 users here now

A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.

Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.

Subcommunities on Beehaw:


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
 

This next version is quite important as it brings important fixes.

Bugs: https://enterprise.lemmy.ml/c/actualbugs018

cross-posted from: https://sh.itjust.works/post/300197

Enterprise: enterprise.lemmy.ml - Thank you!

you are viewing a single comment's thread
view the rest of the comments
[–] Xanvial@lemmy.one 10 points 1 year ago* (last edited 1 year ago) (2 children)

Some password hashing methods has max characters length. For example Bcrypt has 72 max length. This is mostly to avoid taking too much time encrypting user input.

If there's no limit someone can technically froze the server by inputting large password (not because the request is big, but the process is exponentially takes more CPU process the longer characters it needs to compute)

[–] dudeami0@lemmy.dudeami.win 3 points 1 year ago

Having only ever implemented PBKDF2 this is a good insight as well. This limitation does not seem to be an issue with more modern hashing algorithms, but I can see where limiting the size to a reasonable amount for purposes of having an upper bound on performance would be needed.

That's an interesting attack vector. Thanks for the insight.