For those who want to lock things down without going offline and moving to a bunker in New Zealand, the first step is to assess the following things:

• What in my digital life can give away critical information tied to my finances, privacy, and safety?
  • What can I do to minimize those risks?
  • How much risk reduction effort is proportional to the risks I face?
  • How much effort can I actually afford?

First, if you're not at home, you should always lock your device before you put it down, no exceptions. Your phone should be locked with the most secure method you're comfortable with—as long as it's not a 4-digit PIN, which isn't exactly useless but is definitely adjacent to uselessness. For better security, use a password or a passcode that's at least six characters long—and preferably longer. //

Second, set your device to require a password immediately after it’s been locked. //

Also, regularly back up your phone. //

[Don't install bad apps -- consider carefully where it comes from, what it does, if you really need it.] //

Consider turning off Wi-Fi when you’re away from home. Your device may otherwise be constantly polling for the network SSIDs in its history to reconnect automatically or to connect to anything that looks like a carrier’s Wi-Fi network. When this happens, your device gives away information about networks you’ve seen and might allow a hostile network access point to connect. Also, your phone's Wi-Fi MAC address could be used to fingerprint your device and track it. //

The same goes for Bluetooth. If your device has Bluetooth turned on, it’s broadcasting information that could identify it—and you. //

Along those same lines, name your device anything other than [Your Name]’s iPhone. Your phone's network name is broadcast all around you, and it's like holding up a beacon saying "Hello, my name is..." //

[Malware protection on your PC] Even allowing Windows Defender to run in the background provides a significant bump in protection over nothing, and disabling it without a very good reason is a very bad idea. //

[Keep your OS & software up to date -- install updates as soon as they are available ]

[Turn on Windows Firewall when in public]

In the event that your physical device is compromised, you can minimize damage by caring for your actual data. To prevent all types of data loss, back up your data—in encrypted form and offline (either locally or in the cloud) so that ransomware doesn’t get the backups, too. Keep multiple backups just in case, because if your latest backup contains the compromised or encrypted files, it's useless.

And don't just back up your data, use full-disk encryption. Period. It's a one-time setting to activate and there are no excuses for not using it. Full-disk encryption transparently encrypts your hard drive so data can’t be read off of it without your credentials. //

Wi-Fi access points and routers that support firmware or software updates add another layer to the security of your devices while web browsing. If you have an older Wi-Fi access point that you can’t update, toss it. //

And, finally, use a password manager. An easy-to-guess password renders all other security efforts moot. Whether it’s a password built into your web browser of choice or a standalone program, use one. Chrome, Firefox, and Safari all have reasonably secure password managers, and you can replicate passwords for web accounts across devices. If you don't like the idea of a password manager because you're one of those folks who just uses letmein123! as your password everywhere, you need to decide if the convenience is worth the price you'll eventually pay when you're compromised. (Spoiler alert: it's not.)

u/ABC_AlwaysBeCoding (OP)
....
A few days in I started to see some unexplained panics/freezes. Some Steam games would fail validation... Something was wrong. I ran btrfsck and... it reported problems. I couldn't repair them without booting off another disk so I found my Manjaro USB key I made and booted off that again and attempted to --repair the btrfs drive.

FAIL. It was unable to do it. Unrecoverable errors. The partition was basically hosed! WTF? Luckily I only had "game data" on it and it was all synced with the cloud!

Initially I blamed BTRFS. I was mad. I had heard Ubuntu 19.10 now has experimental ZFS-on-root support out of the box. I was intrigued. I said "fuck it", made an installer key and wiped my disk and ran with it.

Things went fine until... I was installing some big game and... things just stopped. But not like "hang" stopped, I could still move windows around and keyboard input still appeared on the screen, which told me the CPU and GPU weren't the cause... fuck, it's something with the drive. It only cleared on reboot. I was afraid my data or filesystem got corrupt... turns out the former did not happen and the latter is virtually impossible with ZFS (yessss), so I tried again. Again, under heavy usage things eventually just froze. I kept trying different things now that I could duplicate it. I had the idea of forcing heavy activity via manually triggering a scrub and then watch zpool status in another window.

And then sonofabitch, I finally saw it. The drive that had just reported as ONLINE during the scrub, suddenly reported "SUSPENDED: One or more devices are faulted in response to IO failures." zpool clear did not clear it. But now I KNEW it was a drive (or enclosure, or cable, or mobo) issue. I immediately suspected the drive cable (as one does, who has been doing this sort of thing for a while), finally found another USB-A 3.1 to USB-C cable from Plugable that looked solidly built, and substituted it.

BOOM. ALL PROBLEMS WENT AWAY.

So OK, the enclosure guys (really cool enclosure, btw) sent me a bad cable with it. It happens. But...

SOLD... on ZFS. //

u/atemu12
The things btrfs check reported might've been benign warnings, false positives and/or fixed on mount.

--repair the btrfs drive.

RTFM

Warning

  Do not use --repair unless you are advised to do so by a developer or an experienced user, and then only after having accepted that no fsck successfully repair all types of filesystem corruption. Eg. some other software or hardware bugs can fatally damage a volume.

Not reading the manual results in:

Unrecoverable errors. The partition was basically hosed! //

u/ABC_AlwaysBeCoding (OP)
Fair enough. Thing is, --repair may be dangerous but it seems to be impossible to corrupt a ZFS filesystem because there isn't even a way to run any sort of --repair short of a resilvering/scrub. But yeah, I was inexperienced with both of these filesystems, as you can tell.

Btrfs will try to continue regardless of error

This is absolutely the wrong strategy. Once corruption starts, it usually spreads. I think ZFS does the right thing here, even if it is inconvenient (and to be fair, if I had a mirror, it probably would have just continued as well... I think? Maybe I'll keep the bad cable to do resilience testing).

BTRFS basically uses the Golang strategy (ignore errors, be squishy and nondeterministic, just keep going), ZFS uses the Erlang/Elixir strategy (fail fast, fail hard, be brittle and deterministic, restart cleanly) and I am most definitely in the latter camp based on 20+ years in the industry getting paid to program while doing sysadmin for fun or necessity.

You can do a number of things to reduce the risks posed by data breaches and identity fraud. The first is to avoid accidentally exposing the credentials you use with accounts. A data breach of one service provider is especially dangerous if you haven’t followed best practices in how you set up credentials. These are some best practices to consider:

• Use a password manager

• When possible, use two-factor or multi-factor authentication ("2FA" or "MFA"). This combines a password with a second, temporary code or acknowledgment from someplace other than your web browser or app session. Two-factor authentication ensures that someone who steals your password can’t use it to log in. If at all possible, don’t use SMS-based 2FA, because this is more prone to interception.

• Set up a separate email address or email alias for your high-value web accounts so that all email regarding them is segmented off from your usual email address. This way, if your primary email address is caught up in a data leak, attackers won’t be able to use that address to try to log in to accounts you care about.

• If you're a US resident, make sure to claim an account for your Social Security number from the IRS for tax information access and other purposes.

• Consider locking your credit reports to reduce identity theft risks.

Tulsi Gabbard 🌺
@TulsiGabbard
The prosecutor in the Rittenhouse trial clearly didn’t do due diligence before making the decision to prosecute. This tragedy never would have happened if the government carried out its responsibilities to protect the safety, lives and property of innocent people.
7:01 PM · Nov 10, 2021

Appendix A of NIST 800-63B addresses this well. Avoiding password patterns is specifically why they recommend against arbitrary password complexity requirements and arbitrary password expiration times. Passwords should only be force expired on events. Timed expiration and complexity rules encourage patterns that make the password weaker. //

Levenshtein distance as a proxy for password strength is extremely limited, for the reasons that schroeder has outlined. And the user experience will probably be poor.

But the question is still academically interesting, and may be useful as a component for some use cases - so it still deserves a thorough answer. :D

Generally, the minimum Levenshtein distance between a previous password and a new one should be the same size as the minimum length of a randomly-generated password that would resist brute force (adjusted to the attacker's threat model). But it's important to note that even this minimum is often inadequate. //

Best case - the passwords are entirely randomly generated, both initially and later. In this case, Levenshtein distance isn't as relevant (or rather, measuring the Levenshtein distance between two randomly generated passwords is just a proxy for measuring the quality of their randomness). //

If we assume all worst cases (human-generated password, poor password-selection strategy, etc.), the answer should be clear: the amount of change in the password should itself be enough to withstand attack on its own - totally independent of the previous password (as if the first password was empty), and as if it was stored using a very fast hash like MD5. This is reduced to how fast we can reasonably expect a randomly generated password to be exhausted for a given threat model, and is covered well elsewhere (but can often hover around 13-15 random characters). //

In other words ... just like Shannon entropy, usefulness of Levenshtein distance as a measure of password strength is really only useful in cases where the passwords are already randomly generated. And if you're doing that, you already have the information necessary to keep them strong, without trying to measure the difference between two of them.

In even other words ... very low Levenshtein distances are an OK proxy for password change weakness, but high Levenshtein distances are a very poor proxy for password change strength. So my answer tries to find a balance between the two.

Environmentalism offers emotional relief and spiritual satisfaction, giving its adherents a sense of purpose and transcendence.

There is a recurring puzzle in the history of the environmental movement: Why do green activists keep promoting policies that are harmful not only to humans but also to the environment? Michael Shellenberger is determined to solve this problem, and he is singularly well qualified.

Alex Wilkes
@AlexandraWilkes
Sen.-Elect Ed Durr on @SaveJersey live when asked about @TheAtlantic’s contention that he doesn’t know how to govern in the New Jersey legislature:

“How much worse could I make it?”
8:33 PM · Nov 9, 2021

Unfortunately for this young family, though, their nightmare was not over. Instead, two months after their child was returned to them, they received a letter from DCFS notifying them that their names were being added to the state’s registry of child abusers.

It’s “like a nightmare that won’t end,” the father, Chris, told WDSU in their report.

But it is all too common.

Yes, even when the parents have been found “not guilty” of any criminal charges. Even when the family court judge orders the baby returned, declaring that the home is safe.

The system is deeply flawed, preventing most parents from getting any kind of legal due process until after their name has been added to the roll.

At least in Louisiana, it looks like their names are not added until their appeal is waived or concluded. Chris and Tess won their appeal, so their names never actually went on the list. But this is not the norm in every state. And the harm to families is real.

Attorney Andrew Brown of the Texas Public Policy Foundation (TPPF) is an ally of the Parental Rights Foundation, working together to bring reform in this area. Andrew was also quoted in the WDSU report: “When you separate a child from their family, you are guaranteed to cause trauma to that child, even if it’s just for a week.”

That’s why we drafted a model bill to provide due process before a parent’s name goes on the list. It’s why we introduced that model to the American Legislative Exchange Council (ALEC) in 2019 and secured their endorsement of it.

It’s why we supported the work of Brown’s TPPF to bring that model to fruition in Texas during the 2021 session. And it’s why we’re gearing up to introduce similar legislation in additional states in 2022. //

If you know a lawmaker willing to champion such a bill, send them the model (available online here) as a starting point. Then email Michael@ParentalRights.org and let me know who you’ve reached out to (and, ideally, any response you receive).

My company policy states I must put all passwords in a password safe shared with management. Is this secure?

As the title says, my company has a policy that all passwords to e.g. our workstations and server logins must be stored in an online safe. I won't say which one but there are some out there you can look at promising the end of password pain. These passwords are then shared with the company's management - I don't know how that bit works, but they can read the passwords too. //

None of the reasons you've given are valid reasons for escrowing your password. There's only a couple valid reasons for escrowing any sort of "authenticator" information. A couple others have touched on these, but I'll try to clarify a bit.

1. Encryption Keys: It makes absolute sense for the organization to have access to escrow copies of your encryption keys. After all, the data you're encrypting (provided you're only using your company's encryption for work purposes, of course) is their data in the end anyway. So, they need to retain access to that data in the event you lose your key or you are separated from the company. However, the encryption key should not be the same key you use for digital signatures. Also, they should not have actual access to your authenticator - the passcode you use for the key. Instead, they should have their own escrow key that works with their authenticator to decrypt your data.

2. Failsafe Accounts: It also makes sense that the organization should have backup copies of credentials necessary to access an Administrator-level account in the event the System Administrator's own account is locked out, or they depart the company. However, the credentials should not be for the System Administrator's own account. They should be for a local system account whose sole purpose is for emergency use. To that end, the account should also never be used for non-emergencies and its usage should be closely monitored and alerted. Traditionally, credentials for accounts like these are sealed in tamper-evident envelopes and stored in a secure, physical vault. It's conceivable that there may be digital equivalents, but I personally wouldn't trust those without a thorough review.

There's two big reasons why it's a bad idea for management to have your password. The first reason is potentially very bad for you, as it could end up causing otherwise unnecessary work for you if things go wrong. However, the second actually turns this around and makes it potentially worse for the company than it is for you if things go really wrong.

1. Potential For Abuse: The obvious one - managers now effectively have unrestricted access to the systems, regardless of whether they should, with the same privileges you have. Most simply this means that the managers may leverage this to do things on the system that they otherwise should not be doing. This also leaves the potential for them to bypass your position whenever they want to rush a particular change along without following standard procedure.

2. Loss of Non-Repudiation: Once someone else has your credentials - and, especially in a case like this where it can be proven they do - they can impersonate you on any systems where those credentials are valid. This makes it difficult to definitively prove that any actions taken by your account were actually taken by you. If a manager does decide to use your account, and ends up royally screwing up the system, it won't be very easy to use you as a scapegoat even though your account is in the logs. Worse for the company is, if you do something to royally screw up the system while your managers have your password, they'll have a harder time proving that it was actually you that did it.

TL;DR: There's no good reason I can think of for management to have any of your passwords. As for the reasons they've given:

1. "If you forget your password..." another System Administrator can reset it for you. Or, management can "break the glass" on the emergency account (see "Failsafe Accounts" above) and do it themselves.
2. "If you turn evil..." again you can be locked out by another System Administrator, or the emergency account. //

No, it is not a good idea. Thomas explained why it doesn't achieve its own goals, but it is worse than that.

Consider what happens when a rogue employee misbehaves causing damage to the company.

During the trial, you are subpoenaed to testify about logs showing that it was the employee who caused the damage, and are asked who else could log in as this employee. You truthfully answer that anyone with access to the safe including all of management could log in as that employee and your logging systems would be none the wiser.

Anything that blurs the distinction between actor and authenticating credentials seriously undermines the company's ability to use access logging to discourage misbehavior or recoup damages.

Managers often hand out passwords to subordinates when an IBAC system fails to explicitly handle delegation, but this is the reverse of that case, where the blurring affects the credentials of the much larger group of lower-level employees.