Client side verification is just security by obscurity, which gains you very little.
If someone is capable of MITM attacking a user and fetching a password mid-transit to the server over HTTPS, they are surely capable of popping open devtools and reverse engineering your cryptographic code to either a) uncover the original password, or b) just using the encrypted credentials directly to authenticate with your server without ever having known the password in the first place
The word ‘decipher’ is doing a lot of heavy lifting. I’m wondering if they socially engineered or just found it written somewhere in the house?
You can plausibly brute force up to 4, maybe 5 words of a seed phrase. It takes longer than a normal password because every seed phrase is technically valid, so the only way to know if your brute force is successful is to generate thousands of addresses at each of the different derivation paths you may expect funds to exist at.
The same seed phrase is used for Bitcoin, Ethereum, Monero, etc, but each currency uses the seed phrase to generate addresses in a slightly different standard. Additionally, each wallet uses a slightly different variation of that. Within each wallet is a notion of accounts, and within each account you could have dozens of addresses. You need to generate each of those addresses, and scan each cryptocurrencies blockchain to see if those addresses have ever been used.
Realistically one of three things happened: his seed phrase was written down and they found it, it was password protected or on a drive with weak AES encryption and they cracked THAT instead, or finally, he used a hardware wallet and they exploited a firmware vulnerability to lift the PIN and transfer out funds and/or read the seed from the device
You are acting like someone checked off a "log passwords" box, as if that's a thing that even exists
Someone configured a logger to write HTTP bodies and headers, not realizing they needed to build a custom handler to iterate through every body and header anonymizing any fields that may plausibly contain sensitive information. It's something that literally every dev has done at some point before they knew better.
lol. Did this in my old building - the dryer was on an improperly rated circuit and the breaker would trip half the time, eating my money and leaving wet clothes.
It was one of the old, "insert coin, push metal chute in" types. Turns out you could bend a coat hanger and fish it through a hole in the back to engage the lever that the push-mechanism was supposed to engage. Showed everyone in the building.
The landlord came by the building a month later and asked why there was no money in the machines, I told him "we all started going to the laundromat down the street because it was cheaper"
And then when you are finally hyped that season 2 is going to be packed with surfing, they announce its cancelled
10 days without food hits differently when you are hiking through mountains 16 hours a day vs sitting on your couch
Literally every library with any traction in any field is MIT licensed.
If the scientific python stack was GPL, then industry would have just kept paying for Matlab licenses
For every 1 person who knows how to use the windows command line, there are 50 people struggling because they didn't embed their video into their PowerPoint, or worse, their USB stick only contains a shortcut to their actual .ppt file
The plastic liners in and on tins and cans - referred to as lacquer in the industry - don't impact recycling. When the tins are heated to thousands of degrees for recycling, what is left of the plastic liner, the inks and UV materials; is separated and basically skimmed off, leaving the metal.
https://ekko.world/plastic-lining-on-beverage-food-cans/226751
For us, probably 1 in 10-15ish say they never signed up. We also have a double opt in, meaning every single one of them opened an email and clicked a link to confirm they wanted to keep getting marketing emails
About 0.2% of people unsubscribe every time we send something out
No it doesn't, if they intercept an encrypted password over HTTPS they can resend the request from their own browser to get access to your account
What is the problem with that? The password is secure and only shared between you and the site you are intending to communicate with. Even if you sent an encrypted password, they wrote the client side code used to generate it, so they can revert it back to its plaintext state server side anyways
How would you verify it then?
If not sending plaintext passwords was best practice then why do no sites follow this? You are literally posting to a site (Lemmy) that sends plaintext passwords in its request bodies to log-in