Saik0

Divorce and child custody agreements are two separate legal things and child custody agreements are thankfully not a matter of public record.

And yet I was able to pull my parents Divorce from decades ago and in those documents were details about who has rights to me… I think this is likely a state by state thing. Though my name was never directly mentioned.

Each one of these events is easily shown to have good merits for being public record. Even ignoring the obvious case of “we want to track what the police/courts were actually doing”.

Traffic accidents

Occurs in front of your property and cause some amount of damage to your stuff that officers didn’t outline in any reports. You want to be able to figure out who did it so you can send them the bill/sue them. Hiding these records doesn’t make sense. Other obvious uses would be to find out where someone went/is missing, eg if someone died.

traffic citations

You’re attempting to hire someone for a job, part of that job is some amount of driving. Being able to lookup if they have any record of driving poorly would be due diligence you’d expect a company to do. Hell getting into an Uber or Lyft… You might want to lookup your driver. You could be surprised.

bankruptcies

Hire someone to do something related to finances in your company? Or to file your taxes? Might want to actually double check they’re not idiots on their own dime either. Someone asks you for a loan, or any other financial related stuff. Records of them defaulting are important.

buying a house

Your dog ran up to me and bit me, then ran away. Being able to get the property details can be highly important.

getting divorced

Can trigger a number of things. If divorce has any kid related issues… and one parent no longer has rights to the child… Schools/doctors can validate that one parent no longer has those rights without just blindly trusting random documents one parent provides.

Well… No offense… but duh? It’s not like OP can migrate his spouses “Spouse@gmail.com” address to his mail server.

I was under the assumption (and I could be wrong) that OP owns the domain… And wants to run their mailboxes. If she wants to keep her own mailbox and use it, just forward it to her gmail if that’s what she wants. I’m also not insinuating forcing someone into something.

I own my domain(you guessed correctly) and host my own emails. My spouse does use an inbox on my server(actually a few)… If she didn’t want to anymore she can open a mailbox where-ever she wants… and I’ll even forward whatever I get to her. That’s it. Wouldn’t stop me from running my own inbox on my own server. And I’m not forcing her to do anything at all. She can use it or not.

This is the mentality I have when I made the previous comments. Just forward her stuff off, she can go wherever she wants.

Until the basement floods and the server goes offline for a few days

That’s what backups are for.

or botched upgrade that’s failing quietly;

See above

over zealous spam assassin configuration;

That’s an assumption that you’re using this specific product.

What’s funny is you think that all of this can’t happen to your stuff on Google’s servers either for some reason… Say the wrong thing in a Youtube comment? Boom whole google profile banned. All your emails are gone too.

