I've cracked billions of #passwords from tens of thousands of #data#breaches in the past 12+ years, and because of this, I likely know at least one #password for 90% of people on the Internet. And I'm not alone! While I primarily crack breached passwords for research purposes and the thrill of the sport, others are selling your breached passwords to criminals who leverage them in #AccountTakeover and #CredentialStuffing attacks.
Use a #Diceware style #passphrase - four or more words selected at random - for passwords you have to commit to memory, like your master password!
Enable MFA for important online accounts, including cloud-based password managers!
Harden your master password by tweaking your password manager's KDF settings! For #Bitwarden, use Argon2id with 64MB memory, 3 iterations, 4 parallelism. For #1Password and other PBKDF2 based password managers, set the iteration count to at least 600,000.
Use unique, randomly generated passwords for all your accounts! Use your password manager to generate random 14-16 character passwords for everything. Modern password cracking is heavily optimized for human-generated passwords, because humans are highly predictable. Randomness defeats this and forces attackers to resort to incremental brute force! There's no trick you can do to make a secure, uncrackable password on your own - your meat glob will only betray you.
Use an ad blocker like #uBlock Origin to keep you safe from password-stealing #malware and other browser based threats!
Don't fall for #phishing attacks and other social engineering attacks! Browser-based password managers help defend against phishing attacks because they'll never autofill your passwords on fake login pages. Think before you click, and never give your passwords to anyone, not even if they offer you chocolate or weed.
#Enterprises: require ad blockers, invest in an enterprise password management solution, audit password manager logs to ensure employes aren't sharing passwords outside the org, implement a Fine Grained Password Policy that requires a minimum of 20 characters to encourage the use of long passphrases, implement a password filter to block commonly used password patterns and compromised passwords, disable #NTLM authentication and disable RC4 for #Kerberos, disable legacy broadcast protocols like LLMNR and NBT-NS, require mandatory #SMB signing, use Group Managed Service Accounts instead of shared passwords, monitor public data breaches for employee credentials, and crack your own passwords to audit the effectiveness of your password policy and user training!
>The Government of Nova Scotia, which uses MOVEit to share files across departments, also confirmed it was affected, and said in a statement that some citizens’ personal information may have been compromised. However, in a message on its leak site, Clop said, “if you are a government, city or police service… we erased all your data.”
@lewdthewides Yeah... with #sftp servers supporting #LDAP + #Kerberos and #Wormhole existing, I just can't find myself being particularly sympathetic to them.
There was absolutely no reason to use some #proprietary service for it.
If the local machine is missing a keytab file, though, isn’t that local #Kerberos for PAM implementation already fundamentally broken? Without a keytab entry, you could /never/ be sure the TGT was legit.
Are keytab files optional when configuring krb5 on FreeBSD? How about other OSes? IOW, does this CVE describe a fundamental, common implementation issue with OTHER pam-krb5 installs?
I haven’t looked at the patch yet (on a phone, not entirely sure I want to get out of bed yet on a Sunday). But the more documentation I read on fixing common pam-krb5 problems, the more suspicious I become that nobody does keytab checking correctly (except, now, #FreeBSD).
That's fun. Reminds me of netcat's GAPING_SECURITY_HOLE
Skimming #RedHat Linux docs, it looks like pam_krb5 is deprecated anyway in favor of pam_sssd, and pam_sssd automatically creates a keytab file upon joining the domain -- looks non-optional.
Over in #Ubuntu land, it looks like keytab is similarly required, but you can turn it off manually (according to the man page).
So with those two examples, my bet is that most #Linux domain members are okay by default. Broken #Kerberos is still broken, but you have to go out of your way to break it (and if you have that breaking power, you can do easier things anyway like just straight up suing as someone else).
The above is based purely on documentation, no testing.
Sigh. So copying and pasting commands from the internet doesn't solve my problem. This means I'm going to have to actually try and /understand/ what's wrong. I didn't sign up for this.
@hl@xdydx#FreeBSD has only support for SMBv1, which you should absolutely avoid for security reasons, although you can probably configure #samba to still allow it ... but ... don't. Nowadays I'd prefer to say FreeBSD does not support mounting SMB shares.
There are some ports available implementing "modern" SMB (v2/v3) on top of #fuse, which might be an option, but in my experience, they're not perfectly reliable and performance isn't the greatest either.
If ever possible, work on the server side and see whether you can share via #NFS instead. Either #NFSv3 (which is only "secure" as long as your network is perfectly secure and you control all participating machines, but at least it doesn't pretend to do anything else), or #NFSv4 with #kerberos security.
My first troublesome hallucination with a #LLM in a while: #Claude3#Opus (200k context) insisting that I can configure my existing #Yubikey#GPG keys to work with PKINIT with #Kerberos and helping me for a couple of hours to try to do so — before realising that GPG keys aren't supported for this use case. Whoops.
No real bother other than some wasted time, but a bit painful and disappointing.