this post was submitted on 05 Oct 2026
603 points (99.3% liked)
Lemmy Shitpost
42200 readers
4191 users here now
Welcome to Lemmy Shitpost. Here you can shitpost to your hearts content.
Anything and everything goes. Memes, Jokes, Vents and Banter. Though we still have to comply with lemmy.world instance rules. So behave!
Rules:
1. Be Respectful
Refrain from using harmful language pertaining to a protected characteristic: e.g. race, gender, sexuality, disability or religion.
Refrain from being argumentative when responding or commenting to posts/replies. Personal attacks are not welcome here.
...
2. No Illegal Content
Content that violates the law. Any post/comment found to be in breach of common law will be removed and given to the authorities if required.
That means:
-No promoting violence/threats against any individuals
-No CSA content or Revenge Porn
-No sharing private/personal information (Doxxing)
...
3. No Spam
Posting the same post, no matter the intent is against the rules.
-If you have posted content, please refrain from re-posting said content within this community.
-Do not spam posts with intent to harass, annoy, bully, advertise, scam or harm this community.
-No posting Scams/Advertisements/Phishing Links/IP Grabbers
-No Bots, Bots will be banned from the community.
...
4. No Porn/Explicit
Content
-Do not post explicit content. Lemmy.World is not the instance for NSFW content.
-Do not post Gore or Shock Content.
...
5. No Enciting Harassment,
Brigading, Doxxing or Witch Hunts
-Do not Brigade other Communities
-No calls to action against other communities/users within Lemmy or outside of Lemmy.
-No Witch Hunts against users/communities.
-No content that harasses members within or outside of the community.
...
6. NSFW should be behind NSFW tags.
-Content that is NSFW should be behind NSFW tags.
-Content that might be distressing should be kept behind NSFW tags.
...
If you see content that is a breach of the rules, please flag and report the comment and a moderator will take action where they can.
Also check out:
Partnered Communities:
1.Memes
10.LinuxMemes (Linux themed memes)
Reach out to
All communities included on the sidebar are to be made in compliance with the instance rules. Striker
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I appreciate the enthusiasm but my load balancer will get sad if I let you send more than 1500 bytes.
First round of hashing could be done client-side, and then send that to the server.
Would be cool to also add salt so that the hash couldn't get re-used across services even with the same source password/file if somehow captured.
Idea:
Basically, the hash is your password. Data can be whatever.
Most websites already use JavaScript, so why not.
So, I was having trouble sleeping last night and found myself mulling over your idea.
As any good sleep deprived tech I went down a rabbit hole. There are solutions that prepare the encrypted payload on the client side. But, why you don't see solutions offering you to authenticate with the entire lotr series is that you hit a ceiling really fast where more data is the same security threshold as the former smaller data.
If you want to derive security from large data there's already a scalable solution in the form of private public key pairs, where the size of the key is directly tied to the security. So if you convert lotr to a prime number you can get somewhere with that approach.
Exactly, this is equivalent to using a password of a particular length with only hex digits. It may be long, but the original data is completely unnecessary here.
I'd rather not make the client do anything like that, you cannot trust a client, EVER; what if some script kiddie tries to send the clear passwd by modifyng the request? Ofc it's a very minor problem but still...
You already trust the client with your password regardless.
I wouldn't send the salt to the client. Have it hash the password, then the server hashes that with the salt for comparison and storage.
But that would mean you can't verify the password complexity server side, which can be bad for certain accounts.
If there would be an advantage to doing so, the server could still do that anyway. You'd just end up storing client salt and server salt.
My main concern was MITM which doesn't modify the webpage if web UI is used, such as on corporate networks which require client devices to have that network's root certificate for scanning and activity logging.