Or random software that interfaces poorly with each other (https://support.google.com/mail/thread/142335843/all-of-my-emails-have-disappeared-how-can-i-recover-them?hl=en)

SMTP is stupidly forgiving. You’re not going to magically lose singular emails.

But one thing is for sure, my wife won’t have any of it. She’s a total backwards thinking give me windows or I’ll jump kind of Gal.

So… forward her inbox to her personal gmail account? Keep your mail server as it was for you?

And I showed you a way that we can make it so it doesn’t matter.

Force local hash -> Hash/salt what you get. Password can be a million characters long. You’ll only ever get like 128 characters.

Nothing I talked about said to not validate inputs. Just that we don’t have to limit a persons password selection.

And a meteor can hit my server the exact time you send your hash which will DOS you/others as well. What’s your point.

The thread is talking about what it takes to store passwords. There is not DOS potential in a well designed system. Just because you want to arbitrarily conjure up bullshit doesn’t make that any less true.

Rejecting large inputs != disallowing users to have large passwords. Why are you attempting to straw-man me here?

Sensible upper bounds are a must to provide a reliable service not open to DDOS exploits.

If I choose to make you hash it in browser first… Then I simply don’t care do I? I can hash/salt again when I get your hash. Edit: There are other answers to the “DDOS problem” that don’t require upper bounds.

If you hash in the browser it means you don’t salt your hash. You should absolutely salt your hash, not doing so makes your hashes very little better than plaintext.

That’s not true. If they send hashed password you could salt/hash again on server if you’re trying to keep the salt “secret”. Their hash should always be the same if they’ve submitted the same password. You’d just be hashing a hash in that case… but it’s the same premise.

That being said, from a security standpoint, any gain in entropy by adding characters would be negligible past a certain point.

That would be completely based on the hash being used. In the example above I showed SHA512 which is 64Bytes. If we’re using ASCII (7 bit per character) as our input then 64 Bytes is just over 73(73.1428…) characters. After that you’re losing data in the hashing process and by that effect it would be negligible… (There’s some wiggle room here in that we can’t type hidden ASCII characters so some passwords over 73 characters would fill those spaces… but detecting collisions is silly and non-trivial… better to just not worry about those at all.)

Extended ASCII would be same premise, just 64 characters instead of 73.

The reality is that nobody is using much more than 64 Bytes for their hashing algorithm for passwords… 64 characters is a good number to max out most of them. Databases don’t need to store much at all regardless of the length of your actual password. If you’re developing an app you can set the database to limit based on the algorithms you’re using. If you have no idea what the web-dev will actually use… then 128 characters on the database field is probably pretty safe (88 I think if storing as Base64, 128 if storing in Hex. Could be off by one here.) and literally trivial to store. The point being that even if every one of your users submitted 10000 character long passwords… that’s irrelevant and trivial for storage as hashes.

I sort of get it. You don’t want to allow the entire work of Shakespeare in the text field, even if your database can handle it.

You don’t store the original text. You store the hash of it. If you SHA512 it, anything that’s ever given in the password field will always be 64Bytes.

The only “legit” reason to restrict input to 16 character is if you’re using an encryption mechanism that just doesn’t support more characters as an input. However, if that’s the case, that’s a site I wouldn’t want to use to begin with if at all possible.

So it isn’t whether you’re using Azure, it’s whether you’re using CrowdStrike (Azure related or not)

No. Azure platform is using Crowdstrike on their hypervisors. So simply using Azure could be sufficient to hurt you in this case even if your Azure host isn’t using Crowdstrike itself. But yes, otherwise it’s a mix of Windows+Crowdstrike.

Yes, but Azure platform itself was using it. So many of those systems were down overnight (and there’s probably still stragglers). The guy you responded to specifically called out Azure-based services.

Oh god this make so much more sense…

I had read a comment from OP talking about random shit, then ran into this thread… I thought they just lost their shit. I still wonder… but a lot less now.

If it’s a raidz, you can.

Yes, but at the very least they have to do queries to build that profile out across dozens or hundreds of recipients… And they only get what I explicitly sent to them/their users.

Google collects 100% of the emails you’re getting on gmail and it’s already sent directly to you… so they see it completely… including emails being sent to other sources since it originates from their server (so collecting information that would be going to an MS Exchange server as well…).

Self hosting this means that you’re collecting your own shit… And companies can only get the outgoing side to their users. And never the full picture of your systems/emails.

This matters a lot more than you think. Lots of systems for automation sends through systems like Mailchimp, PHPmailer, etc… So those emails from your doctor likely never originated from MS or Google to begin with. When it hits your inbox on Gmail or Outlook… Well now it’s on their system. Now they can analyze it.

Mailcow.

Personally. No. The hardest part is getting a clean IP and to setup PTR records for a static IP. The rest has been easy for me personally… but I do this shit for a living so I might be biased.

What do you use for that?

Because emails can have a boatload of sensitive information (especially when collected en masse, think years and years of emails)… In the day of AI bullshit. Minimizing all that data being directly attached to an account associated with you and owned by google or some other corp seems like a sane desire. If you primary a gmail account… and they start (they probably already are) training on that dataset. Shit is going to get real testy.

Nextcloud AIO on a Proxmox LXC container. One instance for home, one instance at work. All works great. Both are on fast ceph storage (SSDs at home and NVMe at work).