Home to all things "Mildly Infuriating" Not infuriating, not enraging. Mildly Infuriating. All posts should reflect that.
I want my day mildly ruined, not completely ruined. Please remember to refrain from reposting old content. If you post a post from reddit it is good practice to include a link and credit the OP. I'm not about stealing content!
It's just good to get something in this website for casual viewing whilst refreshing original content is added overtime.
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.
...
7. Content should match the theme of this community.
-Content should be Mildly infuriating.
-The Community !actuallyinfuriating has been born so that's where you should post the big stuff.
...
8. Reposting of Reddit content is permitted, try to credit the OC.
-Please consider crediting the OC when reposting content. A name of the user or a link to the original post is sufficient.
...
...
Also check out:
Partnered Communities:
Reach out to LillianVS for inclusion on the sidebar.
All communities included on the sidebar are to be made in compliance with the instance rules.
In password security, the longer the better. With a password manager, using more than 24 characters is simple. Unless, of course, the secure password is not accepted due to its length. (In this case, through STOVE.)
Possibly indicating cleartext storage of a limited field (which is an absolute no-go), or suboptimal or lacking security practices.
No, there should be no limit. The password should be salted and hashed stored on the server side they should be uniformly like 256 or 512 characters behind the scenes no matter if you send it 5 characters or 50,000. The password that is stored is just a mathematical representation of the password.
As far as DDOS, It doesn't matter what the limit is, you can send them millions of characters rven if they have a limit. If you're going to DDOS you're going to just use SYN flood, pings, for all of the matters you could send headers.
Not DDOS, DOS. You can often crash an unprepared server with one request by telling it to hash more data than it has memory for. See this blog post for a well-known web framework. Let’s say I just sent it a 10GB password, it still has to process that data whether or not the hash eventually shortens to the database field length.
Just another in a long list of decisions Django made that makes me dislike it.
Let the client hash the password to reduce it. then enforce the hash length as the password length. It's transparent to the user and doesn't look like a pile of bad ideas.
Though it could also amplify DDOS. Allowing 72 character passwords lets a DDOS be three times rougher despite being a seemingly modest limit for a single request.
If a password/passphrase is 24 characters, then any further characters have no incremental practical security value. The only sorts of secrets that demand more entropy than that are algorithms that can't just use arbitrary values (e.g RSA keys are big because they can't be just any value).
So I just went through something similar with a security team, they were concerned that any data should have limits even if transiently used because at some point that means the application stack is holding that much in memory at some point. Username and password being fields you can force into the application stack memory without authentication. So potentially significantly more expensive than the trivial examples given of syn and pings. Arbitrary headers (and payloads) could be as painful, but like passwords those frequently have limits and immediately reject if the incoming request hits a threshold. In fact a threshold to limit overall request size might have suggested a limited budget for the portion that would carry a password.
24 characters is enough to hold a rather satisfactorily hardened but human memorable passphrase. They mentioned use of a password manager, in which case 24 characters would be more entropy than a 144 bit key. Even if you had the properly crypted and salted password database for offline attack, it would still be impossibly easier to just crack the AES key of a session, which is generally considered impossible enough to ignore as a realistic risk.
As to the point about they could just limit requests instead of directing a smaller password, well it would certainly suck of they allowed a huge password that would be blocked anyway, so it makes sense to block up front.
Why not client side hash? JS is more than capable.
Sure, you could do something like that to normalize all manner of passwords to a manageable string, but:
That hash becomes the password, and you have to treat it as such by hashing it again server side. There's a high risk a developer that doesn't understand skips hashing on the backend and ends up insecurely storing a valid password for the account "in the clear"
Your ability to audit the password for stupid crap in the way in is greatly reduced or at least more complicated. I suppose you can still cross reference the password against HIBP, since they use one way hash anyway as the data. In any event you move all this validation client side and that means an industrious user could disable them and use their bad idea password.
if you have any client contexts where JavaScript is forbidden, then this would not work. Admittedly, no script friendly web is all but extinct, but some niches still contend with that
Ultimately, it's an overcomplication to cater to a user who is inflicting uselessly long passwords on themeselves. An audience that thinks they need such long passwords would also be pissed if the site used a truncated base64 of sha256 to get 24 ASCII characters as they would think it's insecure. Note that I imply skipping rounds, which is fine in such a hypothetical and the real one way activity happens backend side.